Rocky Linux-maker bouwt met AI in elf dagen Linux-compatibele kernel

De maker van Linux-distributies CentOS en Rocky Linux heeft met OpenAI Codex in elf dagen een geheel nieuwe besturingssysteemkernel gemaakt die compatibel is met Linux. Dit zogeheten Ginux is geheel in Rust geschreven en draait op x86-64-processors.

Het door Gregory Kurtzer gemaakte Ginux is dus geen nieuwe aftakking (fork) van Linux, meldt opensourcenieuwssite It's FOSS. De nieuwe besturingssysteemkernel heeft volledig eigen kernelementen zoals geheugenbeheer, een scheduler, bestandssystemen, netwerkmogelijkheden en ondersteuning voor apparaten.

Daarbij kan deze kernel wel de gebruikersomgeving (userspace) van Linux draaien, zoals die van Rocky Linux 10. Bestaande Linux-programma's werken op dit platform doordat Ginux de application binary interface (abi) van Linux implementeert. De besturingssysteemkernel draait op dit moment alleen nog in een virtuele machine en mist nog hardwareondersteuning. Verder heeft een onafhankelijke partij de beveiliging nog niet doorgelicht.

AI-geschreven kernel

Het grootste deel van Ginux is geschreven door AI-agent Codex van OpenAI, die op AI-model GPT-5.6 Sol draait. Kurtzer ontwierp de architectuur, stelde beperkingen in, bepaalde de criteria voor acceptatie van code en liet Codex daarna het programmeer- en testwerk uitvoeren. Na meer dan honderd commits leverde dit 139.000 regels code op. De menselijke maker van Ginux zet zijn werkwijze uiteen in een technisch document.

De naam van deze nieuwe besturingssysteemkernel houdt geen verband met het opensourceproject GNU (GNU's Not Unix). Volgens de readme staat de G in Ginux voor GPT, een verwijzing naar Kurtzers gebruik van ChatGPT, en voor Greg.

Reacties (32)

[Waarnemer]

dus ze hebben AI gevraagd om Linux na te maken op een manier dat de code zelf er in ieder geval niet meer op lijkt om te voorkomen dat iedereen zegt dat het een kopie is...

Nou.. applaus... en wat heb ik daaraan?

[Orama]

Jup, Rust is het favoriete programma op dit moment. Je voorkomt veel bugs door de manier waarop het werkt en werkt efficiënt.

Nou ja, "van de toekomst" Het troetelkindje van de programmeertalen wil nog wel eens veranderen. God, weet wat het over 10 jaar is.

[BleghBlarg]

Ik denk eigenlijk dat het troetelkindje nooit meer gaat veranderen.

Nieuwe programmeertalen worden eigenlijk alleen het leven in geroepen om een probleem op te lossen. Maar beter gezegd, een probleem waar wij als mensen niet zo makkelijk omheen kunnen. Dat tijdperk is nu natuurlijk voorbij.

Misschien dat er nog nieuwe worden gemaakt voor de leuk maar een echte serieuze taal die ook daadwerkelijk je van het wordt verwacht ik niet meer.

[bzuidgeest]

Nee, de kernel heeft een set eigen features die linux niet heeft. Een eigen architectuur. Hij heeft OOK een compatibiliteit laag net als Linux (en windows) een posix compat laag heeft.

Niemand zegt dat je er wat aan moet hebben. De auteur noemt het een experiment.

Voor je kritiek levert, verdiep je eerst eens in hoe de auteur zijn werk presenteert.

[Sine]

Het zal vast een knap staaltje werk zijn. Maar zitten we werkelijk te wachten op nog meer OS-versnippering?

[Bliz]

Volgens mij is het vooral een experiment. Praktisch gezien kunnen we er niet zoveel mee. Je moet echt goede argumenten hebben om een eigen kernel te gaan bouwen inclusief brede hardware ondersteuning.

[divvid]

Ik denk dat ze vooral willen kijken of je straks de Linux kernel veiliger kan maken met een moderne taal als Rust

[bzuidgeest]

Welke versnippering? Het is gewoon een experiment. Iets voor de lol.

[Polydeukes]

Een experiment doe je niet voor de lol, maar om zo objectief mogelijk een hypothese te testen, aannames te verifiëren of falsifiëren, en inzicht te krijgen.

NB volgens mij gaat het hier niet om een experiment, maar om een proof-of-concept (POC) waarbij je aantoont dat iets werkt. Het doel is niet dat verder in productie gaan brengen.

[Reactie gewijzigd door Polydeukes op 2 november 2026 16:20]

[bzuidgeest]

ik doe zat experimenten voor de lol. Ik zie geen enkele reden waarom die dingen niet samen kunnen.

[CH4OS]

Daar is het al rijkelijk te laat voor. Niet alleen omdat er zoveel verschillende Linux distributies zijn, maar ook los daarvan is er een enorm divers landschap aan besturingssystemen. Of we dat moeten willen? Ik denk het wel. Iedereen heeft zijn eigen gebruik en manieren. Niet alleen de gebruikers, maar ook systemen hebben dat.

[Reactie gewijzigd door CH4OS op 2 november 2026 15:53]

[divvid]

hoezo versnippering? userspace, waar je je ding in doet, werkt blijkbaar. Je hoort toch ook niemand over alle andere tig verschillende platforms? het is een POC

[Reactie gewijzigd door divvid op 2 november 2026 16:09]

[latka]

Het is wel handig tegen hacks en virussen: de kans dat je 60 os'en tegelijk hacked is niet zo groot.

[MadEgg]

Op zich leuk maar ook weer niet heel bizar gezien Codex gewoon getrained is op de Linux source code zonder enige twijfel. Daarnaast mist een van de complexe stukken van de kernel: de ontzettend wijde ondersteuning voor ontzettend veel hardware.

Wel interessant dat het ABI-compatible is met Linux, dat maakt het wel praktisch toepasbaar.

[Noxious]

Een kleine kernel kan misschien boeiend zijn puur voor virtualisatie, daar je niet zo'n brede hardware-support nodig hebt; maargoed er zijn natuurlijk ook Linux kernel builds (zoals linux-virt in Alpine) die daar op gericht zijn.

[bzuidgeest]

Het is een experiment, geen productie ding. Iets voor de ontwikkelaar om mee te spelen.

Ik heb toen AI nog redelijk nieuw was ook meteen een frontend voor LLVM laten maken met mijn eigen voorkeurs syntax. Gewoon omdat ik wilde zien waar je kon komen. Niet omdat ik verwacht dat ik ineens iets magisch had verzonnen dat iedereen gaat gebruiken.

Overigens is de AI gewoon getrained op OS design kennis en x86 hardware specificatie. De AI hoeft linux niet te zien om gewoon een kernel te kunnen bouwen. Er zijn er over de jaren honderden ontworpen op basis van allerlei uiteenlopende design filosofien.

[Reactie gewijzigd door bzuidgeest op 2 november 2026 16:01]

[bzuidgeest]

Het is 100% proof of concept. Maar het zijn leuke experimenten om de kracht van die machines te testen. Er is nog steeds een groep die denkt dat ze alleen maar hallucineren, maar hier komt een min of meer volledige kernel uit met zijn eigen unieke eigenschappen en een linux compatibility layer, waar sommige linux functionaliteiten expliciet zijn uitgelaten die vloeken met de concepten van deze kernel. En niemand kan stellen dat dit een domme vibe coder is. Een long time developer die een experimentje doet.

[Eksit]

Klopt het dat ai graag in Rust werkt? Alle Craft projecten zijn ook in Rust. Is het dat Rust de toekomst is of is het specifiek voor AI makkelijk?

[Noxious]

De Rust compiler en tools daaromheen zijn erg 'streng' waardoor een LLM veel feedback krijgt als er code uit komt met fouten. Daarom is het een ideaal ecosysteem voor gegenereerde code; veel fouten zijn by design al niet mogelijk. Ik vermoed dat dat de reden is dat Rust zo veel wordt gebruikt i.c.m. LLMs.

[latka]

Als je een ai iets vraagt en hij heeft een programma nodig voor zijn antwoord dis het negen van de 10 keer in python tenzij je hem actief stuurt naar iets anders.

[3raser]

Of Rust de toekomst is weet ik niet, maar het heeft wel een heel groot voordeel in het feit dat het geen buffer overflows kan veroorzaken. Die overflows worden vaak gebruikt door hackers om exploits te maken.

[bzuidgeest]

Het kan wel, het is alleen veeeeeel moeilijker. Niets is perfect en de controles van Rust zijn compiletime niet runtime. Voor runtime safety heb je een taal als c# of java nodig, maar dan heb je ook de managed runtime overhead.

[YopY]

Dat inderdaad; iets wat ik veel zie in mijn wereldje is dat veel Javascript tools omgeschreven worden naar bijv. Rust, om zo de JS interpreter en de intrinsieke performance beperkingen van JS te omzeilen.

Zo is Typescript 7.0 in Go geschreven, dat is geconverteerd van 5.0's Javscript (of Typescript) broncode en 5-10x zo snel. (TS 6.0 was een tussenstap waar ze een paar opties backwards incompatibel veranderd hebben).

Maar vervolgens hebben anderen een deel van die nieuwe Go codebase weer laten vertalen naar Rust, en zo nog eens een vermenigvuldiging van de snelheid behaald (tenminste voor type checking). Opmerking daarbij was dat het niet alleen de conversie naar Rust was, maar dat ze ook wat verbeteringen doorgevoerd hebben waar de TS ontwikkelaars nog geen tijd voor hadden genomen - hun focus lag eerst op het 1:1 omvormen naar Go. Ze hebben die algoritmische wijzigingen ook aangeboden als verbetering voor de officiele Typescript code, waardoor TS 7.1 ook weer een aantal grote performanceverbeteringen heeft.

[.oisyn]

en de controles van Rust zijn compiletime niet runtime

Array bounds checking is runtime, al kunnen die omzeild worden als de compiler statisch kan concluderen dat out-of-bound access niet kan. Er zijn ook nog wel wat andere runtime checks, zoals unwraps van Option<T>/Result<T,E>, of de gedeelde access van een RefCell<T>.

Maar het meeste gebeurt idd tijdens compile time, en dat creëert meteen een ontzettend goede feedback loop voor AI bij het schrijven van code.

[bzuidgeest]

Fair enough. Na een korte poging met de in mijn opnini verschrikkelijke syntax ben ik hard weggerend

[sympa]

Voor zover ik heb begrepen dwingt Rust tot zorgvuldig werken. Dus een hoop bugs zijn op voorhand voorkomen.

Dat het werken in Rust daardoor meer gedoe is maakt voor de AI niet zoveel uit.

[YopY]

Sterker nog, een strenge, formele taal als Rust is juist beter voor AIs omdat ze dan in dichtere loops kunnen werken, en niet stoppen totdat het compiled. Met Rust heb je veel eerder in het ontwikkelproces zekerheid dat het werkt, als het compiled. Met bijvoorbeeld JS moet je het eerst uitvoeren en de output checken. En met C / C++ moet je het uitvoeren en allerlei vage input geven om te zoeken naar buffer overflows.

[MrSir69]

In mijn ervaring werkt AI het best als het zichzelf kan controleren. Dat is tests schrijven en agents die andere agents reviewen, maar ook code die niet compileert als er bepaalde soorten fouten in zitten, zoals rust. Zie ook het bewijs rondom de Navier-Stokes vergelijkingen, dat is gedaan in lean. Die taal compileert alleen als een redenering klopt.

[bzuidgeest]

Nee, het is een keuze van de mensen die de prompt geven. Rust is hip en heeft als voordeel tegenover c en c++ dat het in de compiler een hoop statische checks heeft die memory leaks en gebruik van geheugen door delen van het programma die daar geen recht op hebben voorkomen.

Rust syntax is (opinie) verschrikkelijk. Maar een AI heeft er minder moeite mee. Maar een AI heeft minder moeite met elke taal dan mensen.

[Bigs]

Wel gaaf dat het EFI image alles inclusief de kernel bevat. Het beveiligingsconcept van deze kernel verschilt behoorlijk van dat van Linux. Leuk om te zien.

[digigast]

Even helemaal los van de AI discussie, zie ik dat dit nu onder de Apache 2.0 licentie is vrijgegeven. Iets dat "de open source wereld" al een tijdje slapeloze nachten geeft; een stormvloed aan opensource producten die zo permissive zijn dat bedrijven het lekker gratis kunnen gebruiken en aanpassen en ondertussen niemand iets schuldig zijn. OpenWRT had niet in de huidige vorm bestaan zonder de GPL. Zo is Andrew Tanenbaum al tegen de lamp gelopen met Minix (dat door Intel o.a. gewoon gepakt is en geïmplementeerd in jouw Intel CPU zonder royalties of dank aan (of weten van) Tanenbaum).

Deze licenties streven een mooi ideaal na maar zijn erg naïef over de vriendelijkheid van bepaalde individuen. Rust dwingt dit soort licenties an sich niet af, maar toch nudged (in goed Nederlands) het er wel naar.

[Reactie gewijzigd door digigast op 2 november 2026 16:27]

[dmantione]

Het is natuurlijk indrukwekkend dat een KI dit kan, maar de lijst van systemcalls in Linux is vrij overzichtelijk en dus niet extreem complex om te implementeren. Dat programma's draaien zegt weinig over hoe efficiënt de kernel is. Een aanzienlijk deel van de kernel betreft subsystemen zoals de Direct Rendering Manager, het USB-subsysteem, de netwerkstack e.d. De kernel bevat vele bestandsystemen. En ja, het merendeel van de kernel betreft driverbroncode.

Dus al bij al zegt dit nieuws vrij weinig, het kan gaan om een minimale implementatie van de systemcalls en dan zullen veel programma's kunnen draaien. Hoe goed ze draaien en waarop ze kunnen draaien... dat is nu het moeilijke deel van een kernel bouwen.