In der Welt der Softwareentwicklung und Systemverwaltung werden Tools wie Nix oft als das Nonplusultra für eine saubere, reproduzierbare und behebbare Arbeitsumgebung gefeiert. Nix verspricht eine revolutionäre Herangehensweise an Paketmanagement und Konfigurationsmanagement, die viele Nutzer in den Bann zieht – mich eingeschlossen. Nach mehr als zwei Jahren intensiver Nutzung in meinen Dotfiles und Arbeitsumgebungen habe ich mich jedoch entschieden, von Nix Abstand zu nehmen. Diese Entscheidung resultiert aus einer Vielzahl praktischer Erfahrungen, die mich an die Grenzen und den Overhead dieses Systems bringen ließen. Der folgende Text dokumentiert meine persönliche Reise, die Vor- und Nachteile, auf die ich gestoßen bin, und warum ich mittlerweile eine deutlich einfachere Vorgehensweise bevorzuge – ohne Nix. Zunächst einmal ist festzuhalten, dass Nix durchaus seine Vorzüge hat.
Die Idee, Systeme hermetisch und reproduzierbar zu gestalten, klingt gerade für Entwickler und Systemadministratoren reizvoll. Im besten Fall kann man mit einem definierten Satz an Konfigurationsdateien auf Knopfdruck seine Entwicklungsumgebung oder sogar ganze Systeme identisch einrichten. Gerade bei großen Teams oder komplexen Projekten ist das ein großer Vorteil, der sowohl Effizienz als auch Nachvollziehbarkeit fördert. Doch was, wenn man diese Art von Operation nicht regelmäßig braucht, sondern primär eine stabile, funktionale Entwicklungsumgebung für den Alltag sucht? Aus meiner Erfahrung mit Nix hat sich gezeigt, dass es eine gewisse Eigendynamik und Komplexität mit sich bringt, die schnell zu einem Overkill werden kann. Das System "übernimmt alles" auf eine Art und Weise, die zwar Kontrolle und Konsistenz verspricht, aber dabei auch starke Einschränkungen mit sich bringt.
Angefangen bei meiner Nutzung auf einem Mac musste ich feststellen, dass ich nahezu alles "nixifizieren" musste, damit es stimmig funktioniert. Diese Verpflichtung zur vollständigen Integration aller Programme und Plugins sorgt dafür, dass ich zum Beispiel Tools wie Lazy, Mason oder tpm nicht einfach so verwenden konnte, da die entsprechenden Verzeichnisse durch Nix verwaltet und schreibgeschützt waren. Das bedeutete für mich zusätzlichen Aufwand, alle Anwendungen auch über Nix zu beziehen und anzupassen. Ein noch größerer Stolperstein ergab sich bei der Verwaltung von Desktop-Anwendungen. Die Nix-typische Methode, Anwendungen per symbolische Links in einen eigenen Ordner wie ~/Applications einzubinden, macht es schwer, diese Programme über Spotlight auffindbar zu machen. Das beeinträchtigte meinen Workflow spürbar, weil die gewohnte Suche nach Programmen und deren Start deutlich eingeschränkt wurde.
Letztlich griff ich wieder auf Homebrew zurück, um Desktop-Anwendungen und aktuellere oder nicht verfügbare Versionen von Programmen zu installieren. Diese Dualität innerhalb des Systems fühlt sich nicht nur inkonsequent an, sondern auch unnötig komplex. Ein weiterer, entscheidender Nachteil liegt in der Aktualität der Pakete. Obwohl Nix mit dem sogenannten unstable-Kanal eine aktuellere Paketbasis anbietet, stellte ich immer wieder fest, dass viele Programme hinter den neuesten Versionen zurückbleiben. Gerade wenn bestimmte Features oder Sicherheitsupdates benötigt werden, ist es frustrierend, sich mit veralteten Paketen zufriedengeben zu müssen oder selbst Hand anzulegen, um neuere Versionen zu integrieren. Das manuelle Anpassen von Nix-Paketbeschreibungen ist mit einem erheblichen Zeitaufwand verbunden und erfordert teilweise ein tiefes Verständnis der Build-Prozesse sowie der Abhängigkeiten innerhalb der Nix-Community.
Darüber hinaus ist der unstable-Kanal seiner Natur nach instabil. Die Verlockung, immer die neueste Software zu nutzen, bedeutet gleichzeitig eine erhöhte Fehleranfälligkeit und häufige Brüche, die Fehlerbehebungen erfordern. Ein sonst relativ simpler Update-Vorgang mutierte schnell zu einer zeitraubenden Herausforderung, bei der aus einer kleinen Konfigurationsänderung ein halbstündiger Fix-Marathon wurde. Die Dauer der Anwendung von Änderungen an der Konfiguration ist ebenfalls ein nicht zu unterschätzender Faktor. Während man bei der Anpassung von Einstellungen oder dem Hinzufügen von Programmen eine schnelle Rückmeldung erwarten sollte, nahm das Anwenden von Anpassungen mit Nix oft mehrere Minuten in Anspruch. Dies ist besonders ärgerlich, wenn man mit kurzen Feedbackzyklen arbeitet, etwa bei der Anpassung eines Keymappings im Editor. Aus Sicht der Benutzerfreundlichkeit fühlte sich das zu langwierig und wenig effizient an, was den Spaß und die Produktivität einschränkte.
Aus all diesen Gründen habe ich mich auch mit der Grundidee von Nix auseinandergesetzt – der unumstößlichen Bedeutung von Reproduzierbarkeit. Obwohl eine vollständig reproduzierbare Systemumgebung theoretisch äußerst sinnvoll ist, konnte ich im Alltag kaum einen Mehrwert darin erkennen. In zehn Jahren Nutzung verschiedener Rechner habe ich meinen Arbeitsrechner etwa viermal gewechselt. Trotzdem hat das Konzept der Reproduzierbarkeit bei mir nie dafür gesorgt, dass das Setup auf dem neuen Gerät "einfach funktioniert". Stattdessen musste ich jedes Mal manuell eingreifen – egal, wie exakt ich die Konfiguration vorbereitet hatte. Die Ursache liegt wohl darin, dass ich meine Umgebung nicht regelmäßig auf mehreren Geräten teste und pflege, sodass die Reproduzierbarkeit für mich eher eine theoretische Eigenschaft blieb als ein praktischer Vorteil. Im Gegensatz dazu gewinnt bei mir die einfache Sicherung meiner Daten deutlich mehr an Bedeutung.
Es ist mir wichtiger, regelmäßig Backups meiner Nutzerdaten anzufertigen, als über komplexe Paket- und Konfigurationsmanager den kompletten Zustand eines Systems zu archivieren. Denn spannende Probleme entstehen oft nicht durch Paketversionen, sondern durch verlorene oder beschädigte Daten – und hier hilft weder Nix noch ein anderes Paketmanagementsystem. Ebenfalls belastend ist der Speicherplatz, den Nix beansprucht. Der Nix Store frisst auf meinem Mac im Schnitt mehr als 60 Gigabyte Speicherplatz, was angesichts der begrenzten Kapazität besonders teuer ist. Im Vergleich dazu nimmt die komplette Homebrew-Installation auf dem gleichen System gerademal sechs Gigabyte ein. Dabei ist zu beachten, dass ich bei Nix stets regelmäßig das Garbage Collection-Tool ausgeführt habe, um nicht mehr benötigte Dateien zu entfernen.
Die Tatsache, dass trotzdem so viel Speicherplatz bestehen bleibt, zeigt, wie datenintensiv Nix arbeitet und wie stark der Overhead sein kann – etwas, das in Zeiten von immer schneller ausgebauten SSDs und vor allem bei kleineren Geräten mehr als störend wirkt. Die Komplexität rund um Beitragsleistungen und Erweiterungen erschwert die Motivation, Nix aktiv mitzugestalten. Das Nixpkgs-Repository ist riesig und beim Klonen und Aktualisieren von nur eingeschränkten Klonen mit beschränkter Historie fallen bereits mehrere Gigabyte Daten an – dies verteuert Entwicklungszyklen und hält potenzielle Mitwirkende häufig davon ab, eigene Änderungen einzubringen. Obwohl ich selbst einige Male Beiträge geleistet habe, habe ich festgestellt, dass die meiste Zeit beim Warten auf Git-Prozesse verloren geht, anstatt produktiv am Code zu arbeiten. All diese Faktoren zusammen führten dazu, dass ich meine Einstellung zu Nix überdenken musste.
Ich bin ein eher pragmatischer Anwender, der simple Lösungen bevorzugt und bereit ist, auf komplexe Tools zu verzichten, wenn sie den Arbeitsalltag nicht vereinfachen. Nix ist sehr mächtig, keine Frage, und für spezifische Fälle wie das Betreiben von Servern oder das Verwalten von Entwicklungsumgebungen in Teams bietet es unschätzbare Vorteile. Für den persönlichen Einsatz auf einem Laptop oder Desktop-Rechner sehe ich jedoch keine Notwendigkeit für eine so komplexe Struktur, die mit hohem Aufwand verbunden ist. Als Ersatz habe ich mir eine schlanke Shell-Skript-Lösung geschrieben, die für meine persönlichen Bedürfnisse komplett ausreicht. Ich setze wieder auf Homebrew für die Paketverwaltung auf meinem Mac, was mir deutlich mehr Freiheit, Geschwindigkeit und vor allem weniger Frust beim täglichen Arbeiten bringt.
Meine Linux-Rechner laufen zwar noch mit NixOS, aber ich spiele mit dem Gedanken, auch hier mittelfristig umzusteigen, weil ich die einfache Verwaltung und geringeren Overhead vorziehe. Letztlich schätze ich die Einfachheit und Klarheit, die ich zurückgewonnen habe – wenig Komplexität, wenig unnötiger Ballast und mehr Zeit fürs Wesentliche. Nix hat für mich seine Daseinsberechtigung nicht verloren, aber in meinem persönlichen Kontext ist es einfach nicht das richtige Werkzeug mehr. Manche Werkzeuge sind besser geeignet für komplexe Umgebungen mit hohem Anspruch an Reproduzierbarkeit und Teamarbeit. Andere, wie meine jetzige Lösung, passen perfekt, wenn man pragmatisch und effizient sein will. Zusammenfassend ist es wichtig zu verstehen, dass technische Entscheidungen stark von individuellen Bedürfnissen abhängen. Was für einen Entwickler ideal ist, kann für einen anderen im Alltag mühsam und zeitintensiv sein.
Die Welt der Softwareentwicklung bietet viele Optionen, und es lohnt sich immer, offen zu bleiben, Neues auszuprobieren und gegebenenfalls auch altbewährtes zu schätzen. Ich hoffe, meine Einblicke helfen dabei, informierte Entscheidungen im Bereich der Paket- und Konfigurationsverwaltung zu treffen und das Richtige für den eigenen Workflow zu finden.
