Dieses Tool hat Homebrew gerade getötet.

Die meisten macOS-Entwickler leben in einem prekären Stapel von Werkzeugen. Homebrew installiert alles von `git` bis `ffmpeg`, ASDF oder NVM jonglieren mit Sprachversionen, und eine Mischung aus Shell-Skripten, MacUp-Klonen oder privaten „Bootstrap“-Gists versucht, alles miteinander zu verbinden. Jeder neue Mac wird zu einem Wochenendprojekt aus dem Kopieren und Einfügen von `brew install`-Befehlen und dem Beten, dass `brew bundle` noch der Realität entspricht.

Diese Realität weicht fast sofort. Sie installieren ein einmaliges Tool für ein Kundenprojekt, passen eine `defaults write`-Einstellung an, setzen Node 18 für eine App und Node 20 für eine andere fest und vergessen darüber hinweg. Sechs Monate später funktioniert Ihr Laptop, aber Sie haben keine Ahnung warum, und Ihre `Brewfile` oder Dotfiles erfassen nur etwa 60% von dem, was tatsächlich wichtig ist.

Die Konfigurationsabweichung ist die stille Steuer auf jeden Mac, den Sie besitzen. Niemand verfolgt, welchen obskuren `launchctl`-Dienst Sie deaktiviert haben, welche Python-Version Sie mit pyenv im Vergleich zu Homebrew installiert haben oder welche `~/Library`-Plist Sie um 2 Uhr morgens manuell bearbeitet haben. Versuchen Sie, diese Maschine auf einem neuen Mac nachzubauen, und Sie werden feststellen, dass "dieselbe Konfiguration" eigentlich nur eine grobe Annäherung ist, kein reproduzierbarer Zustand.

Entwickler versuchen ständig, sich mit immer ausgeklügelteren `setup.sh`-Dateien und Dotfile-Repos aus dieser Situation herauszuschreiben. Möglicherweise haben Sie: - `brew bundle dump`, um Pakete zu snapshotten - ASDF- oder NVM-Konfigurationen für Laufzeitumgebungen - Ein `bootstrap`-Skript, das Dotfiles symlinkt und über 20 Befehle ausführt

All dies bleibt unerlässlich: „Mach dies, dann das, dann vielleicht noch dies andere, falls es nicht installiert ist.“ Lass einen Schritt aus oder führe es auf einer leicht anderen macOS-Version aus, und der gesamte Prozess gerät ins Wanken.

Der Traum sieht ganz anders aus: eine einzige, versionierte Datei, die Ihre gesamte Umgebung beschreibt. Eine deklarative Konfiguration, die sagt: „Dieser Mac hat diese Pakete, diese Apps aus dem Mac App Store, diese Sprachversionen und diese Systemeinstellungen“ und ein Tool, das die Realität mit der Datei übereinstimmt – auf jedem Mac, zu jeder Zeit.

Im Vergleich dazu fühlt sich das heutige Homebrew-zentrierte Workflow wie das Skripting eines Kartenhauses an. Ein falsches Upgrade, ein fehlender Tappe, eine stille Warnung von `brew doctor`, und dein „Standard“-Setup bricht in Stunden manueller Reparatur zusammen.

Homebrew fühlt sich an wie ein Befehl: `brew install vim`, Enter drücken, hoffen, dass nichts explodiert. Nix fühlt sich wie ein Vertrag an. Du beschreibst den genauen Zustand, in dem dein Mac sein sollte, und Nix ist dafür verantwortlich, dass die Realität jedes Mal, auf jeder Maschine, mit dieser Beschreibung übereinstimmt.

„Rein funktional“ klingt akademisch, aber für Entwickler bedeutet es eines: Vorhersehbarkeit. Mit derselben Konfigurationsdatei und denselben Eingaben produziert Nix immer dieselben Ausgaben – identische Versionen, identische Abhängigkeiten, identische Systemeinstellungen. Keine überraschenden Updates, keine „läuft auf meinem Rechner“-Gespenster.

Traditionelle Werkzeuge wie Homebrew leben in einer imperativen Welt. Sie führen eine Reihe von einmaligen Befehlen aus: - `brew install vim` - `brew upgrade` - `brew uninstall node`

Ihr System wird zur Summe jedes Befehls, den Sie jemals eingegeben haben, plus allem, was diese Befehle zur Folge hatten. Versäumen Sie einen Schritt bei einem neuen Mac, driftet Ihre Einrichtung stillschweigend vom Original ab.

Nix verwandelt das in ein deklaratives Modell. Sie pflegen eine Konfiguration, die in Code festlegt: „Dieser Mac muss `vim`, `neovim`, `nodejs-20`, `python-3.11`, diese Dotfiles und diese Systemeinstellungen haben.“ Nix erstellt dann diesen Zustand von Grund auf neu, als ob Ihr Mac eine frische VM wäre, und wendet ihn atomar an.

Atomic ist das operative Wort. Nix-Installationen leben in inhaltsadressierten Speicherpfaden, sodass Upgrades zu Transaktionen werden: Entweder wird die neue Konfiguration erfolgreich erstellt, oder Ihr System bleibt genau so, wie es war. Wenn ein Update Ihre Toolchain beschädigt, führen Sie einen einzigen Rollback-Befehl aus und stellen die gesamte Umgebung—Binaries, Bibliotheken, Konfiguration—wie eine lokale Zeitmaschine wieder her.

Da jedes Paket in seinem eigenen isolierten Präfix lebt, installiert Nix glücklich mehrere Versionen desselben Werkzeugs konfliktfrei. Sie können drei verschiedene `node`-Versionen, ein festgelegtes `python` für ein Projekt und ein brandneues `git` für ein anderes haben, die alle ohne Shim-Skripte oder Version-Manager-Tricks koexistieren.

Am wichtigsten ist, dass Nix dein gesamtes Setup als Code behandelt. Deine Nix-Dateien werden zu einem persönlichen Infrastructure-as-Code-Stack: CLI-Tools, GUI-Apps, Installationen aus dem Mac App Store, Shell-Konfigurationen, sogar `defaults write`-Anpassungen, alles unter Versionskontrolle. Ein neuer Mac wird nicht mehr zu einem Wochenendprojekt, sondern zu einem `git clone` und einem einzigen Build-Befehl.

Nix begann 2003 als niederländisches Doktoratsprojekt von Eelco Dolstra, ein Experiment in rein funktionalem Paketmanagement. Diese Forschung entwickelte sich zur Nix-Sprache und dann zu NixOS, einer Linux-Distribution, bei der jedes Paket, jeder Dienst und jede Systemanpassung aus deklarativen Nix-Konfigurationen abläuft. In den 2010er Jahren war NixOS zu einer ernsthaften Alternative für reproduzierbare Linux-Systeme in der Wissenschaft, DevOps und in Homelab-Kreisen geworden, unterstützt von Tausenden von Mitwirkenden und über 80.000 Paketen in Nixpkgs.

Mac-Entwickler haben größtenteils von der Seitenlinie zugeschaut, bis Nix Darwin erschien. Nix Darwin wurde als Schicht über Nix entwickelt und übersetzt diese NixOS-ähnlichen Module in etwas, das den Unix-Kern von macOS, Darwin, versteht. Es verwaltet Launch-Daemons, Benutzeragenten, Shell-Umgebungen und Systemeinstellungen auf dieselbe Weise, wie NixOS `systemd`-Einheiten und -Dienste verwaltet.

Beziehungsmäßig denken Sie in drei Schichten. Nix ist der Motor: der Paketmanager und die Sprache. Nixpkgs ist das massive Repository von Softwaredefinitionen und Konfigurationsmodulen. Nix Darwin ist der Kleber, der diese Abstraktionen auf macOS abbildet und Optionen für alles von `brew`-ähnlichen CLI-Tools bis hin zu Dock-Autohide-Einstellungen bereitstellt.

Anstatt die Konfiguration über `/usr/local`, zufällige Dotfiles und versteckte plist-Anpassungen zu verstreuen, zentralisiert Nix Darwin die Kontrolle. Eine einzelne Flake kann deklarieren: - Welche Pakete aus Nixpkgs installiert werden sollen - Welche Mac-Systemeinstellungen gesetzt werden sollen - Welche Dienste aktiviert oder deaktiviert werden sollen

Nix Darwin ist kein Wochenendprojekt. Es lebt auf GitHub mit Hunderten von Mitwirkenden, aktiver Problemanalyse und regelmäßigen Veröffentlichungen, die mit neuen macOS-Versionen Schritt halten. Power-User integrieren es in ihre My Dotfiles-Repositories und bauen gesamte Macs nach einer Neuinstallation mit einem einzigen `darwin-rebuild switch` neu auf.

Jeder, der sehen möchte, wie dieses Ökosystem zusammenpasst, kann auf der offiziellen Website von Nix & NixOS und im Nix Darwin-Repository beginnen. Gemeinsam verwandeln sie macOS von einem handoptimierten Schneeflocken zu einem Artefakt, das Sie versionieren, überprüfen und wie jeden anderen Code zurücksetzen können.

Flakes klingen wie ein Frühstücks-Cereal, aber im Nix-Land sind sie der de facto Standard der Gemeinschaft für reproduzierbare Konfigurationen. Anstelle einer bunten Sammlung von Shell-Skripten, Brewfiles und Synchronisationstools definiert ein einziger Flake genau, wie dein Mac aussehen sollte: Werkzeuge, Dienste und sogar welche Mac App Store-Apps du erwartest, dass sie existieren. Du erhältst eine einzige Quelle der Wahrheit, und Nix kümmert sich um den Rest.

Im Mittelpunkt steht `flake.nix`, ein Klartext-Manifest, das in der Nix-Sprache verfasst ist. Es hat zwei große Ideen: Eingaben und Ausgaben. Eingaben beschreiben, von welchen Abhängigkeiten deine Konfiguration abhängt; Ausgaben beschreiben, was deine Konfiguration produziert.

Eingaben umfassen normalerweise: - `nixpkgs` (die Haupt-Nix-Paketkollektion) - Andere Community-Flakes (wie `nix-darwin`-Module) - Ihre eigenen gemeinsamen Flakes für die Arbeit oder Nebenprojekte

Ausgaben verwandeln diese Zutaten in etwas, das Sie tatsächlich ausführen können. Eine `flake.nix` könnte Folgendes bereitstellen: - `packages` für CLI-Tools und Programmiersprachen-Laufzeiten - `darwinConfigurations` für vollständige macOS-Setups - `devShells` für projektbezogene Umgebungen

Führen Sie `darwin-rebuild switch --flake .#your-hostname` aus, und Nix baut die in Ihrem Flake deklarierten Outputs, um sie dann auf Ihrem Mac zu aktivieren. Ändern Sie `vim` in `neovim`, fügen Sie `zellij` hinzu, rebuilden Sie, und Ihr System wechselt in einem Rutsch in den neuen Zustand. Keine manuelle `brew install`, kein Rätseln, welcher Version Manager welches Binary steuert.

Wenn `flake.nix` das Rezept ist, ist `flake.lock` die vakuumversiegelte Speisekammer. Diese JSON-Datei bindet jeden Eingang an eine genaue Git-Revision oder Version, sodass du und deine Kollegen beim Bauen aus demselben Repo identische Toolchains und Konfigurationen erhalten. Kein "funktioniert auf meiner Maschine"-Überraschungen, keine stillen Updates, weil `nixpkgs` über Nacht weitergezogen ist.

Es gibt einen Haken: Flakes bleiben offiziell „experimentell“ in Nix und sind hinter einem Feature-Flag versteckt. Die Realität sieht jedoch anders aus. Fast jeder moderne Nix-Leitfaden, jedes Starter-Template und jede ernsthafte Konfiguration — einschließlich beliebter Setups wie Nix Darwin auf dem Mac — geht davon aus, dass du Flakes verwendest, da sie stabil genug, leistungsstark sind und schließlich die Reproduzierbarkeit von Nix vollständig erscheinen lassen.

Die Installation von Nix auf macOS beginnt wie bei jedem anderen Entwicklertool: ein curlbarer Installer, ein Fortschrittsbalken und eine kurze Wartezeit, während es sich in Ihre Shell integriert. Danach weicht der Workflow sofort von der Homebrew-Welt ab. Sie erstellen ein dediziertes Verzeichnis `~/.nix` (oder ähnliches) und fügen dann eine Starter-Nix Darwin-Flake hinzu, die von GitHub oder einem Template wie My Dotfiles gezogen wird.

Diese Flake-Datei wird zur Quelle der Wahrheit Ihres Macs. Sie definiert, welche Pakete, Dienste und Systemeinstellungen auf der Maschine vorhanden sein sollten, von CLI-Tools bis zu Mac App Store-Apps. Anstatt ad-hoc `brew install`-Befehle auszuführen, bearbeiten Sie einen einzigen Nix-Ausdruck, der den gesamten Systemzustand beschreibt.

Alles dreht sich um einen Befehl: `darwin-rebuild switch`. Nix liest dein Flake, bewertet die Konfiguration, erstellt alles, was fehlt, und wechselt atomar deinen Mac in diesen neuen Zustand. Kein Suchen durch die Shell-Historie, kein Raten, welche Dotfile was umgeschaltet hat.

Ändern Sie eine Zeile in der Konfiguration, führen Sie `darwin-rebuild switch` aus, und die Maschine passt sich an. Im Video ersetzt der Moderator `vim` durch neovim in der Paketliste und fügt `zellij` hinzu (im Transkript fälschlicherweise als „zelage“ geschrieben), obwohl es zuvor nie installiert war. Nach dem Neuaufbau ist `nvim` systemweit verfügbar, `zellij` läuft sofort, und das alte Vim-Binary stammt nicht mehr von Nix Darwin.

Dieser Edit- und Wechselprozess verwandelt die Konfiguration in eine Codeüberprüfung statt in einen Ritus. Möchten Sie ein Tool vorübergehend testen? Fügen Sie es zur Flake hinzu, bauen Sie alles neu, probieren Sie es aus und entfernen Sie es dann wieder, um erneut zu bauen; Nix sammelt die ungenutzten Versionen automatisch ein. Jede Änderung ist explizit, versionierbar und auf Macs wiederholbar.

Im Vergleich zu einem traditionellen Homebrew-Setup ersetzt dies eine Vielzahl von Befehlen und Skripten. Eine typische frische Maschine könnte Folgendes umfassen: - 30–80 `brew install` und `brew install --cask` Aufrufe - Ein `brew bundle dump` oder MacUp-Export - Manuelle Bearbeitungen von Dotfiles und macOS-Einstellungen

Mit Nix Darwin und Flakes codieren Sie das gesamte Ritual einmal. Ein neuer Mac benötigt nur Nix und das geklonte Flake; `darwin-rebuild switch` stellt Ihre Umgebung mit einem einzigen Befehl wieder her, von CLI-Tools bis hin zu Systemeinstellungen und Mac App Store-Apps, ohne dass eine mühsame Suche notwendig ist.

Homebrew denkt in Begriffen von Kommandozeilen-Tools und Casks; Nix denkt in Bezug auf komplette Welten. Sobald Sie einen Nix Darwin Flake eingerichtet haben, hört Ihr Mac auf, ein einzigartiges Unikat zu sein, und verhält sich wie ein reproduzierbares Build-Artefakt, von der Shell, die Sie verwenden, bis hin zu der Art, wie Ihr Dock animiert.

Die meisten Menschen entdecken Nix über `nixpkgs` und seine zehntausenden von CLI-Paketen, aber der Umfang reicht viel weiter. Eine einzelne Flake kann Ihre Entwicklungstools, GUI-Apps, Systemdienste, Schriftarten und sogar Startagenten deklarieren, alles auf genaue Versionen festgelegt, sodass ein frischer Mac im Jahr 2025 bitgenau mit Ihrem Laptop aus dem Jahr 2023 übereinstimmt.

Die Integration des Mac App Store lässt die Kinnladen normalerweise herunterklappen. Mit Nix Darwin ausgestattet, können Sie Apps über die App-ID deklarieren, und Nix wird sie aus dem Mac App Store abrufen, solange sie mit Ihrer Kaufhistorie der Apple ID verknüpft sind. Ihre Konfiguration kann buchstäblich sagen „installiere `409201541`“ und Sie erhalten Pages, oder „`497799835`“ und Sie erhalten Xcode, ohne manuelle Klicks im App Store.

Dieser Schritt ersetzt leise einen großen Teil dessen, was MacUp oder selbstgebastelte Backup-Skripte zu lösen versuchten. Anstatt eine Brewfile zu exportieren und zu hoffen, dass man sich erinnert, welche Apps aus dem App Store man verwendet hat, wird deine Flake zur kanonischen Liste von allem, was auf dem Gerät existieren sollte, unabhängig davon, wie Apple es verteilt.

Nix Darwin-Module gehen noch einen Schritt weiter, indem sie macOS-Präferenzen als Code behandeln. Sie können das Verhalten des Docks, die Wiederholrate von Tastenanschlägen, das Tippen zum Klicken auf dem Trackpad, die Sichtbarkeitsoptionen des Finders und die Aktivierung von Hot Corners deklarativ mit strukturierten Nix-Optionen festlegen, anstelle der anfälligen `defaults write`-Befehle. Ein `darwin-rebuild switch` wird zum Pendant für das Durchklicken durch ein Dutzend Systemeinstellungen auf einmal.

Das wandelt manuelle Nachinstallationsrituale in einen einzigen Commit um. Neuer Computer? Klone deine Dotfiles, führe einen Befehl aus, und dein Dock blendet automatisch aus, die Tastenwiederholung erreicht deinen bevorzugten Rhythmus von 15 ms, und deine Shell, Schriftarten und der Fenstermanager erscheinen genau wie zuvor.

Jemand, der neugierig ist, wie weit das geht, kann nix-darwin – Nix-basierte Systemkonfiguration für macOS durchstöbern. Zwischen diesen Modulen und einem guten Flake ersetzt Nix nicht nur Homebrew; es integriert leise Backup-Tools, Einrichtungskontrolllisten und jahrelange Muskelgedächtnis in ein einziges, erneut ausführbares Skript.

Homebrew-Enthusiasten müssen am ersten Tag nicht gleich alles auf den Kopf stellen und neu aufbauen. Eine weit weniger stressige Strategie betrachtet Nix als den Dirigenten und Homebrew als einen der Orchestertteile. Sie behalten Ihre bestehenden Tools, übergeben jedoch die Planung und den Zustand an eine einzige Konfigurationsdatei.

Moderne Nix-Darwin-Setups können tatsächlich Homebrew selbst verwalten. In einem Flake aktivierst du das Homebrew-Modul, leitest es auf deine bestehende Installation und deklarierst dann `brew.packages` und `casks` direkt alongside deinen Nix-Paketen. Wenn du `darwin-rebuild switch` ausführst, ruft Nix für dich `brew install`, `brew uninstall` und `brew upgrade` auf, sodass deine Brew-Welt zu einer weiteren reproduzierbaren Ausgabe wird.

Dieser hybride Ansatz schafft einen idealen Migrationspfad. Sie können beginnen, indem Sie die grundlegenden CLI-Tools — `git`, `node`, `python`, `fzf`, `ripgrep` — in `environment.systemPackages` oder Home Manager verschieben, während Sie GUI-Apps als Brew-Casks belassen. Im Laufe der Zeit ersetzen Sie Brew-Formeln durch Nix-Äquivalente, sobald Sie diese in nixpkgs finden.

Nixpkgs bietet derzeit mehr als 80.000 Pakete an, aber Homebrew Cask gewinnt weiterhin bei der reinen Abdeckung spezifischer Mac-Apps. Dieses lange Ende umfasst obskure Dienstprogramme, Nischen-Menüleistenwerkzeuge und seltsame Einmal-Installationen von Anbietern, die möglicherweise nie in nixpkgs landen. Diese als Brew-Casks unter Nix zu deklarieren, bedeutet, dass Sie nichts verlieren, während Sie den Rest Ihres Stacks standardisieren.

Eine typische "Bridge"-Konfiguration besteht aus drei Ebenen, die von einem einzigen Flake verwaltet werden:

• 1Nix-Pakete für alle grundlegenden CLI-Tools und Sprachlaufzeiten
• 2Nix-Module für Systemvorgaben und Dotfiles
• 3Homebrew-Casks für GUI-Anwendungen und Sonderanwendungen

Du führst weiterhin `darwin-rebuild switch` als deine einzige Quelle der Wahrheit aus. Im Hintergrund aktualisiert sich Nix selbst, wendet die macOS-Standardeinstellungen an, synchronisiert deine Dotfiles und steuert dann Homebrew, um alles zu installieren oder zu bereinigen, was du aufgelistet hast, und das alles, ohne dass du direkt `brew` anfasst.

Die meisten Menschen scheitern an Nix genau an dem Punkt, an dem dieses Video ansetzt: der „wirklich, wirklich steilen Lernkurve.“ Homebrew benötigt nur einen Befehl, um `wget` zu installieren; Nix begrüßt dich mit einer neuen Sprache, einem neuen Denkschema und einem Verzeichnisbaum, der aussieht, als hätte dein Mac eine Hash-Funktion verschluckt. Power-User betrachten diesen Tausch als ein Schnäppchen; alle anderen nennen es ein Wochenende, das für die Dokumentation verloren ging.

Erste Hürde: die Nix-Sprache selbst. Sie sieht ein wenig aus wie JSON und ein wenig wie Haskell, macht dann aber Dinge, die keiner von beiden tut. Man schreibt Attributsätze, Lambdas und Module, nur um zu sagen „installiere `neovim`“, und kleine Syntaxfehler treten häufig als 10-zeilige Fehlermeldungen über „Attribut ‚packages‘ fehlt“ zutage.

Zweite Wand: Konzepte der funktionalen Programmierung, nach denen Sie nie gefragt haben. Nix besteht darauf, dass alles rein und unveränderlich ist, also definieren Sie anstelle von „führen Sie dieses Skript aus“ Ableitungen, die beschreiben, was ein Build sein sollte. Das zahlt sich in Bezug auf Reproduzierbarkeit aus, zwingt Sie jedoch dazu, in Bezug auf Eingaben, Ausgaben und Auswertung zu denken, nicht „führen Sie eine Bash-Einzeile aus und hoffen Sie auf das Beste.“

Dann kommt der Nix-Store, der `/nix/store`-Wald von inhaltlich adressierten Pfaden, der Nix magisch und frustrierend macht. Jedes Build-Ergebnis lebt unter einem Hash wie `/nix/store/abcd1234-neovim-0.9.1`, was Isolation garantiert, das ad-hoc Tüfteln jedoch unfreundlich erscheinen lässt. Man „bearbeitet nicht einfach eine Konfigurationsdatei“; man bearbeitet ein Flake, baut neu und lässt Nix alte Generationen aufräumen.

Das Debuggen von Ableitungen fügt eine weitere Schmerzschicht hinzu. Wenn ein Paket nicht gebaut werden kann, sieht man sich Nix-Ausdrücken, Builder-Skripten und manchmal plattformübergreifenden Eigenheiten aus NixOS gegenüber. Homebrew-Fehler sagen normalerweise „fehlende Abhängigkeit“; Nix-Fehler sagen häufig „Wert ist eine Funktion, während ein Set erwartet wurde“ und erwarten, dass man weiß, warum.

Für einfache Installationen scheint Nix absolut übertrieben. Wenn man nur `node`, `python` und `ffmpeg` benötigt, fühlt sich Homebrews `brew install` schneller, klarer und viel weniger aufdringlich an, als Flakes zu aktivieren, Nix Darwin zu konfigurieren und eine `flake.nix` zu erstellen, nur um ein Shell zu bekommen. Das Video zeigt sogar, dass die anfängliche Einrichtung sich über mehrere Befehle, Flags und Konfigurationsänderungen hinzieht, bevor etwas Spannendes passiert.

Unter den Fans hat Nix ein indirektes Kompliment erhalten: den „schlechtesten Paketmanager, ausgenommen alle anderen.“ Man zahlt im Voraus mit Komplexität, unklaren Dokumentationen und verwirrenden Fehlern, und im Gegenzug erhält man ein System, das nach Bedarf den gesamten Mac rekreiert. Für viele Entwickler überwiegt diese Macht schließlich den Schmerz – nur nicht am ersten Tag.

Göttlich hohe Auszahlungen mit Nix sehen so aus: ein brandneuer Mac verwandelt sich in weniger als 10 Minuten von der Plastikfolie in eine voll ausgestattete Entwicklungsarbeitsstation. Du meldest dich bei Git an, klonst dein My Dotfiles-Repository, führst einen einzigen Befehl `darwin-rebuild switch --flake .` aus und siehst zu, wie dein Editor, die Shells, Programmiersprachen-Toolchains, Schriftarten und sogar die Mac App Store-Apps genau wie zuvor wieder erscheinen. Kein Suchen nach Installern, kein „Oh, richtig, ich habe vergessen, jq zu installieren.“

Im Hintergrund behandelt Nix deine gesamte Umgebung als Daten. Dein Nix Darwin-Plateau erklärt jedes Paket, jeden Dienst und alle macOS-Standardeinstellungen als Code, sodass der Zustand deiner Maschine eine reine Funktion eines Git-Commits wird. Setze diesen Commit zurück, und Nix rollt deine Werkzeuge, Konfigurationen und Systemanpassungen atomar in einem einzigen Schritt zurück.

Für Teams verwandelt sich das Onboarding von einem mehrstündigen Ritual in einen einzigen dokumentierten Befehl. Ein neuer Mitarbeiter zieht das Repository, führt den Flake aus und landet in einer Umgebung, die identisch mit der Produktion und dem Laptop jedes anderen Engineers ist – dieselbe `node`-Version, dasselbe `postgres`, dieselben CLI-Tools, dieselben Dotfiles. „Funktioniert auf meinem Rechner“ stirbt, wenn „mein Rechner“ ein reproduzierbarer Nix-Build ist.

Auch die tägliche Arbeit wird sicherer. Möchtest du Python 3.13, ein brandneues `clang` oder eine neue `zellij`-Konfiguration ausprobieren? Du pinnst sie in einen Branch, führst `darwin-rebuild` aus, und Nix baut die neue Generation neben der alten. Wenn etwas nicht richtig funktioniert, stellt ein einziger Rückrollbefehl die vorherige Generation wieder her, ohne schwebende Symlinks oder halb installierte Pakete.

Dieses atomare Modell fördert Experimente, die Sie niemals bei einem handangepassten Homebrew-Setup riskieren würden. Sie können Folgendes beibehalten: - Eine stabile „Arbeits“-Flake - Eine „Beta“-Flake mit neuen Werkzeugen - projektbezogene Flakes mit fixierten Abhängigkeiten

Der Wechsel zwischen ihnen wird zum Kinderspiel und dauert nur Sekunden, nicht ein ganzes Wochenende mit der Neuinstallation der Xcode Command Line Tools.

Entwickler dokumentieren diesen Workflow bereits in der Praxis; Anleitungen wie Nix on macOS – das bessere Homebrew zeigen, wie man Homebrew vollständig durch deklarative Nix-Konfigurationen ersetzt. Sobald du siehst, wie ein frischer Mac aus einem Git-Commit entsteht, fühlt sich jedes Ad-hoc-Setup-Skript an, als würdest du deine Umgebung mit Steinen zusammenklopfen.

Neugierig, aber nur theoretisch Nix-pilled? Beginne damit, Nix wie ein intelligenteres, entsorgbares virtuelles Umfeld zu behandeln, anstatt es als neue Religion für deinen Mac zu sehen. Installiere Nix, öffne einen Projektordner und führe `nix-shell -p <package>` aus, um eine isolierte Umgebung zu erstellen, die verschwindet, wenn du das Terminal schließt. Keine globalen Installationen, keine `brew uninstall` Aufräumarbeiten, kein Risiko für deinen bestehenden Stack.

Verwende diesen einen Befehl als deine Trainingsräder. Benötigst du `jq`, `nodejs` und `postgresql` für ein Nebenprojekt? Führe `nix-shell -p jq nodejs postgresql` aus und arbeite in dieser Shell. Du erhältst reproduzierbare Werkzeuge pro Projekt, ohne deinen System-PATH berühren oder deine Dotfiles umschreiben zu müssen.

Sobald sich das normal anfühlt, beginne damit, diese Ad-hoc-Shells in einfachen `.nix`-Dateien zu erfassen, die in deinem Repo gespeichert sind. Eine minimale `shell.nix`, die `nodejs-20_x` und `pnpm` festlegt, schlägt bereits eine README-Zeile, die sagt „installiere Node irgendwie.“ Teamkollegen führen `nix-shell` aus und landen in genau derselben Umgebung, egal wie chaotisch ihre Homebrew-Installation aussieht.

Wenn Sie bereit sind, zu sehen, wie ein vollständiges deklaratives Mac-Setup aussieht, stöbern Sie in den Konfigurationen anderer Leute. Durchsuchen Sie Meine Dotfiles des Videodenkers auf GitHub: Meine Dotfiles. Suchen Sie dann auf GitHub nach `nix-darwin flake.nix` und lernen Sie, wie die Leute es zusammenfügen:

• 1`nix-darwin`-Module für Systemdienste
• 2`home-manager` für benutzerspezifische Dotfiles
• 3`mas` Integration für Mac App Store Apps

Behandle diese Repos wie lebendige Dokumentationen. Kopiere ein kleines Stück – eine Schriftart, ein einzelnes CLI-Tool, eine Systemvorgabe – in dein eigenes Flake und führe `darwin-rebuild switch` aus. Wenn es kaputtgeht, stellst du eine Datei wieder her und bist zurück, kein `brew doctor`-Seance erforderlich.

Hier ist die unangenehme Frage: Rechtfertigt der kurzfristige Komfort von `brew install` eine Zukunft, in der dein Mac ein einzigartiges Unikat bleibt, dessen Tod du nie herbeisehn möchtest? Oder bist du bereit, ein Wochenende damit zu verbringen, Nix zu lernen, damit dein nächstes Laptop, dein nächster Job und deine nächste frische Installation zu einem Ein-Befehl-Ritual werden, anstatt zu einer einwöchigen Schnitzeljagd?

Was ist Nix und was macht es anders als Homebrew?

Nix ist ein funktionaler Paketmanager, der eine deklarative Konfigurationsdatei verwendet, um den gesamten Systemzustand zu definieren. Im Gegensatz zu den imperativen Befehlen von Homebrew (`brew install`) baut Nix Ihre Umgebung auf der Grundlage eines Manifests auf, was sicherstellt, dass sie überall reproduzierbar und konsistent ist.

Kann Nix Homebrew auf macOS vollständig ersetzen?

Ja, für viele Entwickler kann Nix (über Nix Darwin) Homebrew, Versionsmanager und Dotfile-Manager ersetzen. Es ist sogar in der Lage, Homebrew selbst zu verwalten, um GUI-Apps oder Pakete zu installieren, die noch nicht im Nixpkgs-Repository verfügbar sind, und bietet somit einen einzigen Kontrollpunkt.

Was sind Nix Flakes und warum sind sie wichtig?

Nix Flakes sind die moderne, standardisierte Methode zur Definition von Nix-Projekten. Sie sind deklarative Manifeste, die Abhängigkeiten festschreiben, wodurch Ihre Konfigurationen eigenständig und perfekt reproduzierbar werden, was einen wesentlichen Vorteil gegenüber herkömmlichem Paketmanagement darstellt.

Ist Nix tatsächlich schwer zu lernen?

Ja, Nix hat aufgrund seiner funktionalen Programmiersprache und neuer Konzepte wie Ableitungen und dem Nix-Store einen notorisch steilen Lernaufwand. Befürworter argumentieren jedoch, dass die anfängliche Investition sich mit unvergleichlicher Kontrolle und Reproduzierbarkeit auszahlt.