Ontwikkelaars kunnen nieuwe systemd-componenten voortaan in Rust bouwen

Met Systemd kunnen ontwikkelaars voortaan programma's in Rust schrijven. Dat meldt Linux-kernelontwikkelaar Christian Brauner op GitHub. Systemd is een systeem- en servicemanager voor Linux, die het opstarten van het systeem regelt en achtergrondprocessen beheert.

Rust logoBrauner benadrukt op GitHub dat systemd zelf niet herschreven wordt in Rust. De ondersteuning geldt alleen voor nieuwe, losstaande componenten waarvan andere delen van systemd niet afhankelijk zijn. Bestaande C-code wordt dus niet herschreven.

Verder valt op dat systemd geen Cargo introduceert. Cargo is de standaardpackagemanager en buildtool voor Rust. Systemd gebruikt echter Meson voor alle builds en blijft dat ook doen, zegt Brauner. Ook zegt hij dat de ondersteuning voor Rust optioneel is. Ontwikkelaars kunnen die zelf aan- en uitzetten.

Door de update hoeven ontwikkelaars programma's niet langer alleen in C te schrijven. Deze programmeertaal is gevoeliger voor geheugenkwetsbaarheden dan Rust. Rust vindt de afgelopen jaren dan ook steeds vaker zijn weg naar Linux. Zo is Rust sinds Linux 7.0 definitief onderdeel van de kernel.

Het eerste systemd-component dat in Rust is geschreven, is systemd-keyring-set-up, dat helpt certificaten in de keyrings van de Linux-kernel te beheren.

Door Eveline Meijer

Nieuwsredacteur

26-10-2026 • 08:14

19

Submitter: perry

Reacties (19)

Moderatie-faq

Sorteer op:

Weergave:

Brauner benadrukt op GitHub dat systemd zelf niet herschreven wordt in Rust. De ondersteuning geldt alleen voor nieuwe, losstaande componenten waarvan andere delen van systemd niet afhankelijk zijn. Bestaande C-code wordt dus niet herschreven.

Niet door de originele auteurs, althans. Ik kan me goed voorstellen dat er puristen zijn die door LLM's geassisteerd een Rust gebaseerde fork gaan maken.
Ben benieuwd. Laatst een upgrade van Ubuntu gedaan waar blijkbaar een rust versie van sudo in zit. Het heeft me wel even gekost om alles weer draaiend te krijgen (met hulp van AI).
Hoezo? Is dat dan geen drop-in replacement van de in C geschreven variant?
Could be. En als ze het dan blijven supporteren heel cool. Vaak knelt daar het schoentje.
Was het maar een gewone complete rewrite.

De discussie jaren geleden was van een 'ouderwets' maar controleerbaar Sys-V versus een moderner maar onbewezen systemd. Vanuit die visie is het minder updaten van C naar Rust en meer op het openzetten van de deur voor meer code ontwikkeld met AI ("want dat is de toekomst"). De logische conclusie is een volledig vibe-coded systemd en daar zitten we natuurlijk allemaal op te wachten.

Niet dat ik tegen Rust ben, maar ik zal mijn BSD kennis moeten ontroesten. Misschien met de kerst maar een systeem overzetten van Linux naar BSD.

[Reactie gewijzigd door specs2021 op 26 oktober 2026 09:20]

De kernel gaat er ook achteraan. Ik ben inmiddels wel een beetje klaar met de hobby. Ik ga wat meer tijd investeren in m'n boot cq motorfietsen cq achtertuin. :-)
Vanuit die visie is het minder updaten van C naar Rust en meer op het openzetten van de deur voor meer code ontwikkeld met AI ("want dat is de toekomst"). De logische conclusie is een volledig vibe-coded systemd en daar zitten we natuurlijk allemaal op te wachten.
Stel dat je gelijk hebt, wat zou het nadeel zijn van het openen van die deur? Ik bedoel dan niet wat de nadelen van vibe-coden zelf zijn, maar wat de nadelen zijn van het voorbereiden op vibe-coden. Wat voor aanpassingen zijn er nodig om die deur open te zetten? Documentatie? Betere naamgeving? Dode code verwijderen? Refactoring?
En wat daarvan is nadelig voor menselijke coders?

In mijn (beperkte) ervaring hoef ik geen concessies te doen om dingen geschikt te maken voor AI. In tegendeel, meestal zijn het dingen die ik eigenlijk toch al had moeten doen maar niet gedaan heb, omdat ik te lui was en het niet nodig vond (documentatie? ah, ik lees de code wel... ik heb het toch zelf geschreven? ;-) .
In mijn ervaring dwingt het inzetten van AI me juist om de basis goed op orde te krijgen omdat ik niet kan vertrouwen op dat "de programmeur begrijpt wel wat ik bedoel".
Niet dat ik tegen Rust ben, maar ik zal mijn BSD kennis moeten ontroesten.
Ik weet niet dat of dat een bewuste woordspeling was of niet, maar zo ja, mooie. :)
BSD(kennis) heeft weinig last van roest en blijft heel lang goed. Even afstoffen is genoeg.
Misschien met de kerst maar een systeem overzetten van Linux naar BSD.
Diversiteit is altijd een goed idee.
Stel dat je gelijk hebt, wat zou het nadeel zijn van het openen van die deur? Ik bedoel dan niet wat de nadelen van vibe-coden zelf zijn, maar wat de nadelen zijn van het voorbereiden op vibe-coden.

Niet degene waar je op reageert maar: Een deel van mijn motivatie om over te stappen op Linux was omdat het een onafhankelijk project is/was dat is gebouwd door de community voor de community. Het gebrek aan commerciële prikkels daaromtrent was wat me ertoe aantrok, maar nu belanden de kernel en de service manager via proxy ook in de klauwen van Silicon Valley.
Beetje off main topic maar als je de Artcraft suite op Linux probeert wordt je weggeblazen door de snelheid waarmee de apps openen. Zelfs op wat oudere hardware is het bijna instant. Deze apps zijn ook in Rust gemaakt door AI.
Rust is niet per se sneller dan C(++) ofzo hoor, heeft er vooral mee te maken dat Rust veiliger is. Al helemaal fijn met vibe coden, LLMs maken vaak fouten en dat is in Rust een stuk moeilijker
Is ook vrij logisch. Rust komt er zeker bij in de buurt, maar puur C is moeilijk te verslaan. Tenzij we de hele kernel met de hand is ASM gaan schrijven :+
Rust en C(++) hebben beiden de potentie om dezelfde razendsnelle applicaties op te leveren.


Het voordeel van Rust t.o.v. C is dat het moderner is en bepaalde geheugenproblemen als gevolg van menselijke programmeerfouten voorkomt. Dat is voor programmeurs een voordeel.
Het voordeel van Rust t.o.v. C is dat het moderner is en bepaalde geheugenproblemen als gevolg van menselijke programmeerfouten voorkomt. Dat is voor programmeurs een voordeel.
Ik mag hopen dat gebruikers software met minder fouten ook wel prettig vinden ;)
Linux kernel wordt wel zo grondig getest dat dit voor eindgebruikers niet echt een probleem is. Het ontwikkelen gaat voor ontwikkelaars sneller. Dat is dus enkel voor programmeurs een voordeel, want de gebruikers zitten mogelijk met wat meer ram-gebruik.
Krijg je met een lege huls die niets doet tijdens het opstarten.
Misschien moet de huls pas gevuld worden als ik mijn intentie duidelijk heb gemaakt?

Ik vraag me bij veel software wel af wat er allemaal gebeurt dat het zo lang duurt om te starten. Direct een venster openen is echt niet teveel gevraagd. Veel applicaties kunnen dat wel op moderne hardware.
Alleen jammer dat de onderliggende code

1) gejat is uit diverse open source alternatieven waar mensen veel tijd in hebben gestoken

2) de onderliggende wiskunde volledig onbegrepen is door de ontwikkelaar, dus bij verbeteringen in de algoritmes men volledig afhankelijk is wat er in bovengenoemde open source implementaties verbeterd wordt

3) het hele AI < vul een willekeurige suite in> voornamelijk one man shows zijn

Ik heb helemaal niets tegen met AI ontwikkelde software, maar steek dan in vredesnaam je tijd in het verbeteren van bestaande volwassenen oplossingen, zodat deze nog beter worden in plaats van een hele rij initiatieven zonder stevige basis

(nog verder off topic uiteraard: het lijkt bijna wel een evolutionair systeem met heel veel doodlopende branches)
Een vibecoder: "Claude herschrijf systemd in Rust, en neem gerust de tijd"

Om te kunnen reageren moet je ingelogd zijn