FOSDEM 25: Systemd skizziert seine Zukunft
Das Init-System Systemd ist gerade 15 Jahre alt geworden. In seiner Keynote auf der FOSDEM 25 spricht Entwickler Lennart Poettering über die anstehende Pläne.
(Bild: FOSDEM / systemd.io)
Systemd ist seit seiner ersten Version, ursprünglich mit dem Namen "Babykit" von Kay Sievers und Lennart Poettering nach der Linux Plumbers Conference 2009 erdacht, zu einem der gewichtigeren Projekte um Linux geworden. Neben einem Kernteam von sechs Entwicklern haben 60 weitere Zugang mit Commit-Berechtigungen zum Quellcode und die Schätzung lautet, dass über die Jahre 2600 Individuen an Systemd mitentwickelt haben.
Die Inspirationen lieferte nicht nur das altehrwürdigen System-V-Init, beziehungsweise die Probleme mit dessen scriptbasierter Dienstekonfiguration. Auch Ideen von Canonicals Upstart, Solaris SMF und von Apples Launchd flossen in Systemd ein. Hier war insbesondere der Dienststart per Socket-Aktivierung nur bei Bedarf, gegebenenfalls auch parallel, einer der Hauptziele der Systemd-Diensteverwaltung. Apple-Rechner mit OS X starteten flott – das sollte auch Linux können.
Systemd: Kleiner FuĂźabdruck mit dynamischen Bibliotheken
Die ersten nennenswerten Zeilen Quellcode liegen 15 Jahre zurück. Ein Jahr später gab es die erste lauffähige Version. Seit 2011 ist Systemd Standard in Fedora, openSUSE und Arch Linux folgten nur etwas später und vor 10 Jahren übernahmen Ubuntu und Debian Systemd als Standard-Init-System. Eine Gelegenheit für Lennart Poettering, die Meilensteine in der bisherigen Entwicklung zusammenzufassen sowie die Gründe, warum sich seiner Meinung Systemd gegen andere Init-Systeme – und teils harsche Kritik – durchgesetzt hat. Auch ein kurzer Ausblick auf jene Aufgaben, die Systemd in naher Zukunft lösen will, passten noch mit in den Tag, der mit einem Gruß an die anwesenden Devuan-Maintainer begann – eine der wenigen Linux-Distributionen, die bis heute Open RC gegenüber Systemd bevorzugt.
Videos by heise
Dabei beruhten viele Kritikpunkte auf Missverständnissen, was sich laut Poettering nun ein paar Jahre später noch deutlicher zeigt: Systemd brach nicht mit allen UNIX-Prinzipien. Systemd ist keine monolithische Binary geworden, die das gesamte Linux-System kontrolliert, sondern heute eine Sammlung von rund 150 Einzelprogrammen. Die wenigsten Linux-Distributionen benötigen alle. Nur Fedora Linux liefert nahezu alle Systemd-Binaries fertig kompiliert in seinen Standard-Repositories aus. Die Größe aller Binaries umfasst 25 Megabyte. Die gesamte Systemd-Sammlung besteht aktuell aus rund 690 Tausend Zeilen C-Code, was der Hälfte der Bibliothek Glibc entspricht.
Schlank blieb Systemd laut Poettering allerdings durch Abhängigkeiten von anderen Bibliotheken. Dies stellt ein Dilemma dar, denn zu viele Abhängigkeiten lassen das Gesamtsystem zu stark anwachsen. Es gäbe laut Poettering die Tendenz, Systemd mehr und mehr Funktionalität zu übergeben. Systemd verlässt sich deshalb mittlerweile bei Extra-Funktionalität auf schwache Abhängigkeiten, die per "dlopen()" nur herangezogen werden, wenn Systemd die Bibliothek anfordert. Als Begrenzung gelten initiale Ramdisks und kleine Container, in welche Systemd weiterhin passen muss.
Ausblick: Rust kommt erst viel später
Zu den Baustellen, die Systemd zuerst angeht, steht auf der Liste Poetterings die Verifizierung der Integrität eines Linux-System beim Start. Dies erledigen Messwerte, die in einem TPM-2-Chip hinterlegt sind (PCRs) und nach dem Boot verglichen werden. Systemd soll sich um die Versiegelung der gewünschten Messwerte kümmern, etwa zum Start eines signierten Unified Kernel Images (UKI), um zwischenzeitliche Manipulationen an Bootprozess und Kernel auszuschließen. Dahinter folgt auf der To-Do-Liste die Ergänzung von DBUS für die Interprozesskommunikation mit dem mächtigeren Varlink, das aus dem Systemd-Dienst einen IPC-Service macht, der JSON zur Weiterverarbeitung ausgeben kann.
Und schließlich hoffen die Systemd-Entwickler auf eine generelle Abkehr von paketbasierenden Linux-Distributionen hin zu imagebasierten Linux-Systemen im Stil von Fedora Silverblue oder Endless OS und wollen Systemd speziell mit Tools für diese Art von Systemen ergänzen. Für die spätere Entwicklung sehen die Köpfe hinter Systemd auch die Verheißungen von Rust, um das Speichermanagement robuster zu machen. So gibt es mit "systemd-zram-generator" intern schon eine neue, in Rust geschriebene Komponente, die jedoch noch nicht veröffentlicht wurde. Generell kann Systemd laut Poettering aber erst richtig von Rust Gebrauch machen, wenn es dynamisch ladbare Bibliotheken unterstützt, ansonsten würde es tatsächlich zu einem unförmigen Golem wachsen, der in keine initiale Ramdisk mehr passt.
(dmk)
