Geschiedenis van de Linux kernel: bepalende keuzes

De korte geschiedenis van de Linux kernel

De geschiedenis van de Linux-kernel loopt van versie 0.01 in september 1991 tot de 7.x-serie, die tegenwoordig op servers wordt opgestart. De lijst met releases is daarvan het minst interessante onderdeel. Een klein aantal beslissingen bepaalde de vorm van het geheel. Elke beslissing heeft nog steeds gevolgen voor een machine die u vanmiddag huurt. Waarom er in 1991 überhaupt een nieuwe kernel nodig was, maakt deel uit van het langere verhaal van Unix, AT&T-licenties en de rechtszaak die BSD vertraagde.

Data en versienummers in deze tekst zijn afkomstig van kernel.org en de releasegeschiedenis die daar wordt gepubliceerd. 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 in 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 van groter belang was: "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 onder deze licentie 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, grotendeels vanwege de anti-tivoisatie-regel in GPLv3, die vereist dat een apparaat dat GPL-code bevat, ook een gewijzigde kopie van die code moet accepteren. Hij beschouwde vergrendelde hardware als een zaak van de fabrikant zelf. In 2017 publiceerden kernelontwikkelaars de Kernel Enforcement Statement, die alsnog éé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 waarmee u opstart, brengt 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 niet van toepassing is op gebruikersprogramma's die kernel-services gebruiken via normale system calls; dit is de reden waarom propriëtaire databases en monitoring-agents voor Linux kunnen worden geleverd zonder regels te schenden. Een permissieve licentie creëert de tegenovergestelde druk, en dat verschil is het waard om te begrijpen voordat u een platform kiest: zie Linux en FreeBSD als serverplatformen.

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, waardoor het nooit draagbaar zou 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 met 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 heeft ontmoet. De kernel kondigt alleen nieuwe hardware aan, en een user space daemon beslist welke module geladen moet worden en hoe het apparaat genoemd moet worden; dit is hoe apparaatbeheer onderdeel werd van het init-systeem en een deel van de reden waarom systemd moeilijk te vermijden werd.

Modules kochten die flexibiliteit zonder de kosten die het microkernel-ontwerp met zich meebracht. Het isoleren van een driver in een 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 rekening mee gehouden moet worden: 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 bij elke nieuwe kernel opnieuw worden gebouwd, wat DKMS doet tijdens een upgrade, en wanneer die build faalt, ontbreekt het apparaat simpelweg na de reboot.

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 één kernel uitvoert. De eerste implementatie gebruikte een 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 user space rekent, maar hielp nauwelijks bij een werklast met system calls, omdat deze in de wachtrij stonden achter hetzelfde slot.

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

Dat werk is de reden waarom een 4 vCPU-plan tegenwoordig onopvallend is. Het markeert ook een limiet die het waard is om te kennen. Op een gedeelde virtuele server plant uw kernel uw threads in, en de hypervisor plant uw kernel in. Voer top uit en lees het %st-veld. Steal time is CPU-tijd die uw kernel klaar was om te gebruiken, maar die de host aan een andere gast gaf; tuning 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" leverden, verscheepten kernels die duizenden patches van elkaar verschilden.

De splitsing werd na 2.6 losgelaten. Mainline opent nu een merge window van ongeveer twee weken, accepteert nieuw werk, draait vervolgens 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 alleen 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, wat de reden is dat 7.0 volgde op 6.19 in april 2026. Wat voor een server telt, 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 maintainers 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 daardoor 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 licentiegeschil 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 opgevolgd. De stable-tree bevat na elke release nog enkele weken lang correcties. Longterm-branches, meestal aangeduid als LTS, bevatten deze correcties 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 kernel mee, en de branch werd onderhouden tot februari 2016, meer dan zes jaar na de verschijning. Red Hat ging nog verder en voerde eigen backports uit op de 2.6.32-gebaseerde kernel totdat RHEL 6 in 2020 het einde van zijn levenscyclus bereikte. Het reproduceren van dat decennium aan ondersteuning is precies de reden waarom CentOS bestond en Rocky Linux en AlmaLinux het vervingen.

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 naar twee jaar, omdat het backporten naar oude trees veel tijd kost en oude branches nauwelijks nog echt getest worden. Op 25 februari 2026 publiceerde Greg Kroah-Hartman opnieuw langere projecties, na overleg met de bedrijven die afhankelijk zijn van die 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 doorlopen tot Dec 2028, wat neerkomt op 3.1 jaar aan correcties.

Beschouw deze data als een ondergrens, niet als een contract. De projecties voor 6.6 en 6.12 schoven beide op in februari 2026, en een branch die door niemand wordt gebruikt, kan voortijdig worden stopgezet. Uw distributie maakt doorgaans de keuze voor u: Debian 13 levert 6.12 en Ubuntu 26.04 LTS levert 7.0. Dat gat vormt de praktische kern 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, niet welke correcties erin zijn opgenomen. Scanners die een kernel beoordelen op basis van de versiestring genereren om precies deze reden valse meldingen bij distributie-kernels.

Waar de kernel op dit moment 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 geïntroduceerd in 6.1. In 7.0 is het experimentele label verwijderd, 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, en 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. Assistentie wordt aangegeven met een Assisted-by:-tag, die tijdens de review is gewijzigd van Co-developed-by: omdat een tool geen auteur is. Gegenereerde code moet compatibel zijn met GPL-2.0-only. De mens 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 registreren wie voor elke wijziging heeft getekend, wat de eigenschap is 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 eis dwingt een fabrikant die apparatuur met GPL-code levert, om ook een aangepaste versie van die code op het apparaat toe te staan. 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 overeenkomst voor overdracht van rechten is om op terug te vallen. De kernel is GPL-2.0-only, waardoor code die uitsluitend 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 user space en eBPF-programma's die door de kernel worden geverifieerd 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 en waarin nieuwe functies als eerste verschijnen. Stable neemt de meest recente mainline-release en ontvangt gedurende enkele weken bugfixes. Longterm-branches blijven jarenlang fixes ontvangen; dit zijn de versies waarop distributies hun kernels baseren. kernel.org vermeldt de huidige longterm-branches met voor elk een verwachte einddatum (end-of-life).

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 zet zijn handtekening (sign-off), wat betekent dat deze de patch heeft gecontroleerd en de verantwoordelijkheid ervoor 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 end-of-life-datum van de branch waarnaar u overstapt voordat u deze in gebruik neemt.