Volgende Linux-kernel is 7.0 en ondersteunt Rust

De volgende kernelversie van Linux zal 7.0 worden. Dat heeft Linus Torvalds bekendgemaakt. De kernel zit nu op 6.19 en daarom wordt het tijd voor een volgend nummer, zo zegt Torvalds. Rust is vanaf 7.0 definitief onderdeel van de kernel en niet langer een experiment.

Torvalds zegt dat hij 'in de war raakt van die grote getallen' in de releasenotes van 6.19. "Bijna geen vingers en tenen meer over om op te tellen, dus de volgende kernel gaat 7.0 heten", aldus de naamgever van Linux.

In een patch die in de 7.0-release komt, zit de opmerking dat het 'Rust-experiment' ten einde is. Rust is een tweede programmeertaal waarvoor ondersteuning komt in de kernel, naast C. Torvalds wil dat ook graag. Het was al in december bekend dat het eraan zat te komen.

Rust for Linux is een project dat al bijna vijf jaar loopt. Het ontwikkelteam wilde zorgen voor betere geheugenbeveiliging in de Linux-kernel door het mogelijk te maken om Linux-kernelmodules in Rust te ontwikkelen. De oorspronkelijke programmeertaal, C, is gevoelig voor geheugenkwetsbaarheden.

Linux Kernel 6.11 uit 2024

Reacties (46)

[Djerro123]

Volgt de kernel geen SemVer? Het komt nu over alsof Linus geen 20 wil als minor versie en dus kiest voor een major getal ophoging, of zit hier ook echt breaking changes in/achter?

[DeRinus]

Sinds 3.0 gebruikt de kernel fingers-and-toes versioning. ofwel 20 releases per major versie nummer.

Na 3.19 -> 4.0, na 4.19 -> 5.0, na 5.19 -> 6.0, na 6.19 -> 7.0

Het is niet gebaseerd op "major features" of "breaking changes". De kernel breekt nooit(/zeldzaam?) user-land code.

[Loller1]

Niet helemaal correct, er is wel gewoon een 4.20 gweest.

[DeRinus]

Je hebt gelijk. Waarschijnlijk heeft hij toen die vinger naar NVidia meegeteld.

[djwice]

Klopt, en die vinger is inmiddels ingetrokken en dus komen we op .19

[GertMenkel]

Linux doet niet echt aan semver.

Om Linus te quoten bij de 4.21-naar-5.0-nummerwijziging:

The numbering change is not indicative of anything special. If you want to have an official reason, it's that I ran out of fingers and toes to count on, so 4.21 became 5.0. There's no nice git object numerology this time (we're _about_ 6.5M objects in the git repo), and there isn't any major particular feature that made for the release numbering either. Of course, depending on your particular interests, some people might well find a feature _they_ like so much that they think it can do as a reason for incrementing the major number.

So go wild. Make up your own reason for why it's 5.0.

[djwice]

Brilliant toch?!

[Aeternum]

Rust onderdeel maken van de kernel is een behoorlijke upgrade dus een volledig versienummer is dan best wel logisch denk ik?

[lenwar]

Het idee van Semantisch Versioneren (x.y.z), is:

X.y.z. Majeurversie. Deze wordt opgehoogd als de software niet meer backwards compatible is. (als je naar deze versie gaat en je doet verder niets gaan er dingen stuk. (API's veranderen, enz.)

x.Y.z Mineurversie. Er komt nieuwe functionaliteit bij, (extra opties), maar alles wat eerst werkte, blijft nu ook werken zonder aanpassing.

x.y.Z. Patchversie. Er was ongedocumenteerd gedrag (fouten dus ) die zijn opgelost.

Het 'toevoegen van Rust', betekend (zeer waarschijnlijk) niet dat andere zaken daar last van hebben, dus dat zou geen Majeurversie moeten geven.

Wat jij beschrijft is meer op 'gevoel'. Dit is een flinke update (want, laten we eerlijk zijn: Rust toevoegen is best wel noemenswaardig), maar in het geval van Semantisch Versioneren, zou dit dus geen majeurupdate zijn.

[bantoo]

Linux zit eigenlijk nog steeds op 2.6.x maar dat werd zo'n groot getal dat ze nu voor de lol zo nu en dan het eerste nummertje ophogen.

[VirtualGuineaPig]

In ieder geval blij dat het geen Linux Me of Linux 26 wordt.

Of wacht 2.6 ....


mmmh.

[bantoo]

Er is niet veel wat ze tegenhoud om de volgende release Linux Vista te noemen. Nou ja, zolang er geen mensen zijn die scripts hebben geschreven die er van uit gaan dat er altijd nummertjes in de naam staan :)

[bzzzt]

Scripts met versie checks zijn meestal stom. Waarom denk je dat Microsoft van Windows 8 naar 10 is gegaan?

[downtime]

Nee, het is vrij random, bij bedrijven bepaalt de marketing vaak wat het versienummer moet zijn en bij Linux bepaalt Torvalds dat.

Ik denk dat hij af en toe het major versienummer ophoogt omdat men anders kan denken dat er in die jaren niks gewijzigd is.

[RobertMe]

Ze zijn tot 2.6.39 gegaan en toen vonden ze het goed geweest.

Linux (/een kernel in het algemeen?) is té groot om netjes semver te volgen. Sommige subsystemen zitten wellicht elke keer grote wijzigingen, incl breaking changes, in, terwijl andere subsystems vrijwel nooit breaking changes hebben. Als je echt heel strikt semver wilt volgen en als onderdeel daarvan dus breaking changes wilt verzamelen dan denk ik dat dat de ontwikkeling helemaal niet ten goede komt. Nu zijn het dus random major version bumps. Zouden ze dat niet doen zaten ze nu op 2.6.1xx. Simpelweg omdat elke release groter of kleinet is maar niks "enorm" is om een nieuwe major te verantwoorden.

En hetzelfde effect zie je bv bij browsers. Die zijn gewoon helemaal van minor versienummers afgestapt. Elke release is een nieuwe major en die krijgt een aantal patch releases. Of er in een nieuwe versie (/major) vervolgens grote wijzigingen of breaking changes zitten is irrelevant.

[doltishDuke]

Naar mijn weten zit er geen enkele logica in en is de upgrade van 6.19 qua betekenis vergelijkbaar met van 4.6 naar 4.7 of 9.12 naar 9.13.

[Epidemias]

Linux volgt SemVer niet. De major versie word aangepast wanneer Linus daar zin in heeft.

[latka]

Semver is toch al niet meer van deze tijd: je wil feature-detection en zeker met iets grootst als de kernel (en de vele opties die er zijn bij het compileren) is het belangrijker via te bepalen of een bepaalde feature in smaak xyz aanwezig is en die dan gebruiken.

[Clemens123]

Linux breekt ook APIs in elke versie in kernel space...en normaal nauwelijks of nooit APIs naar user space. Dus welke semantiek wil je aan de versies hangen?

[Powerblast]

Nice! Toch weer een grote mijlpaal voor Rust als taal. Voor Rust vraag ik me persoonlijk nog af of de voordelen op termijn ook doorwegen in een heel groot project met veel bewegende onderdelen die continue wijzigen en refactors nodig hebben. Dat een dergelijk groot project als Linux het opneemt, geeft toch wel wat vertrouwen dat het wel degelijk de extra inspanning waard is .
Refactoren en low coupling(lees niet heel je setup moeten wijzigen omdat je ergens een mutability wijzigt) blijft toch een dingetje met Rust.

[punishedbrains]

Ik ben net begonnen met Rust aanleren, maar lees overal dat refactoring echt "the way to go" is. Zelf ben ik, o.a. met Java, meer van het opzetten van een goede architectuur eerst en dan pas echt doorpakken. Uiteraard rfactor je daar ook, maar werk je al volgens een bepaald principe, terwijl ik met Rust (als ik het lees dus) meer gewoon wat moet laten werken, dan directories gaan verzinnen die handig zijn. Maar kan zijn dat dat slecht advies is natuurlijk, ik moet nog beginnen aan het "Idiomatic Rust" boek.

Verder ben ik ver verwijdert van alle kritiek op Rust, dat het een meme-taal zou zijn etc. Ik snap daar werkelijk niks van, het is een taal zoals anderen, gewoon leren en wat nuttigs doen. Maar ik ben dan ook van een oude stempel I guess. :)

[Reactie gewijzigd door punishedbrains op 9 februari 2026 15:51]

[Killemov]

Schijnbaar zijn zelfs kernel developers faalbaar. Rust lijkt de remedie te zijn tegen memory-leak achtige problemen en dat is natuurlijk maar een deel van wat er allemaal fout zou kunnen gaan. Welke taal beschermt bijvoorbeeld tegen infinite loops of infinite recursions of iets vergelijkbaars?

[latka]

Infinite recursion is niet zo moeilijk: dat leid vanzelf tot een kernel-oops omdat je uit het geheugen loopt De grootste problemen (en die lost Rust ook niet op) zitten eerder bij concurrency. Dat was laatst met een CVE ook zichtbaar: het betrof rust code, maar het werd veroorzaakt door een concurrency probleem.

[punishedbrains]

Ja inderdaad en daar zal wel de afkeer vandaan komen, dat Rust zogenaamd alles zou oplossen. Maar waar dat vandaan komt heb ik ook niet echt mee gekregen. Logische problemen zijn inherent aan programmeren, het enige dat Rust vrij goed doet is gewoon vaak keihard op de rem trappen.

[Powerblast]

Dat is inderdaad een fabeltje. Rust beschermt niet tegen functionele fouten. Het vangt vooral technische fouten op, of voorkomt ze.
Mijn grootste favoriet is bijvoorbeeld dat match (cases) elke mogelijkheid moet bevatten. Even snel één branch testen gaat dus niet, je moet ze allemaal uitschrijven. Veel gedoe als je even snel wat wil testen. Minder gedoe in de toekomst omdat je dit niet kunt vergeten. En zo zijn er nog wel wat voorbeelden . Soms denk ik echt, jongens wat een miserie, ik had beter bij Java gebleven. Om dan 5 minuten later weer verbaasd te zijn over wat de compiler catched, wat ik zelf niet had gezien.

[mekkieboek]

Qua leesbaarheid vind ik Rust soms ingewikkeld op het eerste oog. Voorbeeld (geplukt van het web, ik ben zelf geen rust developer)

(eval $e:expr, $(eval $es:expr),+) => {{
calculate! { eval $e }
calculate! { $(eval $es),+ }
}};

Wat doet die ,+ en waarom dubbele accolade?
Ja, ook met C kun je lastig leesbare constructies maken, a = (b * **c++) << (d==2) ? 1 : 2;
Zie ook de obfuscated C contest: https://www.ioccc.org/

Maar goed, ook met Rust zal het voor een developer vast wennen in het gebruik maar ik vind (smaken verschillen) het niet perse een mooie programmeertaal.

[rjberg]

Dit is macro code, aannemende dat het echt Rust is, dat telt naar mijn mening niet echt als deel van de taal. Het is in ieder geval niet waarmee je begint, en is meer bedoeld voor speciale gevallen als het bouwen van een parser zodat je met minder code een specifiek doel kan bereiken.

[Powerblast]

Het maakt ook uit met welke taal je het vergelijkt. Als je het vergelijkt met iets zoals Python of zelfs Java of C# ziet het er erg complex uit. Als je het vergelijkt met C++ in de iets complexere gevallen is het juist eenvoudiger vind ik. Een voorbeeld: Ik zie bij Rust of een functie verwacht dat ik geheugen opkuis of niet. Bij C++ mag je gokken en hopen dat het in de docs staat. Dat maakt de syntax iets complexer maar het helpt wel heel wat issues te vermijden .

[NitSuA]

Dan ben ik toch benieuwd, als geheugenkwetsbaarheden zo’n belangrijke reden voor de overstap naar Rust zijn (ongetwijfeld zijn er meer voordelen), kan dat dan niet afgevangen worden door hele goede codescans op de huidige C code, op deze kwetsbaarheden? (Zeker nu AI steeds volwassener en beter wordt). Dat bespaart een hoop herschrijven.

[Reactie gewijzigd door NitSuA op 9 februari 2026 16:04]

[djexplo]

Het zou van uit mijn perspectief logischer zijn om alle c-code in de code geautomatiseerd naar Rust om te zetten.
Wat Microsoft ook wil doen: nieuws: Microsoft wil in 2030 C/C++ in Windows en andere code geheel vervangen door Rust

Dat kan al b.v. met C2Rust maar die maakt er onveilige Rust code van, https://c2rust.com/ .

Maar volgens b.v. Darpa kan het alleen met behulp van LLM's. Wat weining vertrouwen geeft aan onderhoudbare code.
https://www.darpa.mil/research/programs/translating-all-c-to-rust

Ook zit je met het probleem dat de meeste "die-hard" developers bij Linux waarschijnlijk van de c-school zijn, en wel c en c++ kunnen schrijven maar geen Rust .

[Powerblast]

Dat verhaal omtrent alle code van Windows herschrijven bleek volgens mij niet waar te zijn. Heb het toen even gevolgd maar geen idee wat ze er dan mee bedoelden. Alles herschrijven lijkt mij op zich ook niet zo nutttig. Moet eerlijk bekennen dat Rust ook niet alleen maar voordelen heeft. Snel itereren is er niet bij. De compiler werkt dan volledig tegen je. Dus het geeft nogal wat tegengas als je snel wat wil proberen en je design of feature nog niet 100% duidelijk is. Vandaar dat ik ook nog twijfel om er wel of niet meer mee te doen.

[Killemov]

Het zou juist een trainingsproces voor AI kunnen zijn.

[Killemov]

Ha crust!

[vanaalten]

Maar code moet wel onderhoudbaar blijven, lijkt mij.

Ik heb geen ervaring met C/C++/Rust of programmeren algemeen, maar is zo'n automatisch omgezet stuk code nog wel leesbaar als daarna iemand de Rust-versie wil bijwerken? Wordt eventueel commentaar in de code ook automatisch correct omgezet?

[bzzzt]

kan dat dan niet afgevangen worden door hele goede codescans op de huidige C code, op deze kwetsbaarheden?
(Zeker nu AI steeds volwassener en beter wordt). Dat bespaart een hoop herschrijven.

Hoewel je met code scans veel problemen kan vinden (zeker met de betere AI tools) blijft het patroonherkenning die nooit helemaal volledig is. Het grote voordeel van programmeertalen met sterke typering en geheugenveiligheid is dat je 100% zeker kan zijn dat er, als de compiler het accepteert, geen typering of geheugenbugs in de code zitten. (en ja, ik ken de 'unsafe' trucs, maar dat is intentioneel en dus ook duidelijk af te lezen aan de code)

[NitSuA]

Dank je, ik snap wat je zegt. Maar het wordt dan wel een beslissing op basis van een businesscase. Want C code inclusief goede (AI) code scanning verkleint het verschil met Rust. Dus weegt de investering dan nog op? Zeker ook het re-skillen van bestaande C devs, die mogelijk heel veel kernel / applicatie ervaring hebben en mogelijk vertrekken? Daarnaast.. hoewel Rust nu een technisch betere keuze lijkt, zal ook Rust op den duur ingehaald worden door een nieuwe taal.

[Guru Evi]

In principe wel, je kunt dus alle veiligheidsfeatures aanzetten in C compilers (stack canary etc) en bijna identieke veiligheden verkrijgen, echter, net als Rust, wordt de code dan ontzettend traag en krijg je fouten en waarschuwingen zodat ze niet volledig compileren.

Om "alle" problemen op te lossen, krijg je, net als Rust, heel veel werk (iemand moet al de aangemerkte problemen oplossen) wat in de meeste omstandigheden onnodig blijkt omdat er geen exploit path is, compatibiliteitsproblemen met andere architecturen die bijvoorbeeld, zoals Intel en moderne ARM, geen features zoals NX hebben.

Daarnaast zit er nog genoeg unsafe in Rust core libraries om enkele jaren zoet gehouden te worden, om nog niet te spreken over het libc alternatief en ook de verschillende licentieproblemen dat Rust met zich meebrengt (Rust en Rust tools zijn niet GPL en hebben ook gebruiksrestricties).

Er is een reden dat Rust nog steeds niet (goed) werkt buiten Intel en een kernel refactor is gekkenwerk. Er zijn maar een paar dingen die in de kernel zitten die Rust 'nodig' hebben en je kunt die in het algemeen eruit laten, behalve als je misschien Linux op een Apple hardware wilt draaien.

Een kernel schrijven in Rust is mogelijk (https://www.redox-os.org/) maar na 10+ jaar is het nog steeds relatief onveilig. Sommige functies zijn veilig geïmplementeerd. Andere gebruiken veilige Rust-constructies, zoals slices, maar op een onveilige manier. Weer andere gebruiken direct onveilige constructies zoals raw pointers.

[Oudecomputer]

Rust brengt ook gigantische limitaties.
Rust is geen stabiele taal/ standaard het is nog influx wat nu in deze versie werkt hoeft niet te werken in een volgende versie. Dit ze je over een aantal jaren. Versie 1.0 vs nu kun je niet compilen. De compilers is wat op aan te merken. Linus heeft dat al gedaan.
En twee rust is niet compatibel met alles. Heel veel oude hardware is niet compatibel met rust. Dus dat moet achter gelaten worden.

[Powerblast]

Rust brengt ook gigantische limitaties.

Klopt. Het voelt soms echt aan als vechten. Iets kan wel in je hoofd of op papier werken, maar als de compiler het niet kan garanderen dat het veilig is, compileert het niet. Vandaar dat ik ook nog niet all in durf te gaan. Voor business software lijkt mij dat er steeds plaats zal zijn voor talen zoals Java en C#. Eigenlijk veel simpeler in gebruik en 95% van de tijd snel genoeg. Voor die 5% extra snelheid, geef je heel wat vrijheid op, plus ook development speed op zich. Rust schrijven gaat in mijn ervaring een pak trager dan Java. Ik moet wel zeggen, ik ben verre van een specialist in Rust, dus misschien komt dat met ervaring . Nu een jaar of 5j on and off mee bezig.

[Oudecomputer]

Niet alle platformen hebben een rust compiler. En ook het schijnt dat de compilers erg moeilijk maken om terug te lezen wat er veranderd is . Dat het dingen uit elkaar trekt. Linus had daar best wel woorden over. Een Linux kernel is altijd in development. En de rust compilers maakte het vrij moeilijk om te zien wat er nu veranderd was omdat het veel dingen uit elkaar trok . Misschien is het verstandiger om nog een paar jaar te wachten. Je ziet distributie als Ubuntu onveilige of slechte rust code pushen in de core utilities want het moet. Terwijl functies niet werken of niet af zijn of gigantische bugs hebben dat er een hotfix moet worden gepusht. Liever betrouwbare code dan halfbakken onzin met een achter deur pushen.

[ioor]

Zo jammer dat t niet het spel RUST is wat ondersteund wordt...was even heel blij totdat ik alles las :p

[VirtualGuineaPig]

OK, dat wordt jezelf herprogrammeren: https://rust-lang.org/learn/

[milliondollarman111]

Goed nieuws voor PopOS dus?

[Macfuture]

Dat was precies ook mijn reactie. Pop!OS Cosmic gebruikt deels Rust als taal. Een volgende versie (april) zou Linux kernel 7.0 gebruiken. Ik neem aan dat het o.a. extra snelheidswinst oplevert voor het fantastische OS?

[rjberg]

Betwijfel het, machine code na compilatie is machine code; er zijn verschillen, maar de interfaces van libraries zijn door het OS bepaald en de CPU architectuur, niet de taal.

Zowel Rust als C worden als machinecode gedraaid, geen interpreter, dus het is niet zo dat code opeens dichter bij de hardware staat.

[milliondollarman111]

PopOS vind ik zelf fantastisch inderdaad.