Geschiedenis van de Linux kernel: bepalende keuzes

De korte versie van de Linux kernel-geschiedenis

De geschiedenis van de Linux kernel loopt van versie 0.01 in september 1991 tot de 7.x-serie die vandaag de dag op servers draait. De lijst met releases is het minst interessante onderdeel hiervan. Een klein aantal beslissingen heeft de vorm van het systeem bepaald, en elk daarvan heeft nog steeds gevolgen voor een machine die u vanmiddag huurt.

Datums en versienummers in deze tekst zijn afkomstig van kernel.org en de publicaties over de releasegeschiedenis. De huidige status, per augustus 2026: 7.0 verscheen op 12 april 2026, 7.1 op 14 juni 2026, en 7.2 bevindt zich in de fase van release candidates.

Waarom de GPL-keuze uit 1992 nog steeds relevant is

Versie 0.01 werd op 17 september 1991 gepubliceerd onder een licentie die Torvalds zelf had geschreven. Deze vereiste dat de broncode werd gedistribueerd en bevatte een regel die zwaarder woog: "U mag dit niet tegen betaling distribueren, zelfs niet voor 'administratiekosten'." In 1991 werd software op diskettes geleverd, en het kopiëren en versturen van diskettes kost geld. Die clausule maakte een commerciële Linux-distributie onmogelijk.

Hij wijzigde dit. De overstap naar de GNU General Public License (GPL) werd aangekondigd in de release notes van versie 0.12 in januari 1992 en werd van kracht op 1 februari 1992. Versie 0.95, in maart 1992, was de eerste release die hieronder werd gepubliceerd. Elk bedrijf dat later op Linux is gebouwd, rust op die verandering.

De kernel is uitsluitend GPL versie 2 en is nooit overgegaan naar versie 3. Torvalds weigerde dit in 2007, voornamelijk vanwege de anti-tivoisatie-regel in GPLv3, die vereist dat een apparaat waarop GPL-code wordt geleverd, ook een aangepaste kopie van die code accepteert. Hij beschouwde vergrendelde hardware als een zaak van de fabrikant zelf. In 2017 publiceerden kernelontwikkelaars de Kernel Enforcement Statement, die toch één onderdeel van GPLv3 overneemt: iemand die een inbreuk herstelt nadat deze is gemeld, behoudt de licentie, in plaats van deze bij de eerste overtreding permanent te verliezen.

Dit heeft twee gevolgen voor een server. Het kernel-binary dat u opstart, draagt het recht op de bijbehorende broncode met zich mee, dus niemand kan u een Linux-kernel leveren die u niet mag inspecteren of opnieuw mag compileren. Bovendien stelt de copyrightvermelding op de kernel dat de licentie geen betrekking heeft op gebruikersprogramma's die kernelservices gebruiken via normale system calls. Daarom kunnen propriëtaire databases en monitoring-agents voor Linux worden geleverd zonder regels te overtreden. Een permissieve licentie creëert de tegenovergestelde druk, en dat verschil is belangrijk om te begrijpen voordat u een platform kiest: zie Linux en FreeBSD als serverplatforms.

Waarom de monolithische kernel in de praktijk won

Op 29 januari 1992 plaatste Andrew Tanenbaum een bericht met de titel "LINUX is obsolete" in de nieuwsgroep comp.os.minix. Hij deed twee beweringen. Monolithische kernels, waarbij drivers en bestandssystemen in één bevoorrechte adresruimte draaien, waren een ontwerp uit de jaren 70, terwijl microkernels, waarbij die onderdelen als gewone processen draaien, de toekomst waren. En Linux was vastgeklonken aan de Intel 386, dus het zou nooit draagbaar worden.

De bewering over draagbaarheid werd beantwoord door porting. Versie 1.2 in maart 1995 voegde Alpha, SPARC en MIPS toe. Versie 2.0 in juni 1996 voegde een 64-bit Alpha-port toe.

De bewering over het ontwerp werd beantwoord door een compromis. Linux werd nooit een microkernel. Het kreeg laadbare kernelmodules: objectbestanden die u in een draaiende kernel invoegt en weer verwijdert, waardoor een driver los van het kernel-binary wordt uitgebracht.

lsmod | head
modinfo virtio_net | head -5

lsmod toont wat er op dit moment geladen is. modinfo print het bestand waar de module vandaan kwam en de parameters die deze accepteert. Op een virtuele server bestaat het grootste deel van het schijf- en netwerkpad uit modules, wat de reden is dat één kernel-image opstart op hardware die het nog nooit eerder heeft gezien.

Modules kochten die flexibiliteit zonder de kosten die het microkernel-ontwerp met zich meebracht. Het isoleren van een driver in zijn eigen proces betekent betalen voor een context switch en een bericht bij elke aanroep, en in 1992 waren die kosten aanzienlijk.

De kosten die Linux behield, zijn de kosten waar u rekening mee moet houden: een module draait met volledige kernelrechten, dus een defecte module haalt de hele machine onderuit in plaats van slechts één proces. Out-of-tree modules zijn waar dit tot problemen leidt. Een vendor-driver die niet in de mainline zit, moet opnieuw worden gebouwd voor elke nieuwe kernel, wat DKMS doet tijdens een upgrade, en wanneer die build faalt, ontbreekt het apparaat simpelweg na de herstart.

Waarom SMP vijftien jaar nodig had om voltooid te worden

Linux 2.0 was in juni 1996 de eerste kernel met ondersteuning voor symmetric multiprocessing (SMP), wat betekent dat meer dan één CPU dezelfde kernel uitvoert. De eerste implementatie maakte gebruik van één enkel slot, het big kernel lock (BKL), waardoor er telkens slechts één processor in de kernelcode kon zijn. Een tweede CPU hielp daarom bij een werklast die in de user space berekent, maar hielp nauwelijks bij een werklast met systeemaanroepen, omdat deze in de wachtrij stonden achter hetzelfde slot.

Het verwijderen van dat slot duurde vijftien jaar. De resterende gebruikers werden grotendeels door Arnd Bergmann omgezet naar fine-grained locking, en het BKL werd verwijderd in 2.6.39, uitgebracht op 18 mei 2011. De scheduler ontwikkelde zich in hetzelfde trage tempo: de O(1) scheduler in 2.6.0, de Completely Fair Scheduler (CFS) vanaf 2.6.23 in 2007, en EEVDF, die in 6.6 in oktober 2023 de plaats innam van CFS.

Dat werk is de reden waarom een plan met 4 vCPU's tegenwoordig heel gewoon is. Het markeert ook een grens die het waard is om te kennen. Op een gedeelde virtuele server plant uw kernel uw threads, en de hypervisor plant uw kernel. Voer top uit en lees het veld %st. Steal time is CPU-tijd die uw kernel klaar was om te gebruiken, maar die de host aan een andere gast heeft gegeven; optimalisatie binnen uw kernel kan dit dus niet herstellen.

Waarom de 2.6-serie de manier waarop de kernel wordt gebouwd veranderde

Vóór 2.6 kwamen versienummers in paren. Een even tweede getal betekende een stabiele serie (2.4), een oneven getal betekende ontwikkeling (2.5). 2.4 werd uitgebracht op 4 januari 2001 en 2.6 op 17 december 2003, dus gebruikers wachtten bijna drie jaar op de volgende stabiele serie. Distributies konden niet wachten, dus pasten zij backports toe. Twee leveranciers die beide "2.4" uitleverden, leverden kernels die duizenden patches uit elkaar lagen.

De splitsing werd na 2.6 geschrapt. De mainline opent nu een merge window van ongeveer twee weken, accepteert nieuw werk, draait daarna release candidates totdat het rustig wordt, en brengt elke 9 tot 10 weken een versie uit; het ritme dat kernel.org nog steeds documenteert. De andere helft van het model arriveerde op 4 maart 2005 met de eerste release van de stable tree, een update met uitsluitend fixes voor 2.6.11, onderhouden door Greg Kroah-Hartman en Chris Wright. De stable tree accepteert fixes en weigert nieuwe functies.

Een bijwerking: het versienummer hield op een belofte te zijn. 3.0, 4.0, 5.0 en 7.0 zijn geen herschrijvingen. Torvalds verhoogt het eerste getal wanneer het tweede getal groot genoeg wordt om hem te storen; dit is de reden waarom 7.0 in april 2026 volgde op 6.19. Wat voor een server van belang is, is welke branch uw distributie volgt en of die branch nog steeds fixes ontvangt.

Hoe het BitKeeper-conflict in april 2005 leidde tot de creatie van git

Vanaf februari 2002 werd de kernel ontwikkeld in BitKeeper, een propriëtair gedistribueerd versiebeheersysteem van het bedrijf BitMover van Larry McVoy, beginnend bij de 2.5-serie. BitMover verstrekte kernelontwikkelaars een gratis licentie met voorwaarden: men mocht niet werken aan een concurrerende versiebeheertool en men mocht BitKeeper niet reverse-engineeren. Veel ontwikkelaars vonden het onprettig om een vrije kernel te bouwen met een tool waarvan zij de broncode niet mochten inzien.

Het conflict escaleerde in april 2005, nadat Andrew Tridgell een programma demonstreerde dat communiceerde met BitKeeper-repositories. BitMover bestempelde dit als reverse engineering en trok de gratis licentie in. De kernel verloor midden in een ontwikkelcyclus zijn versiebeheersysteem.

Het werk aan git begon op 3 april 2005. Torvalds kondigde het aan op 6 april. Op 7 april was git self-hosting, wat betekent dat de eigen geschiedenis van git al in git werd bijgehouden. De eerste merge van meerdere branches vond plaats op 18 april. In juni 2005 beheerde git de release van 2.6.12. Torvalds droeg het onderhoud kort daarna over aan Junio Hamano en keerde terug naar de kernel.

Het ontwerp vloeide direct voort uit het probleem: duizenden bijdragers en beheerders die over een onbetrouwbaar netwerk van elkaar pullen. Elk object wordt benoemd op basis van de hash van de inhoud; het wijzigen van één byte in de oude geschiedenis verandert daarom de naam van elke daaropvolgende commit. Daarom is een clone bewijs in plaats van een bewering. Elke deploy-pipeline, elke configuratie-repository, de code-host waar de meeste teams naar pushen en de git-server die u zelf kunt draaien zijn voortgekomen uit een licentiediscussie over een kernel.

Wat het LTS-model belooft en wat niet

Mainline is niet wat u draait. Een mainline-release wordt 9 tot 10 weken later vervangen. De stable-tree bevat gedurende enkele weken na elke release correcties. Longterm-branches, meestal aangeduid als LTS, bevatten deze jarenlang; dit zijn de versies waarop distributies hun systemen bouwen.

2.6.32, uitgebracht in december 2009, is de versie waarmee het model zich bewees. RHEL 6, Debian 6, SUSE Linux Enterprise 11 SP1 en Ubuntu 10.04 LTS leverden deze allemaal, en de branch werd onderhouden tot februari 2016, meer dan zes jaar na de verschijning.

De belofte is meer dan eens gewijzigd. Eerst was het twee jaar, daarna voor sommige branches zes jaar. In 2023 verkortten de stable-maintainers de standaardtermijn tot twee jaar, omdat het backporten naar oude trees veel tijd kost en oude branches in de praktijk nauwelijks worden getest. Op 25 februari 2026 publiceerde Greg Kroah-Hartman opnieuw langere prognoses, na overleg met de bedrijven die afhankelijk zijn van deze branches. Het huidige kader loopt van drie tot zes jaar.

[
  {
    "kernel": "5.10",
    "released": "2020-12-13",
    "eol_projected": "Dec 2026",
    "maintained_for": 6.0
  },
  {
    "kernel": "5.15",
    "released": "2021-10-31",
    "eol_projected": "Dec 2026",
    "maintained_for": 5.1
  },
  {
    "kernel": "6.1",
    "released": "2022-12-11",
    "eol_projected": "Dec 2027",
    "maintained_for": 5.0
  },
  {
    "kernel": "6.6",
    "released": "2023-10-29",
    "eol_projected": "Dec 2027",
    "maintained_for": 4.2
  },
  {
    "kernel": "6.12",
    "released": "2024-11-17",
    "eol_projected": "Dec 2028",
    "maintained_for": 4.1
  },
  {
    "kernel": "6.18",
    "released": "2025-11-30",
    "eol_projected": "Dec 2028",
    "maintained_for": 3.1
  }
]

kernel.org vermeldt 6 longterm-branches per augustus 2026. De oudste, 5.10, zal correcties hebben ontvangen gedurende 6.0 jaar wanneer deze eindigt in Dec 2026. De nieuwste, 6.18, zal naar verwachting lopen tot Dec 2028, wat neerkomt op 3.1 jaar aan correcties.

Beschouw deze data als een ondergrens in plaats van als een contract. De prognoses voor 6.6 en 6.12 schoven beide op in februari 2026, en een branch die door niemand wordt gebruikt, kan voortijdig worden beëindigd. Uw distributie maakt doorgaans de keuze voor u: Debian 13 levert 6.12 en Ubuntu 26.04 LTS levert 7.0. Dat verschil vormt de praktische inhoud van de vraag over LTS versus interim-releases op een server, en het is wat er daadwerkelijk onder de motorkap verandert wanneer u Ubuntu 24.04 naar 26.04 upgradet.

Hieruit volgt één valkuil. uname -r op Ubuntu 24.04 toont iets als 6.8.0-51-generic. Dat is een upstream-basis aangevuld met de eigen backports van de distributie. Het versienummer vertelt u dus waar de branch begon en niet welke specifieke correcties erin zijn verwerkt. Scanners die een kernel beoordelen op basis van de versiestring, genereren om precies deze reden valse meldingen bij distributie-kernels.

Waar de kernel-community momenteel over discussieert

Er zijn twee actuele discussies gaande, en beide gaan over de vraag wie het werk moet verrichten.

Rust werd in december 2022 als infrastructuur in 6.1 geïntroduceerd. In 7.0 verviel het experimentele label, waardoor de kerntalen van de kernel nu C, assembly en Rust zijn, en de build geen nightly compiler meer vereist. Het geschil gaat over het onderhoud. Een C-maintainer die een interface wijzigt, kan Rust-bindings verbreken die hij zelf niet leest; de discussie gaat over wiens taak het is om deze te herstellen.

Het tweede punt van discussie is de bijdrage van AI. Sasha Levin stelde in juli 2025 een beleid voor, nadat een toenemend aantal door machines ondersteunde patches de mailinglijsten bereikte. Het document werd op 23 december 2025 geaccepteerd en is nu opgenomen in de eigen procesdocumentatie van de kernel op docs.kernel.org/process/coding-assistants.html. Een AI-agent mag geen Signed-off-by-tag toevoegen, omdat die regel het Developer Certificate of Origin (DCO) certificeert en alleen een persoon dit kan doen. Ondersteuning wordt aangegeven met een Assisted-by:-tag, die tijdens de review werd gewijzigd van Co-developed-by: omdat een tool geen auteur is. Gegenereerde code moet compatibel zijn met GPL-2.0-only. De persoon die de patch verstuurt, controleert deze en draagt de verantwoordelijkheid ervoor.

De druk achter dit beleid is de benodigde reviewtijd. Het genereren van een patch duurt seconden, terwijl het reviewen ervan een maintainer een hele middag kan kosten. Een tag lost die onbalans niet op. Wat het wel waarborgt, is de herkomst: de geschiedenis blijft vastleggen wie voor elke wijziging heeft getekend; dit is de eigenschap die het DCO in 2004 moest beschermen.

Wat deze geschiedenis betekent voor de server die u huurt

• De licentie is de reden waarom u de kernel waarmee uw provider opstart kunt lezen en opnieuw kunt compileren, en waarom propriëtaire software er nog steeds op draait.
• Het monolithische ontwerp is de reden waarom één driver-bug de hele machine laat herstarten, en waarom een out-of-tree module bij elke kernel-upgrade opnieuw moet worden gebouwd.
• Het release-model is de reden waarom het versienummer u weinig vertelt, terwijl de branch en de end-of-life datum u vrijwel alles vertellen.
• Het type virtualisatie bepaalt wat u überhaupt mag doen: op KVM start u uw eigen kernel op en laadt u modules, terwijl bij container-virtualisatie die de host-kernel deelt, uname -r de versie van de host toont, modprobe faalt en diverse sysctls alleen-lezen zijn.

FAQ

Waarom is de Linux-kernel nog steeds GPLv2 en niet GPLv3?

Torvalds besloot in 2007 tegen GPLv3, voornamelijk vanwege de anti-tivoisatie-eis. Deze verplicht een apparaat dat GPL-code bevat om ook een aangepaste versie van die code te accepteren. Hij beschouwt vergrendelde hardware als een zaak van de fabrikant. Herlicentiëring is in de praktijk bovendien vrijwel onmogelijk, omdat het auteursrecht op de kernel bij duizenden bijdragers ligt en er geen overdrachtsovereenkomst is om op terug te vallen. De kernel is uitsluitend GPL-2.0, waardoor code die alleen onder GPLv3 wordt aangeboden niet kan worden samengevoegd.

Is de Linux-kernel een monolithische kernel of een microkernel?

Monolithisch, met laadbare modules. Stuurprogramma's en bestandssystemen draaien binnen de adresruimte van de kernel, en lsmod toont de modules die op dit moment geladen zijn. Het effect is snelheid aan de ene kant en een grotere impact bij fouten aan de andere kant: een defecte module kan de hele machine laten crashen, terwijl bij een microkernel slechts één proces verloren zou gaan. Sinds 1992 is dit beeld genuanceerd door FUSE-bestandssystemen in de gebruikersruimte en eBPF-programma's die de kernel verifieert voordat ze worden uitgevoerd.

Wat is het verschil tussen mainline, stable en longterm kernels?

Mainline is de tree van Torvalds, die elke 9 tot 10 weken wordt uitgebracht; nieuwe functies komen daar als eerste terecht. Stable neemt de meest recente mainline-release en ontvangt gedurende enkele weken bugfixes. Longterm-branches blijven jarenlang fixes ontvangen en vormen de basis waarop distributies hun kernels bouwen. kernel.org vermeldt de huidige longterm-branches met voor elk een verwachte einddatum.

Accepteert de Linux-kernel code die door AI is geschreven?

Ja, onder een beleid dat in december 2025 is vastgelegd. De tool moet worden vermeld in een Assisted-by:-tag, een AI-agent mag geen Signed-off-by-regel toevoegen en de gegenereerde code moet compatibel zijn met GPL-2.0-only. De menselijke indiener ondertekent de code, wat betekent dat deze de patch heeft beoordeeld en er verantwoordelijkheid voor neemt onder het Developer Certificate of Origin.

Welke kernelversie moet ik op een server draaien?

In vrijwel elk geval de versie die uw distributie onderhoudt. Een distributie-kernel is een longterm-branch aangevuld met backported fixes en tests van de leverancier; dit is de versie waar de images van uw provider en uw ondersteuningsafspraken vanuit gaan. Bouw een nieuwere mainline-kernel wanneer u een specifiek stuurprogramma of een specifieke functie nodig heeft, en controleer de einddatum van de branch waar u naar overstapt voordat u zich hieraan verbindt.