Die Schlagzeile klingt nach einem Systemwechsel: systemd, das Init-System fast jeder großen Linux-Distribution, bekommt Rust. Der Bericht beschreibt aber einen engeren Schritt. Neue Randkomponenten dürfen in Rust entstehen. Der bestehende Kern bleibt in C und wird nicht umgeschrieben. Das ist keine Revolution, sondern eine Erweiterung der Werkzeugkiste. Entscheidend ist nicht, ob Rust kommt, sondern wo es eingesetzt wird und welche Regeln gelten.
Was in systemd 263 beschlossen wurde
Der Bericht von The Register, verfasst von Liam Proven, stützt sich auf eine Ankündigung des Entwicklers Christian Brauner. Darin heißt es, systemd 262 sei vor etwa einem Monat veröffentlicht worden, systemd 263 sei nun in Arbeit. Brauner habe mitgeteilt, sein neues Feature sei zusammengeführt worden; der ursprüngliche Pull Request #44144 sei dafür in fünf Teile zerlegt worden. Die Rust-Unterstützung ist damit kein Gerücht aus einer Mailingliste, sondern ein dokumentierter Schritt im Entwicklungsprozess.
Entscheidend ist die Formulierung im zweiten Pull Request. Rust werde nur für neue Blattkomponenten verwendet. Bestehender C-Code werde nicht portiert. Nichts, wovon andere Komponenten abhängen, werde in Rust geschrieben. Das ist der Unterschied zwischen Anbau und Umbau: systemd bekommt neue Räume in anderer Bauweise, die tragenden Wände bleiben aus C. Wer gehofft hatte, der Kern des Linux-Init-Systems werde Stück für Stück ersetzt, wird durch diese Einschränkung enttäuscht.
Der Schritt ist dennoch bemerkenswert, weil er eine zweite Sprache im systemd-Ökosystem zulässt. Neue Werkzeuge und Randfunktionen können dort entstehen, wo Rust seine Stärken bei Speichersicherheit und klaren Fehlermodellen ausspielt. Der bestehende Betrieb bleibt unangetastet. Für ein so zentrales Stück Infrastruktur wie systemd ist das vernünftig. Nicht das große Versprechen zählt, sondern der zugelassene Bereich.
Fünf Teile statt eines großen Rust-Pull-Requests
Der ursprüngliche systemd-Rust-Pull-Request mit der Nummer 44144 wurde in fünf Teile aufgeteilt. Teil eins enthält keyring-util und voa-util, Helfer, um Zertifikate in Kernel-Keyrings einzutragen. Teil zwei ist der eigentliche Aufhänger: die Unterstützung für Programme, die in Rust geschrieben sind. Die weiteren Teile binden nur die Header, die der Rust-Code nutzt, wrappen die libsystemd-shared-Helfer für systemd-keyring-setup und fügen systemd-keyring-setup selbst hinzu. Die Zerlegung wirkt technisch unspektakulär, macht große Änderungen aber prüfbar.
Eine so große Änderung in einem einzigen Patch wäre für Reviewer schwer zu durchdringen. Getrennte Teile lassen sich einzeln bewerten, testen und gegebenenfalls zurückweisen. Für die Integration von Rust in systemd bedeutet das einen langsameren, aber kontrollierteren Weg. Die Aufteilung ist kein bürokratisches Detail, sondern Teil der Sicherheitsstrategie.
Der Bericht nennt die beteiligten Werkzeuge und Mindestversionen. Erforderlich sind Rust 1.85 oder neuer, bindgen 0.71.1 oder neuer sowie Meson 1.4.0 oder neuer. Diese Versionen sind vergleichsweise alt, was den Einstieg erleichtert; Debian 13 bringt ein passendes Meson mit. Für Distributoren ist das relevant, weil sie ihre Build-Umgebungen nicht sofort auf die neuesten Werkzeuge heben müssen.
Kein Cargo, keine Standardbibliothek: die Regeln für Rust in systemd
Die auffälligste Regel: kein Cargo, alles wird mit Meson gebaut. Cargo ist der Paketmanager und das Build-System von Rust; normalerweise baut man Rust-Anwendungen und verteilt Rust-Module damit. systemd hat bereits einen Build-Prozess auf Basis von Meson und Ninja. Meson ist in Python geschrieben und erzeugt die Build-Dateien, Ninja führt die Kompilierung parallel aus. Wer Rust-Code für systemd schreibt, muss sich an die vorhandene Werkstatt anpassen, nicht umgekehrt.
Die zweite Regel ist strenger: Der Rust-Code darf die Standardbibliothek nicht verwenden. Für viele Anwendungsentwickler klingt das radikal, in der eingebetteten Rust-Programmierung ist es normal. Ohne Standardbibliothek entfallen Teile der Laufzeitumgebung, die in einem so niedrig angesetzten System wie systemd nicht verfügbar oder nicht erwünscht sind. Der Code muss sich auf das konzentrieren, was die Plattform bietet; das reduziert Abhängigkeiten und Überraschungen.
Diese Regeln zeigen: Die Rust-Unterstützung ist keine Einladung zu einem freien Rust-Ökosystem. Es geht nicht darum, beliebige Crates einzubinden oder die übliche Rust-Entwicklungserfahrung nach systemd zu holen. Es entsteht ein schmaler, kontrollierter Korridor für neuen Code. Für erfahrene Rust-Entwickler ist das eine Umstellung; für das systemd-Projekt ist es der Preis dafür, die bestehende Build- und Laufzeitdisziplin zu erhalten.
Davon zu unterscheiden ist die umgekehrte Richtung: systemd aus Rust-Code aufzurufen. Dafür gibt es seit Jahren Werkzeuge, etwa das systemd-Crate, das 2015 erstmals erschien. Die neue Unterstützung erfindet diese Schnittstelle nicht neu; sie erlaubt, neue systemd-Komponenten selbst in Rust zu schreiben. Diese Unterscheidung ist wichtig, weil sie in Diskussionen gern vermischt wird.
Warum der Kern in C bleibt
Brauner wird in dem Bericht mit dem Hinweis zitiert, das Team hätte Rust gern im Kern von systemd unterstützt. Derzeit sei die Unterstützung von Rust für dynamische Bibliotheken aber noch nicht weit genug. Die Grenze verläuft nicht dort, wo Rust grundsätzlich ungeeignet wäre, sondern dort, wo die technische Infrastruktur für einen so tiefen Eingriff fehlt. Solange diese Lücke besteht, bleibt der C-Kern die stabilere Wahl.
systemd ist längst mehr als ein kleines Programm, das beim Booten Dienste startet. Zum Projekt gehören Diensteverwaltung, Journal, Geräteverwaltung und Netzwerkdienste; viele Distributionen verlassen sich auf dieses Zusammenspiel. In einem solchen Linux-Init-System mit Rust zu experimentieren ist etwas anderes, als ein neues Kommandozeilenwerkzeug zu bauen. Ein Fehler im Kern trifft den gesamten Startvorgang und damit den Rechner, bevor der Nutzer eingreifen kann. Die Zurückhaltung ist deshalb keine Technikfeindlichkeit, sondern Risikomanagement.
Die Blattkomponenten sind deshalb ein sinnvoller Anfang. Sie liegen am Rand des Systems, haben überschaubare Abhängigkeiten und lassen sich leichter isolieren. Wenn dort ein Fehler auftritt, ist der Schaden begrenzt; wenn sich die Bauweise bewährt, kann das Projekt später weitere Bereiche prüfen. Die Analogie mit dem Anbau passt: Neue Räume werden nach neuen Regeln gebaut, das Fundament wird nicht während des laufenden Betriebs ausgetauscht.
Was das für Linux und für dich bedeutet
Für Distributoren bedeutet die Änderung zusätzliche Build-Abhängigkeiten. Wer systemd 263 paketiert, muss eine passende Rust-Toolchain, bindgen und ein ausreichend neues Meson bereitstellen. Das ist kein dramatischer Bruch, aber ein weiterer Baustein, den Build-Teams im Blick behalten müssen. Die Mindestversionen sind moderat, und der bestehende C-Code bleibt unverändert. Die Rust-Unterstützung in systemd 263 ist damit vor allem eine Frage der Werkzeuge, nicht der sofortigen Migration.
Für dich als Nutzer ändert sich kurzfristig wenig. Dein System bootet weiterhin mit demselben C-Kern, und bestehende Dienste werden nicht plötzlich durch Rust-Implementierungen ersetzt. Langfristig kann die neue Möglichkeit dort Wirkung zeigen, wo neue Randwerkzeuge sicherer und wartbarer werden. Sicherheit entsteht selten durch eine große Ankündigung, sondern durch viele kleine Entscheidungen an den richtigen Stellen. So ist die Rust-Unterstützung einzuordnen.
Für Rust-Entwickler öffnet sich ein neues, aber bewusst enges Betätigungsfeld. Wer mitmachen will, muss Rust beherrschen und Meson, bindgen und die systemd-Konventionen verstehen. Cargo-Wissen allein reicht nicht, und die standardbibliotheksfreie Programmierung verlangt Disziplin. Das senkt die Zahl der möglichen Beitragenden, erhöht aber die Chance, dass der Code zum Projekt passt.
Die Nachricht ist größer als ihre unmittelbare Wirkung, aber kleiner als der erste Eindruck vermuten lässt. systemd unterstützt Rust künftig für neue Randkomponenten, nicht als Ersatz für den bestehenden Kern. Wer die Schlagzeile als Beginn eines kompletten Rewrites liest, überinterpretiert sie; wer sie als kleinen, kontrollierten Schritt abtut, unterschätzt die langfristige Bedeutung. Beides zusammen ergibt das realistischste Bild: ein Projekt, das eine neue Sprache zulässt, ohne seine tragenden Teile leichtfertig auszutauschen.
Quelle: theregister.com
