Warum ich bei NixOS gelandet bin

Vor NixOS lief auf meinen Rechnern Manjaro. Zwei Dinge haben mich davon weggetrieben. Der Standby war unzuverlässig, und mindestens zweimal kam ich nach einem Upgrade nicht mehr über die Anmeldung hinaus. Beide Male hatte ich keine Zeit, der Ursache nachzugehen und habe die Kiste einfach neu aufgesetzt.

Warum ausgerechnet NixOS

Die Frage liegt nahe, weil ich beruflich mit Konfigurationsmanagement zu tun habe. Ansible und ein dotfiles-Repo wären der kurze Weg gewesen, und ich hätte für beides niemanden fragen müssen.

Für NixOS haben zwei Eigenschaften gesprochen. Erstens ist das ganze Betriebssystem deklarativ beschrieben, nicht nur die Schicht, die ich mit einem Ansible-Playbook nachträglich draufsetze. Zweitens gibt es den Rollback. Ein Update, das die Anmeldung zerlegt, kostet mich damit einen Neustart in die vorherige Generation statt eines Abends.

Der zweite Punkt hat mir die Angst vor Updates von Anfang an genommen. Ich musste NixOS nicht erst vertrauen lernen, ich wusste ab dem ersten Tag, dass ich zurückkomme.

Angefangen habe ich in einer VM

Die erste NixOS-Installation lief in einer VM. Fünf Tage später kam ein echtes Gerät dran, und zwar das unwichtigste, das ich hatte: ein goldenes Huawei-Notebook-Notebook von 2017, das seit einem Jahr im Schrank lag, weil ich längst auf einem Tuxedo arbeitete.

Auf dem alten Notebook lief NixOS dann so schnell wie nie zuvor. Ein Gerät, das ich ein Jahr lang nicht angefasst hatte, war wieder brauchbar.

Zwei Monate später kam das Tuxedo dazu, auf dem bis dahin ebenfalls Manjaro lief. Tuxedo unterstützt NixOS mit eigenen Treibern, dafür gibt es bei mir ein kleines Modul in der Konfiguration.

Bis der Desktop an der Reihe war, vergingen weitere vier Monate. Auf dem arbeite ich täglich, deshalb habe ich die Umstellung vorher in der VM durchgespielt.

Was besser wurde

Der Standby funktioniert seit dem ersten Tag, und zwar immer.

Der zweite Gewinn war der erwartete: Ein neuer Rechner ist keine Bastelei mehr. Die Konfiguration liegt im Repo, der Host bekommt seine eigene Datei, und was gemeinsam gilt, teilen sich alle Maschinen.

Und dann die Server

Ein halbes Jahr später kam derselbe Schritt noch einmal, diesmal im Homelab. Ich hatte meinen alten Proxmox-Server durch ein Geekom ersetzt. Auf dem alten lief ein LXC-Container mit Ubuntu, das ich aus dem Beruf kannte. Beim Neuaufbau habe ich stattdessen NixOS in den Container gesetzt. Den alten Server habe ich danach verkauft.

Dafür gibt es ein eigenes Repo. Dieselbe Flake wie für die Workstations wollte ich nicht, weil Server und Arbeitsrechner sauber getrennt bleiben sollten und die Unterschiede zwischen beiden zu groß waren.

Was das bringt, habe ich beim zweiten Container gemerkt. Ich hatte mir ein ZimaBoard 2 gekauft und auch dort Proxmox installiert. Der NixOS-Container darauf war deutlich schneller eingerichtet als der erste: Die Module lagen schon da, geändert hat sich vor allem der Name. Was ich auf dieser Maschine nicht brauchte, habe ich abgeschaltet, was fehlte, kam als neues Modul dazu. Ein weiterer Container kann jederzeit dazukommen.

Das Repo ist trotzdem klein geblieben. 30 Commits, zwei Dateien für die beiden Hosts, elf Module. Wie das Homelab drumherum aussieht, steht in Mein Homelab.

Was nervt

Build-Zeiten. Solange ich Pakete nehme, die schon gebaut sind, merke ich davon nichts. Sobald ich etwas in einer bestimmten Version brauche und es selbst bauen muss, wird es zäh. Und dann fällt dieselbe Bauzeit auf jedem Rechner erneut an, auf dem ich das Paket haben will.

Was ich einem Umsteiger sagen würde

Nicht zu früh generisch werden. Das ist der Fehler, den man mit ein bisschen Erfahrung in Konfigurationsmanagement fast zwangsläufig macht: Man will von Anfang an die saubere Abstraktion, ein Modul für alles. Bei NixOS bezahlt man das damit, dass man erst die Nix-Syntax vollständig verstehen muss, bevor irgendetwas läuft.

Lieber am Anfang Code duplizieren und ein laufendes System haben. Aufräumen kann man später, und dann versteht man auch, was man da abstrahiert.

Ich habe ohne KI angefangen und mir vor allem die Repos anderer Leute angesehen, von denen es reichlich öffentlich gibt. Mit KI-Hilfe wurde es später deutlich einfacher.

Die Skripte

Im Repo liegen inzwischen elf kleine Shell-Skripte rund um Rebuild und Generationen. Vier davon waren schon im allerersten Commit dabei.

Die ersten sind entstanden, weil ich mir die Befehlszeilen nicht merken wollte. Die späteren tun mehr, als eine Zeile zu ersetzen: Generationen vergleichen, anzeigen was sich seit dem letzten Rebuild geändert hat, prüfen ob ein Neustart nötig ist. Ein Teil davon wurde später überflüssig, als ich nh entdeckt habe. Das Werkzeug macht vieles davon von Haus aus und mit einer Ausgabe, die man auch lesen kann.

Nach anderthalb Jahren

Zwei Rechner laufen inzwischen produktiv aus dem Workstation-Repo, dazu die VM, in der ich Dinge ausprobiere, bevor sie auf eine echte Maschine kommen, und die beiden Server aus dem zweiten Repo. Ein paar hundert Commits sind es geworden, ich fasse die Konfiguration regelmäßig an, meistens für Kleinigkeiten.