Linux im Ehrenamt: NixOS muss einsteigerfreundlicher werden

Während bei dem Linux -Betriebssystem NixOS vieles rosig aussieht, zeigen sich Probleme mit den Ansätzen der Community. Eine Lösung dafür gibt es.

4. Juli 2022 um 08:59 Uhr / Ein IMHO von Lennart Mühlenmeier

Das Logo von NixOS zeigt sechs Lambdas und heute einen Daumen hoch. Bild: Sincerely Media / Unsplash-Lizenz

"Wir sind eine kleine Distribution, eher ein Start-up, können schnell etwas ändern," sagte mir Janne Heß im Mai 2022 bei einer ersten Vorstellung von Nix . Heß war der Release Manager für die kürzlich veröffentlichte Generation des Linux-Betriebssystem NixOS 22.05 . Zu dem Betriebsystem gehört die Programmiersprache Nix und das Paket-Repository Nixpkgs. Schon im Mai ließ ich andeuten: Die Einstiegshürden bei diesem Open-Source-Projekt sind zu hoch.

Nix ist toll, viel mehr sollten es mitentwickeln! In seiner Dissertation warf der Nix-Schöpfer Eelco Dolstra die zentrale Frage auf, die mit Nix beantwortet werden soll: Wie kann man Software auf verschiedenen Systemen deployen, ohne dass dabei alles kaputt geht? Die Problemstellung löst NixOS meines Erachtens nach erstklassig. Mit einer zentralen Konfigurationsdatei lässt sich das gesamte System beschreiben und bauen. NixOS-Systeme sind somit deklarativ, reproduzierbar und verlässlich, wie der Slogan des Projektes richtig zusammenfasst.

Dass die Community schnell etwas ändern kann, zweifele ich nicht an. Doch es bestehen Probleme organisatorischer und technischer Natur, die viele Linux-Communitys haben: Abhängigkeiten zu anderen Projekten, Überforderung des Teams, wenig Geradlinigkeit bei wichtigen Entscheidungen. In dieser Analyse gehen wir diesen unterschiedlichen Punkten exemplarisch an NixOS nach und zeigen: Die vornehmlich ehrenamtliche Community kann das schaffen, gerade wenn sie die hohen Einstiegshürden nimmt und mehr Unterstützung durch weitere Entwickler bekommt.

1. Schwieriger Installationsprozess

Allein schon der Installationsprozess war lange Zeit sehr schwierig: Man musste von einer ISO booten und hatte nur die Kommandozeile vor sich. Von da aus musste alles von Hand gemacht werden – gerade auch die Konfigurationsdeklarationen, die Anfängern wohl eher nicht geläufig sind.

Mittlerweile gibt es zwar einen grafischen Installer, der die erste Erstellung der Konfigurationsdateien und Formatierungen der Festplatten erleichtern soll. Er basiert auf dem generischen Installer Calamares . Nur unterstützt der Installer noch nicht alle Feinheiten von Nix. Zudem ist er laut dem dazugehörigen Pull Requests (PRs) und angemerkten Mängeln noch nicht stabil genug für einen Einsatz.

So muss dann mitunter doch auf die herkömmliche Methode zurückgegriffen werden. ( Das Projekt Nix-Gui versucht derweil, das komplette System langfristig mit einer grafischen Benutzeroberfläche verwaltbar zu machen.)

2. Code is documentation?

Zwar gibt es die sogenannten Nix Pills , die die Konzepte erklären sollen, und ein Manual , das im Prinzip alles erklärt. Auch wird die Website von NixOS stetig aktuell gehalten und simplere Aspekte werden erklärt . Jedoch zeigt sich immer wieder, dass für das Paket-Repository Nixpkgs immer noch der Code die Dokumentation ist.

Um verstehen zu können, wie Software eingesetzt und deployt werden kann, müssen all zu oft die entsprechenden Module gelesen werden. Beispielsweise hat das Nextcloud-Modul derzeit auf dem Master-Branch um die 1.000 Zeilen Code. . Diesen gilt es zu lesen und zu verstehen.

Die Suche unter search.nixos.org macht zwar die Optionen der Module wie services.nextcloud.config für die genaue Konfiguration durchsuchbar. Jedoch geht es über die deklarierten Beschreibungen (noch?) nicht hinaus. Module generieren die softwareeigenen Konfigurationsdateien. Zum Beispiel entstehen mit dem NixOS-Modul mehrere PHP-Dateien im Datenordner, die ansonsten von Hand angepasst werden müssten.

Auch dass Howtos und Handons schnell veraltet sind (siehe folgenden Punkt 3), führt wiederum dazu, dass der Code die Dokumentation ist. Dieser Zustand ist in dem Sinne nicht haltbar, weil er Einsteigern, die noch nicht versiert in der Programmiersprache Nix sind, das Lernen erschwert.

3. Bitte mehr Konsistenz – gerade bei Modulen

Bei nahezu jedem Release von NixOS werden Moduloptionen umbenannt, entfernt und erweitert. Ein gängiger Kritikpunkt diesbezüglich ist, dass mit jedem Versionssprung dementsprechend die Konfigurationen überarbeitet werden müssen. Das wird zwar sehr gut und verständlich im Manual dokumentiert. Nur sollte mehr Konsistenz herrschen, wie diesbezüglich in IRC-Channels diskutiert wurde. All zu oft wirken die gravierenden Änderungen eher wie geschmackliche Wünsche, als dass sie nachvollziehbar sind.

4. Onboarding von Committern fragwürdig

Das Onboarding von Committern ist – salopp gesagt – fragwürdig. Beitragende haben das Recht, Code per Pull Request in den Hauptzweig einzupflegen. In einem stetig offenen Issue werden neue Committer vorgeschlagen und mitunter von der Community bewilligt. Zur Veröffentlichung im Mai 2022 gab es 176 Committer. Der Entscheidungsprozess ist zwar transparent, aber objektive Kriterien gibt es nicht.

Nix zu verlieren

5. Fehleranfälliger Merge-Prozess

Im April 2022 hat sich ein Maintainer im Discourse-Forum beschwert , weil der Development-Prozess "nicht nachhaltig" sei. Der Maintainer paketiert unter anderem Cuda-Pakete, die unfrei sind. Daraus ergibt sich, dass gewisse Buildtests, die über Nix bereit gestellt werden, nicht laufen können.

Der Maintainer bringt aber ein eklatantes Problem auf den Punkt. Er sagt: "Jeder fügt Commits zu einem Branch hinzu, und dann findet ein von Menschen geführter, fehleranfälliger Prozess statt, um sie alle in Master zusammenzuführen" . Bei Reviews können zum Beispiel Fehler übersehen oder bewusst ignoriert werden. Als Lösung schlägt er Merge Trains vor: Diese automatisiere den Merge-Prozess und garantiere, dass der Master immer stabil bleibt.

6. Bauen von Generationen braucht zu viel Power

Auf älteren Geräten kann das lokale Bauen einer neuen Generation des Betriebssystems mehrere Stunden dauern. Das sollte man wissen. Auf meinem Thinkpad X260 (Baujahr 2016) habe ich öfters bis zu mehreren Stunden eine Load von 80 und das Gerät ist der Überhitzung nahe, wenn ich das System neu baue.

Ein Ausweg für dieses Problem wäre ein Build Server, der das Bauen der Software übernimmt und dann die Ergebnisse rüberkopiert. Aber auch dies ist teuer: Man braucht viel Power durch gute CPUs und RAM-Riegel.

Ohne NVMe-SSD würde ich heutzutage kein NixOS mehr betreiben wollen. Auf meinem Arbeitslaptop – einem Thinkpad X13 (Baujahr 2021) – flutschen die Builds nahezu durch in Sekundenschnelle. Zugegeben ist mein privates Set-up komplexer und damit rechenintensiver.

7. Unbekannter Scope von Nixpkgs

Der vorher erwähnte und im vorherigen Erfahrungsbericht vorgestellte Contributor Lassulus wies mich im Gespräch zudem darauf hin, dass Nixpkgs einen unbekannten Scope habe. Er würde diesen Zustand als "Scope Creep" bezeichnen: Es ist unklar, welche Software inwiefern unterstützt und packetiert werden solle. Zudem gebe es wenig Fokus bei der Arbeit an Nixpkgs: "Wir wollen alles machen, aber wenn die Software keiner benutzt, wird sie auch nicht maintained."

8. Enge Bindung an Github

Nahezu jegliche Entwicklung an Nix, NixOS und Nixpkgs geschieht auf Github. Dort können Contributors Pull Requests stellen, Nutzer Issues aufmachen und Committer mergen. Zwar gibt es noch das Discourse-Forum , Matrix- und IRC-Channels, in denen Features diskutiert werden.

Aber andere Wege, daran beizutragen, fehlen. Zum Beispiel wurde die Mailingliste Nix-devel abgeschaltet . Man macht sich abhängig von Github und seinem Betreiber Microsoft sowie deren Entscheidungen. Sollte sich jemand – auch abseits von Nix – auf Github im Sinne Microsofts falsch verhalten und gebannt werden, gibt es keine Möglichkeit mehr, beizutragen.

Fazit: Bitte einsteigerfreundlicher werden

Um die genannten Probleme zu beheben, bedarf es mehr Struktur und vor allem geringerer Hürden für Einsteiger. Mit schnellem Wachstum kommen auch eher neue Problemstellungen. Wenn also Neue leichter und unkompliziert integriert werden können, sind diese Probleme eher lösbar.

IMHO ist der Kommentar von Golem.de. IMHO = In My Humble Opinion (Meiner bescheidenen Meinung nach)