Warum ich NixOS liebe

• NixOS basiert auf dem Nix-Paketmanager und ist so aufgebaut, dass sich das gesamte System als Code definieren und jederzeit in einen deterministischen, reproduzierbaren Zustand zurückversetzen lässt.
• Alle Konfigurationen und Pakete werden in einer einzigen deklarativen Konfigurationsdatei verwaltet, sodass sich dieselbe Umgebung auch auf neuer Hardware aus einer einzigen Quelle neu aufbauen lässt.
• Es bietet stabile Releases im 6-Monats-Rhythmus, automatische Updates und bei Bedarf Experimente mit aktueller Software über den unstable-Kanal.
• Es stellt isolierte Entwicklungsumgebungen bereit, in denen sich verschiedene Sprachen und Tools ohne Systemverschmutzung ausprobieren lassen, und sorgt für eine konsistente Developer Experience über macOS und Linux hinweg.
• Auch zum LLM-Coding-Zeitalter passt es gut: Trotz schnell wechselnder Tools ermöglicht es mit einem im Vergleich zu Docker deterministischeren und geschichteten Build-Modell Konsistenz bis hin zum Deployment.

---

Die Philosophie und der Reiz von NixOS

• Der Kern von NixOS ist nicht die Linux-Distribution, sondern der Nix-Paketmanager.
  • NixOS ist das Ergebnis eines deterministischen und reproduzierbaren funktionalen Paketmanagers, mit dem sich anhand der eingegebenen Nix-DSL das gesamte Betriebssystem konfigurieren lässt.
  • Das System lässt sich vollständig neu aufbauen oder teilweise ändern, und wenn das Ergebnis nicht gefällt, ist ein Rollback möglich.
• Während die meisten Betriebssysteme mit der Zeit instabiler werden, kann NixOS seinen Zustand definieren und bauen.
  • Dadurch wird verhindert, dass sich durch Paketinstallationen, Konfigurationsänderungen sowie das Hinzufügen und Entfernen von Tools ein unklarer Zustand ansammelt.
  • Da das System als Code definiert ist, lässt sich jederzeit dasselbe Ergebnis reproduzieren.

Deklarative Konfiguration und Verwaltung aus einer einzigen Quelle

• In NixOS lässt sich das gesamte System — Pakete, Einstellungen, Keyboard-Mappings und mehr — in einer einzigen deklarativen Konfiguration definieren.
  • Selbst Detailverhalten wie Einstellungen für GNOME-Erweiterungen oder Keyboard-Mappings lässt sich in der Nix-DSL beschreiben.
  • Auch auf einem neuen Rechner lässt sich das gesamte System aus einer einzigen Quelle neu aufbauen.
• Ohne manuelle Einrichtung oder verstreut verwaltete Skripte lässt sich so ein konsistenter Systemzustand beibehalten.

Stabilität und Update-Management

• NixOS hält einen vorhersehbaren Release-Zyklus von 6 Monaten ein und unterstützt automatische Updates.
  • Probleme wie Instabilität bei typischen OS-Upgrades, störende Benachrichtigungen oder System Drift werden minimiert.
  • Bei Bedarf kann der unstable-Kanal aktiviert werden, um aktuelle Software experimentell zu nutzen.
• Auch auf einem HP-Laptop ist die Hardware-Kompatibilität und Stabilität hoch, sodass es ohne zusätzliche Konfiguration sofort einsetzbar ist.

Experimente und isolierte Entwicklungsumgebungen

• NixOS bietet sichere und kostengünstige Experimentierumgebungen.
  • Pakete müssen nicht direkt im System installiert werden, sondern können in einer isolierten Shell-Umgebung ausgeführt werden.
  • Mit der Nix-DSL lassen sich Abhängigkeiten, Build-Schritte und Artefakte deklarativ definieren, wodurch eine saubere Entwicklungsumgebung ohne Verschmutzung erhalten bleibt.
• Da sich derselbe Nix-Paketmanager sowohl unter macOS als auch unter Linux nutzen lässt, bleibt die Verwaltung von Development-Tools und Abhängigkeiten konsistent.
  • Es gibt auch Community-Support für FreeBSD.

Warum es gut zum LLM-Coding-Zeitalter passt

• LLM-basierte Coding-Tools erfordern häufig den Wechsel zwischen bestimmten Versionen von Utilities, Compilern und Runtimes.
  • Nix behandelt diese Anforderungen als deklarative Inputs für Tools und führt sie in isolierten Umgebungen aus.
  • Beim Build eines Rust-Sprach-zu-Text-Agenten kann Nix zum Beispiel automatisch die Rust-Toolchain laden und eine isolierte Build-Umgebung bereitstellen.
  • Die Systemumgebung (~/.cargo, ~/.rustup, PATH usw.) wird dabei nicht verändert.
• Mit flake.nix und nix flake check lässt sich die Experimentierumgebung eines Agenten als reproduzierbares Artefakt fixieren.
  • Dadurch werden temporäre Sessions in verifizierbare Build-Einheiten überführt.

Deployment und ein konsistentes Entwicklungsmodell

• Nix bietet ein im Vergleich zu Docker deterministischeres und geschichtetes Image-Build-Modell.
  • Mit dockerTools.buildLayeredImage lassen sich kleine und reproduzierbare Docker-Images erzeugen.
  • Mit derselben Konfiguration kann auf unterschiedlichen Architekturen dasselbe Ergebnis gebaut werden.
• Dasselbe Modell gilt konsistent für Laptops, Shells, Projektabhängigkeiten, CI-Pipelines und Deployment-Artefakte.
  • Statt viele verschiedene Tools zu kombinieren, lässt sich das gesamte Softwaresystem mit einer einzigen Denkweise verwalten.

Fazit

• NixOS ist eine konkrete Umsetzung eines deklarativen, reproduzierbaren, rücksetzbaren und stabilen Systems.
• Experimente und Upgrades lassen sich ohne Angst durchführen, und selbst in sich schnell verändernden Tool-Umgebungen verschmutzt es das System nicht.
• Auch für moderne Entwicklungs-Workflows wie LLM-Coding-Agenten bietet es gleichzeitig Stabilität und Flexibilität.
• NixOS ist die vollständigste Alltagsumsetzung dieser Philosophie.

[dongho42]

Ich hatte früher auch etwa ein halbes Jahr lang NixOS benutzt, bin dann aber wieder zu Arch zurückgekehrt, weil ich bei NixOS selbst für eine sehr einfache Aufgabe, für die man bei anderen Betriebssystemen nicht einmal extra suchen müsste, trotz endlosem Googeln keine Lösung finden konnte. Dann habe ich in einem NixOS-Forum die von irgendeinem NixOS-Experten? dokumentierte Lösung gesehen, und als ich sah, dass diese Dutzende Zeilen lange, hackige Lösung die meisten Likes bekommen hatte, wurde mir ziemlich düster, wie mein weiteres Leben mit NixOS wohl aussehen würde...

[dongho42]

Und ich erinnere mich nicht mehr genau, aber ich glaube, es war flake oder irgendeine andere Funktion, bei der es an einem Ort als Best Practice, an einem anderen als experimentell und wieder woanders als beides bezeichnet wird, und als ich gesehen habe, dass das seit Jahren so weitergeht, war der steinige Weg ziemlich offensichtlich..

Natürlich hat es Spaß gemacht, die komplette Desktop-Umgebung einfach als Code abbilden zu können

[pmc7777]

Sogar Firebase Studio verwendet Nix

[laeyoung]

Oh ... ich verstehe!

Übrigens: R.I.P., Firebase Studio T_T

[grenade]

Viel zu schwierig, ich habe es ein bisschen ausprobiert und dann aufgegeben T_T
(I use Arch btw)

[ztaka]

Wer es kennt, nutzt es heimlich still und leise, haha
Ein reproduzierbares Setup, umgesetzt mit einer deklarativen funktionalen Sprache

[ytuniverse]

Die Lernkurve ist absurd steil. So sehr Reproduzierbarkeit garantiert wird, so hoch sind auch die Anforderungen.
Selbst mit flake ist es noch anspruchsvoll.

Außerdem scheint intern etwas wie SQLite verwendet zu werden, und dessen Performance schwankt wiederum, sodass es bei der Zeit, die eine erneute Reproduktion der Umgebung dauert, gewisse Schwankungen gibt.

[GN⁺]

Hacker-News-Kommentare

• Ich denke, NixOS ist in Bezug auf die Kompatibilität mit AI-Tools einzigartig.
  Bei anderen Betriebssystemen ist es schwer, einer AI die Systemkonfiguration anzuvertrauen, aber dank der deklarativen und rollback-fähigen Struktur von NixOS kann man sich darauf verlassen.
  Einen Wechsel von Pulseaudio zu Pipewire oder die Installation von Hyprland würde ich Claude oder Codex nicht überlassen, aber bei NixOS hätte ich sogar genug Vertrauen, es Grok zu übergeben.
  Entscheidend ist die Stabilität, Änderungen vorab prüfen und jederzeit zurückrollen zu können.
  Entwicklerinnen und Entwickler, die von einem „AI-verwalteten Linux-Desktop“ träumen, sollten NixOS ausprobieren. Am besten beginnt man damit, Claude zu sagen: „Erstelle mir eine Flake-basierte Gnome-Konfiguration, die ich in einer VM demonstrieren kann.“

  • Ich nutze seit 3 Jahren NixOS und seit über einem Jahr Claude. Die Kombination der beiden ist wirklich ideal.
    Es ist beeindruckend zu sehen, wie Claude die dconf-Einstellungen von GNOME deklarativ anpasst.
    Allerdings versteht die AI den komplexen Kontext des Nix-Ökosystems oft nicht und produziert deshalb manchmal seltsame Ergebnisse.
    Man merkt, dass die unstrukturierte Lambda-Struktur von Nix und die impliziten Scopes zwischen Modulen nicht nur für Menschen, sondern auch für AI schwierig sind.
    Deshalb ist es wichtig, die Struktur und Muster eines Projekts klar zu definieren. Trotzdem ist das Erstellen Nix-basierter Templates angenehm und produktiv.
  • Ehrlich gesagt wirkt das wie eine übertriebene technische Lösung für ein Problem, das gar nicht existiert.
    Muss man für die Installation von Hyprland wirklich ein LLM einsetzen? Ein einfaches sudo dnf install hyprland reicht doch völlig aus.
    Es wirkt weniger so, als wäre Nix „AI-freundlich“, sondern eher so, als würde man ein LLM verwenden, weil Nix für Menschen umständlich direkt zu handhaben ist.
  • Ich hatte eine ähnliche Erfahrung. Ich habe früher unter dem Namen „ClaudeOS“ einen Beitrag auf HN gepostet, aber in Wirklichkeit war das eine Kombination aus NixOS + Flakes + Claude Code.
    Ich verwalte die Konfigurationen mehrerer Maschinen als „Business-Profile“ und verteile automatisch die jeweils benötigten Repos und Einstellungen.
    Ein Kollege im Unternehmen war ursprünglich Windows-Nutzer, verwendet inzwischen aber ganz selbstverständlich NixOS im Alltag.
    Auch sämtliche Hardware-Einstellungen werden deklarativ verwaltet, und meine Konfiguration liegt in diesem öffentlichen GitHub-Repository. Feedback ist willkommen.
  • Ich habe Claude ebenfalls schon Probleme in meiner NixOS-Konfiguration lösen lassen, und das hat wirklich gut funktioniert.
    Auch beim Umziehen der Konfiguration in eine neue Struktur oder beim Erstellen mehrerer WM/DE-Testumgebungen übernimmt Claude den Großteil der wiederkehrenden Arbeit.
    Inzwischen ist mein System vollständig stabil, sodass ich kaum noch etwas manuell tun muss.
    Bei anderen Betriebssystemen hätte ich dieses Vertrauen nicht.
  • Früher wirkte Nix auf mich so schwer zugänglich, dass ich darauf gewartet habe, bis AI weit genug ist.
    Stattdessen habe ich meine Entwicklungsumgebung mit Docker-Skripten verwaltet, aber inzwischen fühlt sich die Kombination aus Nix und AI perfekt an.
    Ich glaube, in Zukunft werden viele Softwaresysteme erscheinen, die sich mit AI deutlich leichter bedienen lassen.

• Nach 30 Jahren mit Windows bin ich vor einem Jahr komplett zu Nix gewechselt.
  Jetzt gibt es für mich überhaupt keinen Gedanken mehr daran, zu Windows zurückzukehren.
  Ich liebe es, dass die komplette OS-Konfiguration in einem Git-Repository liegt.
  Ohne Nix zu entwickeln ist genauso ineffizient wie Programmieren ohne Git.
  Wenn man es einmal eingerichtet hat, ist das Aufsetzen neuer Systeme danach sehr einfach.

  • Ich frage mich, ob es ein Projekt gibt, mit dem man auf Basis meiner NixOS-Konfiguration leicht isolierte Container erstellen kann.
    Ich möchte jede App in einer unabhängigen Umgebung ausführen, ohne dass das gesamte System beeinflusst wird.
    Ich denke, NixOS ist einer der Wege in genau diese Zukunft.
  • Ich wollte zeitweise zu Fedora Bazzite zurückkehren, bin aber bei NixOS geblieben, weil sich HDR unter Sway dort stabiler umsetzen lässt.
    Auch Nvidia-GPUs funktionieren gut, und es ist deutlich stabiler als Gamescope.
  • Ich würde gern Beispiele sehen, wie man nix-shell nutzt, um Python-Skripte schnell auszuführen. Ich lerne noch, wie Python und NixOS zusammenspielen.

• Ich würde NixOS gern mehr mögen, aber das größte Problem ist die mangelnde Dokumentation.
  Informationen sind über verschiedene Foren, alte Blogs und Issues verstreut.

  • Dazu kommt, dass es zwei offizielle Wikis gibt (nixos.wiki, wiki.nixos.org), was verwirrend ist.
    Beide werden aktualisiert, aber je nach Suche wirkt jedes Mal ein anderes aktueller.
  • Früher habe ich mich auch über die fehlende Dokumentation beschwert, inzwischen denke ich aber, dass der Quellcode selbst die Dokumentation ist.
    nixpkgs zu klonen und direkt zu lesen ist am schnellsten.
  • ChatGPT ist ziemlich nützlich darin, Material aus verschiedenen Quellen zusammenzutragen und funktionierende Codebeispiele zu erzeugen.
  • Viele Nutzer lesen die Dokumentation ohnehin nicht, sondern lassen Claude Code den Nix-Code schreiben.

• Ich habe NixOS als Laptop-OS ausprobiert und dabei sehr klare Vor- und Nachteile erlebt.
  Die deklarative Konfiguration und die Snapshot-Funktionen sind revolutionär, aber die Trennung zwischen Paketen und Services sowie das Flake-Konzept waren verwirrend.
  Bei der KDE-Installation wurde nur eine Minimal-Konfiguration installiert, sodass zusätzliche Einrichtung nötig war, und die Dokumentation unterschied sich je nach Version so stark, dass sie schwer nachzuvollziehen war.
  Am Ende habe ich aufgegeben, weil ich eine stabile Maschine brauchte, aber für Systemadministratoren scheint es eine hervorragende Wahl zu sein.

  • Auch für mich war Flake am Anfang schwer zugänglich, aber in Wirklichkeit ist es die intuitivste Art, damit zu arbeiten.
    Der Installer von Determinate Systems aktiviert Flake standardmäßig.
    Man kann die Konfiguration aus /etc/nixos in ein Git-Repository verschieben, und mit dem Befehl nixos-install --flake <repo> lässt sich eine vollständige Konfiguration ausrollen.
    Mit Home-manager kann man sogar das Benutzerverzeichnis deklarativ verwalten.
    Dateien in /etc lassen sich über environment.etc verwalten, Dateien in .config über Home-manager-Optionen.
    Relevante Links: Option environment.etc, Home-manager-Optionen
  • Ich musste lachen, als ich nach Dokumentation zu mkOutOfStoreSymlink gesucht habe und die Antwort lautete, das sei „so einfach, dass es keine Dokumentation brauche“.
    Trotzdem sind die Vorteile von NixOS so groß, dass ich gerade vollständig umziehe: Homelab → Laptop → Desktop.
    Die Dokumentationslage bleibt allerdings weiterhin hoffnungslos.
  • Flake hat zwei Aufgaben:
    1. Es deklariert die Eingaben und Ausgaben einer Codebasis.
    2. Es pinnt die Versionen der Eingabequellen.
       Es übernimmt also auf Nix-Ebene die Rolle von package.json und einer Lock-Datei.
  • Ich frage mich, warum noch niemand LLMs genutzt hat, um die Dokumentation zu verbessern.

• Ich mochte NixOS schon früher, aber seit dem LLM-Zeitalter noch mehr.
  Wenn ich Codex sage: „Ändere diese Serverkonfiguration so, dass Wildcard-Zertifikate funktionieren“, ist das in 5 Minuten erledigt.
  Reproduzierbare Serververwaltung war noch nie so einfach.

• Seit ich zu NixOS gewechselt bin, fühlt sich die Zeit mit apt oder brew wie Technik aus der Steinzeit an.
  Auch mit AI-Tools wie Copilot harmoniert es hervorragend.

  • NixOS ist zu 95 % großartig, aber die restlichen 5 % sind sehr schmerzhaft.
    Um Probleme zu lösen, braucht man ein tieferes Verständnis als bei gewöhnlichem Linux.
    Dafür bezahlt man die Komplexität einmal im Voraus.
  • Ich habe 20 Jahre lang verschiedene Linux-Distributionen genutzt, aber NixOS ist die erste, bei der ich das Gefühl habe: „Das ist die richtige Lösung.“
    Mit nix-shell temporär etwas zu installieren oder in einer einzigen Konfigurationsdatei alle installierten Pakete zu sehen, ist großartig.
    Dank automatischer Snapshots habe ich keine Angst vor Experimenten. Wenn etwas schiefgeht, boote ich einfach die vorherige Generation.
    Früher hatte ich Angst davor, Kernel-Parameter zu ändern, heute probiere ich es einfach aus.
    Weil ich Lisp mag, habe ich auch Guix System in Betracht gezogen, aber in der Praxis ist NixOS nutzbarer.

• Ich wünschte nur, NixOS hätte nicht diese ungewöhnliche Dateisystemstruktur.
  Dieser Ansatz soll zwar das Problem lösen, mehrere Python-Versionen gleichzeitig zu nutzen, aber für mich ist das unnötig.
  Ich möchte einfach nur auf allen Maschinen dieselbe Konfiguration beibehalten.
  Aktuell experimentiere ich mit Fedora-bootc-Images und Podman, aber dort fehlt eine sofort wirksame Funktion wie nixos-rebuild switch, was unpraktisch ist.
  Am Ende ist es ein Trade-off zwischen leicht experimentierbarem Nix und Fedora mit Standard-Dateisystem.

• Der größte Vorteil von NixOS ist die deterministische Reproduzierbarkeit des CI-Caches.
  Man muss Pakete nicht jedes Mal neu bauen, und auch das Einrichten von Entwicklungsumgebungen ist einfach.

  • Nix in CI zu verwenden ist wirklich eine hervorragende Kombination.
    Tangled hat zum Beispiel sein gesamtes CI-System mit Nix aufgebaut und damit die Caching-Probleme von GitHub Actions vollständig gelöst.

• Ich nutze nicht das ganze System, aber devenv.sh sehr gern.
  Damit lässt sich eine Entwicklungsumgebung viel einfacher aufsetzen als mit lokalen Containern.

  • Allerdings ist die Methode für Version Pinning nicht besonders klar.
    Mir fehlt eine einfache Möglichkeit, Versionen wie in .tool-versions von asdf abzugleichen.
    Im Nix-Umfeld heißt es oft: „Das ist der falsche Ansatz“, aber ich möchte einzelne Versionen trotzdem weiterhin pinnen.
  • Mich würde interessieren, worin der Unterschied zu home-manager besteht.
  • Mit einem einfachen pkgs.mkShell kann man eine ähnliche Umgebung bauen, daher frage ich mich, warum man unbedingt devenv nutzen sollte.

• Ich mag NixOS auch, aber Guix bevorzuge ich noch mehr.
  Mit der Sprache Guile bin ich vertrauter, und auch die Dokumentation ist besser. Ich sehe die beiden Systeme als Schwesterprojekte.

  • Ich finde, Guix sollte viel mehr Aufmerksamkeit bekommen.
    Dass es eine echte Programmiersprache (Scheme) verwendet, ist ein großer Vorteil.
    Das bietet eine viel stärkere Grundlage als eine bloße Konfigurationssprache.