Gewohntes durch Neues zu ersetzen, strengt immer zusätzlich an. Das gilt auch für das besonders im Debian-Lager umstrittene Systemd. Mit einer salomonischen Entscheidung hat das Projekt jetzt eine klare Linie in Sachen Init-System vorgegeben, freut sich Jens-Christoph Brendel.
Hornbrille, Colaflasche, Kapuzenpulli – was kann man noch zu den Insignien eines echten Nerds zählen? Eines auf jeden Fall, und das gerade auch in der Unix-Welt: religiösen Eifer. Mit einem Fanatismus, der jenen der Glaubenskriege Low Carb versus No Fat weit in den Schatten stellt, bekämpften sich schon die seligen Veteranen im Editor War, Vi contra Emacs.
Richard Stallman, der in den frühen 1980-ern an GNU Emacs bastelte, gründete die Church of Emacs und erhob sich im Sommer 2000 selbst als St. IGNUcius zu ihrem Heiligen. Im Gegenzug riefen Vi-Fans den Cult of Vi ins Leben. In endlosen Foren-Postings duellierten sich die Kombattanten: “Emacs ist ein großartiges Betriebssystem – allerdings fehlt ein guter Editor.” (Thomer M. Gil, Autor der Vi Lovers Home Page). “Eine freie Version von Vi zu verwenden, ist keine Sünde; es ist eine Buße.” (Richard M. Stallman).
Das ist zwei Jahrzehnte her. Die Zeit – und die auch in Linux vordringenden GUIs – haben die Wogen geglättet. Es fehlte aber nie an Themen, die man mit vergleichbarer Leidenschaft ausfechten konnte. Seit Jahren ist das etwa der Streit pro und contra Systemd. Die technischen Argumente lassen sich schnell aufzählen: Systemd sieht sich selbst als das bessere Init-System, weil es durch das Parallelisieren des Bootvorgangs schneller arbeitet, weil es dafür dank Zwischenspeicherung von Anfragen in Sockets keine explizit konfigurierten Abhängigkeiten braucht, weil es Snapshots beherrscht, weil es die Ressourcenverwaltung über Control Groups unterstützt, weil es viele Einstellungen zentralisiert und vereinheitlicht. Systemd kümmert sich außer um Start, Überwachung und Beenden von Diensten um eine ganze Reihe von Dingen, die zumeist weder im Kernel noch in den Anwendungen angesiedelt sind, aber zur Kernaufgabe Service-Management passen: Interprozesskommunikation, Hardware-Management, Logging oder Monitoring etwa. Nichts davon konnte das traditionell verwendete SysVinit, das einer anderen Zeit entstammt.
Die Gegner fühlen sich durch Systemd vor allem ihrer Wahlfreiheit beraubt. Immer mehr Prozesse hängen von Systemd ab und würden anders kaum mehr laufen. Ein Wechsel zu einem anderen Init-System – es gibt verzweifelte Versuche mit diesem Ziel, beispielsweise Devuan – wäre extrem aufwendig. Das ist allerdings die Kehrseite eines jeden Standards. Und auch ein weiterer Vorwurf schlägt in diese Kerbe: Würde ein Fehler oder Sicherheitsleck in Systemd entdeckt, beträfe das viele Distributionen und Anwendungen. Mit mehr Diversität wäre das anders. Aber dann müsste man eben auch für jeden Service Dutzende spezieller Skripte basteln, um ihn in jeder Umgebung starten zu können. Je mehr Menschen Systemd verwenden, umso mehr können es auch auf Schwachstellen hin überprüfen. Weiter wird Systemd vorgeworfen, es sei zu komplex und zu schwierig zu bedienen oder verstoße gegen die Unix-Philosophie “ein Tool für einen Job”. Die Komplexität ist angesichts der Funktionsvielfalt sicher kaum zu vermeiden. Gewohntes durch Neues zu ersetzen, strengt immer zusätzlich an. Die Philosophie ist ohnehin nie streng befolgt wurden – man schaue auf KDE, Gnome, X11 oder gar den Kernel selbst.
Am Ende bleiben den Systemd-Gegnern nicht viele stichhaltige technische Argumente; im Kern beherrscht sie der Unwille, sich etwas vorschreiben zu lassen. Eine Trotzreaktion, allerdings eine auf verlorenem Posten, denn faktisch sind die Würfel gefallen. Systemd wird vom dominierenden Linux-Distributor entwickelt, und nach und nach sind so gut wie alle namhaften Distributionen auf diesen Zug aufgesprungen, inklusive Suse (OpenSuse seit 2011, SLES seit 2014) und Ubuntu (seit 2015).
Ende vergangenen Jahres gab es nun im Debian-Lager, das in dieser Frage schon einmal vor einer Zerreißprobe stand, wieder eine Urabstimmung (General Resolution) zur Systemd-Policy. Gewonnen hat die Option mit der leicht salomonischen Formulierung: “Das Debian-Projekt erkennt an, dass Systemd-Service-Units die bevorzugte Konfiguration sind, um zu beschreiben, wie man einen Daemon oder Dienst startet. Dennoch bleibt Debian eine Umgebung, in der Entwickler und Benutzer alternative Init-Systeme und Alternativen zu Systemd-Funktionen erforschen und entwickeln können. Wer an der Erkundung solcher Alternativen interessiert ist, muss jedoch die nötigen Ressourcen für Entwicklung und Packaging selbst aufbringen.”
Das ist ein klarer Punktsieg für Systemd, denn die Alternativen finden zwar Erwähnung, aktiv unterstützt wird aber lediglich Systemd. Und die Option, die knapp geschlagen auf dem zweiten Platz landete, war das radikale Votum für die ausschließliche Verwendung von Systemd. Eine konstruktive Entscheidung.
