Was lässt sich nach knapp einem halben Jahr über NixOS sagen? Ist es für den "Normalo" zu schwierig? Wie performt es?
Vor einem halben Jahr bin ich zu NixOS gewechselt und nutze es auf allen meinen Rechnern. Zeit für eine ehrliche Zwischenbilanz.
Das Fazit zuerst
Starkoch Nixos kocht noch immer. Die Küche ist aufgeräumt, die Speisekarte als einzige Quelle der Wahrheit ist der Königsweg – und das in drei Restaurants gleichzeitig.
Die beste Erfahrung: NixOS hat mich in den letzten sechs Monaten nie im Stich gelassen, obwohl ich nicht zimperlich mit ihm umgegangen bin. Kein einziger Paketkonflikt, obwohl ich fast alles aus dem Unstable-Branch beziehe – kein zerschossenes System, obwohl ich massiv an der Konfiguration gebastelt habe – der Grundstock ist nach wie vor die Erstinstallation. Ich hatte wirklich immer einen voll arbeitsfähigen Rechner, was mich zwar maximal erfreute, aber es irritierte mich zu Beginn auch irgendwie. Denn nach meiner bisherigen Erfahrung mit Basteln an Linux wäre so stümper- und laienhaftes Schrauben am System unweigerlich mit einem einsam blinkendem Curser auf schwarzem Grund bestraft worden. Mittlerweile ist es mir zur beruhigenden Gewissheit geworden, dass ich immer auch einen Schritt zurück machen kann (1-Klick-Rollback beim Reboot), sollte die neue Konfiguration noch nicht passen.
Ich hatte Probleme, nicht wenige(!), aber diese hatten weniger mit NixOS, als überwiegend mit Git bzw. Codeberg zu tun. NixOS ist ein absolut großartiges Desktop-Linux, aber noch beeindruckender sind die Möglichkeiten, die diese Distribution für eine Multi-Host-Umgebung (also eine Nix-Konfiguration für mehrere Rechner) bietet. Ich hatte die dahingehenden Möglichkeiten von Flakes in Teil 2, Teil 3 und einem weiteren Beitrag in meinem Setup-Guide beschrieben. An Git führt dann aber kein Weg vorbei. Nur ... – Git ist so eine Bit**, es duldet nur die 100%ige und vollständige Unterwerfung vor den Regeln – schlecht, wenn man diese noch nicht so drauf hat. Zum Glück ist NixOS selbst aber extrem robust und stabil, es hat sich durch meine wilde Lernkurverei nie aus der Bahn werfen lassen.
Wenn ich in NixOS mehr verändern möchte, als nur ein Paket zu installieren, schaue ich immer zuerst in die Dokumentation (Wiki und die Options), damit ich den Grundgedanken der Konfiguration in der Nix-Sprache verstehe. Das Suchen in Foren war immer eine Sackgasse. Dagegen lasse ich mir meinen Entwurf für veränderte Konfigurationsdateien (.nix, ich nenne sie liebevoll "Nixen") immer von einer freundlichen KI gegenchecken. Gleiches gilt für die Interpretation von Fehlermeldungen, welche ich oft als Reaktion auf meine Experimente zurückbekam. Diese Fehlermeldungen (generiert vom Nix-Evaluator) sind übrigens bemerkenswert, da sie ziemlich ausführlich, konkret und präzise ausfallen, keineswegs nur eine Fehlernummer mit Benennung. Mit dem beschriebenen Vorgehen bin ich als Novize gut gefahren.
Ich schrieb ja schon ziemlich zu Beginn, also voll in meiner Anfangseuphorie, dass Distro-Hopping durch NixOS ein Ende gefunden hat. Daran hat sich tatsächlich nichts geändert, nach einem halben Jahr mit NixOS gibt es kein Zurück mehr. Die Idee des Deklarativen (siehe Teil 1 meines Setup-Guides) hat sich eingebrannt und begeistert mich bis heute ungebrochen.
Was brillant funktioniert
Das Versprechen der Reproduzierbarkeit. Ich betreibe mittlerweile drei Rechner mit NixOS: einen Dell 5320, einen Dell Pro Plus und ein Surface Go 2 (welches mein altes Lenovo ersetzte). Alle drei laufen mit der gleichen Basis-Konfiguration. Wenn ich auf einem Rechner etwas ändere, landen die Änderungen via Codeberg auf allen anderen – mit einem einzigen Befehl. Das klingt nach einem kleinen Kunststück – aber genau das ist NixOS.
Rollbacks retten Leben. Zweimal bootete ein Rechner nach einem Rebuild (mit von mir verursachten Konfigurationsfehlern) nicht mehr – einmal der Dell 5320 wegen einer falschen UUID in der hardware-configuration.nix, einmal das Surface wegen eines von mir verursachtem Kernel-Konflikts. Beide Male: Neustart – ältere Generation im Bootmenü wählen – fertig. Auf anderen Systemen wäre das eine Neuinstallation geworden. Bei NixOS war es ein Klick. Und das ist schon beeindruckend – und ungemein beruhigend. Der Arbeitstag kann dann in jedem Fall erstmal normal weiter laufen.
Das Update-Skript. Von Beginn an erstellte ich mir kleine Skripte für die Shell (in meinem Fall die Fish-Shell), welche Arbeitsschritte zusammenfassen. Klar, ein Update funktioniert bei NixOS tatsächlich mit nur einem Befehl, aber wenn man wie in meinem Fall Flakes nutzt, muss es ja noch über Git zu Codberg und committet werden. Was als einfaches nixos-rebuild switch begann, ist heute eine vollständige Fish-Funktion namens update, die automatisch erkennt, ob ein Rechner hinter Codeberg zurückliegt oder lokale Änderungen hat – und dann das Richtige tut. Kein Nachdenken mehr darüber, ob ich eine aktualisierte Konfiguration auch wirklich via Git zu Codeberg transferiert hatte.
Konkret funktioniert das so: Mein Skript update vergleicht zunächst den lokalen Git-Stand mit dem auf Codeberg. Hängt der aktuelle Rechner hinter Codeberg zurück – zum Beispiel, weil auf einem anderen Rechner Änderungen gemacht wurden – holt es automatisch den aktuellen Stand und baut das System neu. Hat der aktuelle Rechner hingegen neue lokale Änderungen, aktualisiert es die Paketversionen, baut das System, bereinigt den Nix-Store und sichert alles auf Codeberg. Sind beide Seiten auf dem gleichen Stand, wird trotzdem ein Update der Pakete angestoßen – damit kein Rechner aus Versehen veraltet.
Darunter liegen drei Funktionen, die ich zunächst als separate Skripte hatte: update-push für das bewusste Aktualisieren und Sichern, pull-update für das Holen und Bauen vom Codeberg-Stand, und rebuild für den schnellen lokalen Neuaufbau ohne Git.
Und die Weiterentwicklung in Form des Skripts update steht auch Dir zur Verfügung. Die verlinkten Konfigurationsdateien aus dem Teil 2 meines Setup-Guides habe ich seither aktualisiert.
Multi-Host-Setup. Durch das mehrfach verbesserte und nun finale Update-Skript konnte ich meine selbst- und hausgemachten Git- und Codeberg-Probleme überwinden. Seither ist die Freude an der Multi-Host-Performance von NixOS ungetrübt. Kleines Beispiel: Ich hatte meine Tochter immer um ihr schickes kleines Surface Go 3 beneidet, deshalb kaufte ich mir nach dem Tod meines alten Lenovo (ich berichtete HIER von der Einbindung) ein gebrauchtes Go 2 mit M3-Prozesser. Unter den Ultra-Portablen PCs mit Tablet-Funktion, ist die Surface-Go-Serie in meinen Augen ein herausragend wunderbares Stück Hardware – einen kleinen portablen Rechner brauche ich einfach auch (hauptsächlich für den Urlaub). Trotz einer abgespeckten Programmauswahl und weniger Verknüpfungen mit Netzwerklaufwerken, lässt sich der kleine Rechner dennoch super in die gemeinsame Grundkonfiguration einbinden und auch dort verwalten. Die oben verlinkte Anleitung beschreibt das Vorgehen. Die für das Go 2 angepassten "Nixen" verlinke ich ganz unten.
Performance. Beispielsweise das erwähnte Surface Go 2 (mit dem M3-Prozessor) läuft mit dem Standard-NixOS-Kernel (einen angepassten Surface-Kernel braucht es nicht) unter NixOS um Welten flüssiger, als das leicht bessere Go 3 meiner Tochter mit dem i3 unter Ubuntu.
Generell muss ich sagen, dass NixOS extrem flüssig auf jeder meiner Maschinen läuft. Auf dem Dell5320 hatte ich ja vorher CachyOS, das lief keine Spur besser.
Wo es wirklich gehapert hat
Git und Codeberg waren mein Erzfeind, mein Endgegner, "aarrrrghh". Der SSH-Key für root fehlte. Branches liefen auseinander. Push-Fehler wegen nicht-linearer Historie. Falsche UUIDs in der hardware-configuration.nix die irgendwann beim falschen Rechner gelandet waren. Ich habe mindestens ein Dutzend Mal sudo git reset --hard origin/master eingegeben – manchmal notgedrungen, manchmal weil ich es schlicht vergessen hatte vorher zu pullen. Aus diesen selbst eingebrockten Frust-Momenten entstand das Skript update, welches mich vor eigenen Fehlern im Umgang mit Git schützt.
Die ehrliche Diagnose: Die Git-Workflows bei einem Multi-Host-Setup sind nicht trivial. Man muss verstehen, dass Codeberg die Quelle der Wahrheit ist – und immer dann, wenn man das vergisst, rächt es sich. Ich habe es oft vergessen.
Die flake.nix ist nicht fehlerverzeihend. Ein fehlendes Anführungszeichen, ein falscher Attributname, ein home-manager.users.retorix das für zwei von drei Rechnern vergessen wurde – und das System baut nicht, oder schlimmer, es baut aber lässt danach alle Programme verschwinden. Der Nix-Evaluator gibt aber geduldig so lange erläuternde Fehlermeldungen, bis man den Dreh (evtl. mit KI-Unterstützung) raus hat.
Der fehlerhafte Nextcloud-Client. Ausgerechnet der für mich so wichtige Nextcloud-Client machte als normales Paket Probleme. Das selektive Auswählen von Synchronisationsordnern war im Paket fehlerhaft. Die Internet-Recherche ergab, dass es ein bekanntes Problem ist, die Flatpak-Version aber fehlerfrei sein soll. Somit musste ich in den sauren Apfel beißen (ich mag keine Container) und nur für dieses eine Programm auf meinem System Flathub einrichten. Tatsächlich waren damit dann aber auch die Probleme mit dem Nextcloud-Client gelöst.
Zeitaufwand für ein Update. Das ist nur eine Anmerkung, nichts was einschränkt, oder gar störend ist – ich möchte es aber erwähnen. Da NixOS ja bei jedem Update den Nix-Store neu sortiert, das System nach der geänderten Deklaration neu baut und den alten Ballast von Bord wirft, dauert ein Update länger, als z.B. ein sudo pacman -Syu auf einem Arch-Linux-System. Parallel weiterarbeiten ist aber kein Problem. Dafür ist das System aber stets frisch und clean gebaut, so als wäre es eine Neuinstallation.
Was ich gelernt habe
NixOS ist nicht das superschwierige Nerd-System. Die Konfigurationsdateien folgen einer glasklaren Logik, die man einmal verstehen muss – und dann läuft es, auch wenn es zu Beginn manchmal ruckelt.
Was ich unterschätzt hatte: die Werkzeuge rund um NixOS (Git, Codeberg, Flakes, Home-Manager) bilden zusammen ein Ökosystem, das man erst kennenlernen muss – da stecken die steilen Rampen in der Lernkurve - aber eben nur dann, wenn man ein Multi-Host-Setup anstrebt.
In Teil 2 schrieb ich:
Es gibt viele technische Gründe für die "Gewaltenteilung" im System, mich persönlich überzeugt aber ein eher philosophischer Grund am meisten: Semantische Klarheit: configuration.nix beschreibt, was das System ist, home.nix beschreibt, was Du bist. Das ist keine technische Notwendigkeit, sondern eine gedankliche Ordnung, die sich auszahlt, sobald die Konfiguration dann doch mal wächst.
Dazu stehe ich auch heute noch, würde aber nach meinem wilden Ritt mit Git und Codeberg heute dazu anmerken:
Gib der deklarativen Idee von NixOS unbedingt eine Chance, bleib aber bei nur einem oder zwei Rechnern erstmal bei der ausschließlichen Konfiguration über die configuration.nix, so wie in Teil 1 meiner Setup-Reihe beschrieben.
Wenn jemand aufgrund meiner Impulse ebenfalls bei NixOS gelandet ist, würde ich mich über einen Kommentar freuen; aber jeder andere Beitrag zu NixOS interessiert mich natürlich ebenso.
Ressourcen
Hier die Konfigurationsdateien für das Go 2. In der flake.nix (siehe Download in Teil 2) ist das Surface natürlich als Teil des Multi-Host-Setups ebenfalls mit aufgeführt:
surface-system.nix
home-surface.nix
GNU/Linux.ch ist ein Community-Projekt. Bei uns kannst du nicht nur mitlesen, sondern auch selbst aktiv werden. Wir freuen uns, wenn du mit uns über die Artikel in unseren
Chat-Gruppen oder im
Fediverse diskutierst. Auch du selbst kannst Autor werden. Reiche uns deinen Artikelvorschlag über das
Formular auf unserer Webseite ein.
