In der 70. Folge des Datenkanals hatten wir uns systemd als Thema gewählt, doch war die Sendezeit dann wieder zu kurz, weshalb ich an dieser Stelle noch ein paar Gedanken zum Thema nachgereicht hatte. In der Zwischenzeit haben wir aber auch die 71. Folge als Fortführung des Themas aufgenommen und den Großteil meiner hier dargelegten Punkte aufgegriffen.

Die 70. Folge hat sich für mich leider in dem Klein-Klein von Bugs, ungünstiger und unvollständiger Implementation und der Kommunikation mit Lennart Poettering verloren. Meiner Meinung nach sollte man aber bei den Fragen und Problemen zum Thema systemd drei Kategorien unterscheiden: 1) Konzept, 2) Implementation (Bugs) und 3) Marketing (inkl. Rollout-Strategien, Ankündigung von Änderungen und Neuerungen).

Das Fehler bei der Implementation geschehen oder einiges unvorteilhaft Umgesetzt wird, ist unbestritten und das sollte man akzeptieren. Außerdem sollte man auch akzeptieren, dass solch umwälzende und einschneidende Neuerungen auch neu sind und man daher hinzulernen und anders arbeiten muss – und systemd macht vieles neu.

Die Art und Weise wie systemd verkauft wurde, ist sehr unglücklich gelaufen, denn wie Jens es in der ersten Sendung angesprochen hat, wurde es als Ersatz für init verkauft – und damit kleine Änderungen suggeriert –, aber dann war es plötzlich dbus und journald und noch einiges mehr. Diese Taktik des trojanischen Pferdes, die hier sicher ungewollt praktiziert wurde, hat viele verwirrt und auch zu einem erheblichen Ärger beigetragen. Hinzu kam noch die Kommunikation mit Lennart, die speziell ist, aber bei der ich sagen muss, dass es stimmig ist, wenn man ihn im Chaos Radio Express 209 hört.

Mir war für das Thema wichtig, über die Inhalte und die Konzepte zu sprechen und nicht die Bugs und das PR-Desaster zu diskutieren – denn beides ist hinreichend im Netz dokumentiert. In fünf Jahren erinnert sich wahrscheinlich kaum jemand an die Probleme und wenn das Konzept gut ist, dann ist es das, was bleibt. Hier ein paar Beispiele, für vergangene Debatten und wer erinnert sich noch daran:

Erst in der zweiten Sendung haben wir mehr Verständnisarbeit geleistet und die Gründe für Änderungen bzw. die Konzepte erklärt. Wir wollten zeigen, was geht und wie man mit systemd arbeitet, um genau die Probleme unserer Zuhörer beim Umstieg oder der täglichen Arbeit zu mindern. Ein neuer Nutzer, der heute einsteigt und nur systemd lernt, wird das Konzept als völlig normal ansehen und mit solchen Problemen wie Jens sie mit Tor beschrieben hat nicht hadern. Aber es ist auch noch Aufklärungsarbeit notwendig. In der erst Sendung haben wir leider den Blick zu sehr zurück gewandt und nur darüber gesprochen, was in der Vergangenheit passiert ist, statt in die Zukunft zu schauen und zu überlegen, wie uns systemd beeinflussen wird.

Klar, der Blick zurück ist auch wichtig und bei dem systemd-Projekt wahnsinnig interessant – Soziologen oder Kommunikationswissenschaftler würden daran ihre helle Freude haben. Mich würde es auch interessieren, dieses oder andere Projekte unter dem Blickwinkel der Kommunikation (Vermarktung) zu analysieren, denn ich glaube, hieran haben schon viele Projekte gelitten oder auch Gutes geleistet – Firefox Quantum fällt mir spontan als jüngeres Beispiel für ungünstige PR ein.

Mit der 71. Folge ist es uns hoffentlich besser gelungen, die Beweggründe für die Veränderungen durch systemd darzulegen. Bei der Aufzeichnung der Sendung ist mir auch aufgefallen, dass wir stärker über Lösungen und Ansätze für eine Veränderung gesprochen habe. Im Diskurs von These (fork in systemd) und Antithese (fork im Dienst) sind uns neue Ideen (fork-you; Synthese) gekommen. Ich hoffe, wir konnten den Zuhörern an dieser Stelle ein gutes Beispiel seien und zeigen, dass man mit Offenheit für die Bedürfnisse des anderen und einem rational geprägten Diskurs auch neue Wege entdecken kann. Die starken Emotionen in der Debatte um systemd versperren oft den Weg für Neues – auch auf Seiten der systemd-Entwickler.

Vortrag zum Thema

Von Benno Rice gab es bei der linux.conf.au 2019 den Vortrag The Tragedy of systemd, der auch sehr gut die Schwierigkeiten beschreibt, die der Debatte um systemd zugrunde liegen. In den Kommentaren zum LWN-Artikel über den Vortrag finden sich auch viele weitergehende Bemerkungen.

Notizen zur Sendung

In Vorbereitung auf die Sendung hatte ich mir schon Notizen angefertigt, die ich hier noch aufführen will, denn vielleicht helfen sie dem einen oder anderen noch etwas mehr beim Verständnis der Fragen rund um systemd.

Neue Anforderungen, die Welt hat sich geändert

Bereits vor systemd gab es schon Entwicklungen von Verwaltungssystemen für Dienste, die sich im Konzept von System-V-init unterschieden: upstart, runit, minit. Auch innerhalb von SysV-init wurden in die Steuerungsskripte Metainformationen in deklarativer Art eingebaut, so dass man mit insserv daraus die Startreihenfolge ermitteln konnte und mit startpar war es zum Beispiel möglich, verschiedene Programme gleichzeitig zu starten. Unter Debian hatte sich auch das Programm start-stop-daemon etabliert, womit schon das Starten und Beenden eines Dienstes vereinheitlicht wurde.

Systemd ist zum Teil wirklich nur ein Aufräumen und Integrieren bisheriger Insellösungen.

Konzeptuelle Änderungen mit systemd

Weitere Neuerungen