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.

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.

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.

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

Reacties (46)

[nehal3m]

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.

[specs2021]

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]

[CAPSLOCK2000]

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.

[nehal3m]

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.

[Goderic]

maar nu belanden de kernel en de service manager via proxy ook in de klauwen van Silicon Valley.

Nu? Dat is al jaren zo

[MSalters]

Dit gaat niet over init, het eigenlijke opstarten van Child processen. Dat blijft C net zoals de SysV init.

In beide systemen zijn er helper processen. In SysV is dat vaak een shell script, met alle issues van dien. Shell is historisch een vergissing, het probeert een UI en een programmeertaal te combineren. SystemD is modern en gebruikt C code plus configuratie data. Dat kan nu dus ook Rust zijn, maar configuratie blijft data.

[Killemov]

Shell is historisch een vergissing, het probeert een UI en een programmeertaal te combineren.

Dat is een mening. Wat is hier mis mee? Ik had dit al op de C64 en Amiga, nauwelijks iets mee gedaan in DOS/Windows en natuurlijk weer volop gebruikt in Linux. Ik zou mij het digitale leven niet kunnen voorstellen zonder enige vorm van scripting. En het bespaart me heel veel werk als ik in bash gewoon een for-loopje kan gebruiken:

for i in {335,333,331,328,321,317,315,300}; do history -d $i; done

[MSalters]

Je kunt het wel afdoen als een mening, maar dit is onderwerp van usability research. Op de C64 kon het niet anders en wisten we ook niet beter.

Een voorbeeld van een UI feature wat in shell niet goed werkt is "discoverability". Nee, man pages zijn niet hoe dat hoort. Een tweede voorbeeld waar we beter weten zijn spaties, quotes, haakjes, variabelen en hun interactie. Unix shells maakten daar een absolute puinzooi van.

[Goderic]

En error handling is ook echt een ramp

[Killemov]

Ik hoor alleen maar wat er niet goed aan is, maar niets van hoe het beter kan.

Het meeste is uiteraard historisch zo gegroeid en de wirwar van verschillen in syntaxis is irritant. Echter zie ik tegenwoordig het gebruik maken van een shell al als alternatief of aanvulling voor normaal desktopgebruik. Het is wat mij betreft dus al voor gevorderden die ergens verstand van dienen te hebben. Dus als jij niet weet hoe 'rm' werkt, doe het dan in vredesnaam via de bestandsbeheerapplicatie van jouw favoriete desktopomgeving.

[MSalters]

Hoe het beter kan is op zich vrij duidelijk. UI doe je primair via een GUI, bijvoorbeeld web. Programmeren doe je in 1 van de tientallen programmeertalen. Configuratie doe je in data.

[Bamboozled]

In unit files kan je gewoon "shell" aanroepen. Ik weet niet precies wat je met shell bedoelt, als je bedoelt dat je visueel in een environment zit dan begrijp ik niet goed waar je reactie tov shell vandaan komt, dit is al sinds de begindagen van Unix onderdeel van hoe gewerkt wordt.

[MSalters]

Unit files zijn de externe interface. Daar kun je desnoods Javascript aanroepen.

Nee, ik bedoel de interne tools zoals deze keyring.

[cdwave]

SysVInit trapte een setje genummerde shellscripts af, en liet het daarbij.

Systemd houdt een complete boom bij van services en devices en meer. Niet te vergelijken.

Shell scripts mogen bij allebei. En shell heeft gewoon zijn plaats in alle POSIX systemen. Dat is geen vergissing, de shell voorziet gewoon in een behoefte.

[GertMenkel]

Dat "onbewezen" systemd is ook al meer dan tien jaar geleden onderhand. Ik kan niet genoeg bash en perl om die ouder sys-v scripts te reverse engineeren als ik simpelweg een service wil stoppen, een configbestandje is toch een hele orde van grootte makkelijker.

AI kan overigens ook prima C genereren. Net zo goed als iedere andere programmeertaal, misschien wel net zo goed als mensen (maar dat is het probleem met C natuurlijk, correcte en veilige C schrijven is heel moeilijk en weinig mensen kunnen het). Je kunt heel systemd in assembly vibecoden als je dat wilt, Rust maakt je leven alleen iets makkelijker doordat er minder vage edge cases en voetpistolen in de taal zitten ingebouwd.

Aan de andere kant: nu de wereld naar systemd over is, zouden de sys-v-mensen blij moeten zijn, je kunt nu automatisch al die systemd-configuratie door LLM's laten omtoveren tot de ellenlange bashscripts en cronjobs die je gewend bent!

[Reactie gewijzigd door GertMenkel op 26 oktober 2026 10:11]

[Xander2]

De discussie jaren geleden was van een 'ouderwets' maar controleerbaar Sys-V versus een moderner maar onbewezen systemd.

Die discussie is al lang geleden beslecht. SysV kan in principe alleen reageren op runlevel wijzigingen en voldoet niet in een modern systeem dat talloze events kent tijdens het draaien.

Er moet een laag tussen userspace en kernel zitten om dit op te vangen en dynamisch configuratie en hardware support te scheiden. Dat is onmogelijk zonder iets als systemd, van te voren is niet alles configureerbaar..

[kabelmannetje]

De logische conclusie is een volledig vibe-coded systemd en daar zitten we natuurlijk allemaal op te wachten.

Dat is een glijdende schaal drogreden.

[nehal3m]

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. :-)

[bzuidgeest]

Wat maakt vibe coded uit? (verschrikkelijke term). Zolang het goed getest word. Je kan elk resultaat van AI door performance benchmarks en unit tests etc halen. Dan ben je zeker van het eindresultaat. Hoe de code er werkelijk uitziet is niet/weinig relevant.

[Jerie]

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.

Een compatibility layer lijkt me handiger. Gebruik ik op macOS ook voor het 'ip' commando van Linux. Ik trek die oude BSD utility's (die ook andere syntax al hadden) niet meer.

[Mellow Jack]

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).

[Mijzelf]

Hoezo? Is dat dan geen drop-in replacement van de in C geschreven variant?

[Stroper]

Neen, sommige zaken werken anders, worden niet meer ondersteunt, omdat ze het niet (meer) veilig vinden.
bv.
sudo -E of wildcards

[GertMenkel]

Er zijn wat uitzonderingen als je zelf je sudoers in elkaar geknutseld hebt met allerlei configuratieopties. Voor 99% van de gevallen zal het een drop-in replacement zijn.

Ik ken de meeste opties die genoemd worden niet (default is voor mij goed genoeg), maar als je een hele complexe setup hebt, snap ik wel dat je vaagheden tegen kunt komen.

[Finder]

Van welke versie ben je vertrokken en waar ben je nu?

Ik ben zelf nog even op X11 en 24 LTS gebleven omwille van een GTX1080. En ik heb liever een systeem dat 'oud' is maar stabiel.

[Mellow Jack]

Van 24.04 naar 26.04. precies zoals @Stroper zegt. Wildcards waren bij mij een issue. Bepaalde services mogen op mijn systeem bepaalde acties uitvoeren. Uiteindelijk moest ik wat dingen overzetten naar een script en dat script in sudo opnemen.

Nu ik het begrijp vind ik het wel logisch. Maar ik ben toch wel een avondje bezig geweest om alles weer draaiend te krijgen

[NoTechSupport]

Could be. En als ze het dan blijven supporteren heel cool. Vaak knelt daar het schoentje.

[tweakkjoost]

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.

[Ablaze]

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.

[bzzzt]

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

[J Koning]

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.

[bzzzt]

Een zeldzame crash vanwege een bug is voor gebruikers toch ook naar? Rust maakt juist bepaalde constructies expliciet waardoor de kans op lastige issues met code die op verschillende threads draait.

Daarnaast heeft Rust niet per se meer geheugen nodig.

[J Koning]

Nee, niet per sé, maar een ervaren C-programmeur schrijft code vanuit computer principes, waardoor je bij het realiseren zelf al weet wanneer iets beter of optimaler kan.

Met Rust doe je dat al minder, omdat je bijvoorbeeld niet hoeft na te denken over het verwijderen van een pointer. In my opinion gaat dat er toch voor zorgen dat je minder gaat nadenken over de stack en de heap. Ja, je kán het allemaal handmatig doen, maar waarom programmeer je dan nog in Rust?

En er zijn constructies die standaard meer geheugen gebruiken, bij collections of strings, en daarvoor geldt hetzelfde, je kán het allemaal niet gebruiken maar waarom dan nog Rust?

[bzzzt]

Nee, niet per sé, maar een ervaren C-programmeur schrijft code vanuit computer principes, waardoor je bij het realiseren zelf al weet wanneer iets beter of optimaler kan.

Een programmeertaal als C is al een abstractie boven machinecode. Als micro optimalisatie het doel is is C al een nivo te hoog.

Met Rust doe je dat al minder, omdat je bijvoorbeeld niet hoeft na te denken over het verwijderen van een pointer. In my opinion gaat dat er toch voor zorgen dat je minder gaat nadenken over de stack en de heap. Ja, je kán het allemaal handmatig doen, maar waarom programmeer je dan nog in Rust?

Een ervaren programmeur kan nog steeds prima nadenken over stack en heap allocatie, ook al werkt hij aan een Java applicatie. Dat is waar 'ervaren' voor staat.

Ik heb het er niet mee eens dat er winst zit in je leven zo moeilijk mogelijk maken als programmeur. Als een taal inherent een bepaalde klasse bugs niet heeft is dat altijd waardevoller dan het kleine beetje performance winst wat je zou kunnen pakken door geheugen een microseconde eerder vrij te geven (en als dat in Rust toch echt een probleem is heb je je scopes verkeerd staan).

En er zijn constructies die standaard meer geheugen gebruiken, bij collections of strings, en daarvoor geldt hetzelfde, je kán het allemaal niet gebruiken maar waarom dan nog Rust?

Je doet het nu voorkomen of het verschil immens is, maar een minimale overhead inwisselen voor nul risico op exploits omdat je functie voorbij het einde van een zero terminated string leest lijkt me de juiste oplossing voor 99,99% van de gevallen. Als je code nou zo performance kritisch is moet je waarschijnlijk toch al met custom data structuren en functies aan de slag om daar echte winst uit te halen.

Er zijn maar weinig personen zo schadelijk geweest voor computer security dan vastgeroeste C programmeurs die iedere CVE als 'menselijke programmeerfout' afdoen. Op een bepaald moment moet je het systeem zelf verbeteren...

[J Koning]

Een ervaren programmeur kan nog steeds prima nadenken over stack en heap allocatie, ook al werkt hij aan een Java applicatie. Dat is waar 'ervaren' voor staat.

Ik heb het er niet mee eens dat er winst zit in je leven zo moeilijk mogelijk maken als programmeur. Als een taal inherent een bepaalde klasse bugs niet heeft is dat altijd waardevoller dan het kleine beetje performance winst wat je zou kunnen pakken door geheugen een microseconde eerder vrij te geven (en als dat in Rust toch echt een probleem is heb je je scopes verkeerd staan).

Ik had het wellicht slecht uitgelegd, maar je mist mijn punt. Wat ik bedoelde was dat op het moment dat je dit soort manuele handelingen abstraheert, ga je op termijn anders denken. Een eenvoudig voorbeeld is het gebruik van AI, waarbij menig programmeur inmiddels meldt dat ze programmeervaardigheid tot op zekere hoogte verliezen. Je zal dit misschien vergezocht vinden, maar dat vind ik helemaal niet. Het abstraheren van manuele acties slijt het begrip van wat de computer aan het doen is. Dat denkgedrag lijkt me op kernelniveau onwenselijk. Maar er is geen taal die het denkgedrag van een computer expliciet vereist. Dan zou je de C-compiler moeten ombouwen.

Je doet het nu voorkomen of het verschil immens is, maar een minimale overhead inwisselen voor nul risico op exploits omdat je functie voorbij het einde van een zero terminated string leest lijkt me de juiste oplossing voor 99,99% van de gevallen. Als je code nou zo performance kritisch is moet je waarschijnlijk toch al met custom data structuren en functies aan de slag om daar echte winst uit te halen.

Op kernelniveau wil je de beste performance hebben. Dus ook de 0,01 maakt uit, al helemaal over 50 jaar wanneer we 5000 0,01-tjes hebben die opstapelen. Maar het is inderdaad niet veel.

Er zijn maar weinig personen zo schadelijk geweest voor computer security dan vastgeroeste C programmeurs die iedere CVE als 'menselijke programmeerfout' afdoen. Op een bepaald moment moet je het systeem zelf verbeteren...

Dit soort uitspraken zijn over het hele Internet te vinden, maar we begrijpen toch beide waarover dit onderwerp gaat? Het is inderdaad een afweging, security of performance. Ik vind Rust helemaal geen verkeerde taal en de kernel wordt elk jaar honderdduizenden lijnen groter, dus oke, laten we Rust gebruiken. Maar ik hoop dat we nog steeds blijven denken.

[bzzzt]

Wat ik bedoelde was dat op het moment dat je dit soort manuele handelingen abstraheert, ga je op termijn anders denken.

Dat klopt, maar op zich is dat geen reden om handwerk niet te automatiseren. Als je dat consistent doortrekt zou je immers ook nog steeds moeten hoofdrekenen ipv papier, rekenmachine of computer gebruiken.

Een eenvoudig voorbeeld is het gebruik van AI, waarbij menig programmeur inmiddels meldt dat ze programmeervaardigheid tot op zekere hoogte verliezen.

Ik denk dat het heel erg ligt aan wat je precies onder 'programmeren' verstaat. In ieder geval is de exacte syntax van talen minder relevant omdat AI dat meestal voor je invult. Maar dat deze coding assistants al jaren.

Maar er is geen taal die het denkgedrag van een computer expliciet vereist.

Het ontgaat me nog steeds helemaal wat je onder 'denkgedrag' van een computer verstaat.

Op kernelniveau wil je de beste performance hebben. Dus ook de 0,01 maakt uit, al helemaal over 50 jaar wanneer we 5000 0,01-tjes hebben die opstapelen. Maar het is inderdaad niet veel.

Op kernel nivo moet het vooral veilig zijn. Toen de meltdown en spectre bugs uitkwamen hadden kernel ontwikkelaars er helemaal geen probleem mee 15% performance in te leveren in ruil voor een bewijsbaar veiliger systeem.

Maar ik hoop dat we nog steeds blijven denken.

+1

[Scribe]

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

[segil]

als ik Linus mag geloven, is niets sneller dan C.

YouTube: Linus Torvalds Explains What Makes Linux So Fast

[Scribe]

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

[_JGC_]

Ook dan is ASM niet per definitie sneller dan C.
De snelheid van C ligt vooral bij de compiler die het omzet naar machinecode.

[bantoo]

Krijg je met een lege huls die niets doet tijdens het opstarten.

[bzzzt]

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.

[cdwave]

Ik denk dikke applicatie frameworks die honderden megabytes aan zinloze zooi in moeten swappen om "Hello World" te kunnen doen. Programmeurs die op state-of-the art machines werken en dus niet merken hoe inefficiënt hun code is.

Gewoon, de gebruikelijke "ik ga er pas wat aan doen als het een probleem is" houding. Zo blijft alles toch irritant traag ook al heb je steeds rappere hardware.

Schril contrast met mijn 32-bit ARM bordje die in 7 seconden na power-on een volledige GUI liet zien op een full-HD monitor, onder Linux.

Start maar eens Doom op je moderne PC. Binnen 1 seconde kun je monsters gaan knallen. De hardware is het probleem niet.

[fenrirs]

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)

[ShadLink]

Een vibecoder: "Claude herschrijf systemd in Rust, en neem gerust de tijd"

[HollowGamer]

Dit is een van de voordelen van Linux: het is ontzettend flexibel en veelal is alles mogelijk/onafhankelijk van elkaar.

Kijk je naar Windows, dan moet er altijd wel worden teruggekeken naar compatibiliteit, terwijl Linux(-libs) veel meer hun eigen ding doen en je als ontwikkelaar je daar maar op moet aanpassen.

Toevallig is dit nu Rust, maar je kunt dus ook prima C in de mix gooien. Het blijft ook een valkuil, want dan moet je als ontwikkelaar wel meerdere talen kunnen begrijpen.

Hoe meer je leest over Linux en hoe meer je het gebruikt, snap ik eigenlijk niet zo goed waarom mensen nog blijven hangen in het Microsoft ecosysteem? Je hebt daar ook services zoals systemd, maar je moet het doen zoals Microsoft het wilt, ook al is dat inflexibel of inefficiënt (want anders breekt het voor andere). Daarnaast moet het perse via de GUI, terwijl Linux standaard altijd begint vanuit de CLI gedachten.

[Reactie gewijzigd door HollowGamer op 26 oktober 2026 12:26]