Drie LTS-versies van Linux-kernel krijgen tot twee jaar extra ondersteuning

Drie versies van de langetermijnuitvoering van de Linux-kernel krijgen een verlenging van de ondersteuningsperiode. De ondersteuning voor deze LTS-uitvoeringen loopt een tot twee jaar langer door. Toch is er sprake van een afnemende trend in het aantal jaren ondersteuning.

De nieuwste LTS-versie 6.18 krijgt een jaar langer ondersteuning, die daarmee in december 2028 vervalt. Mogelijk wordt dit nog verlengd als daar veel vraag naar is, schrijft opensourcenieuwssite Phoronix. Versie 6.12 van de LTS-uitvoering van de Linux-kernel krijgt er twee jaar ondersteuning bij. Daarmee eindigt de ondersteuning voor die voorgaande LTS-versie in december 2028, in plaats van in december dit jaar. Versie 6.6, die de LTS-release vóór 6.12 was, krijgt een jaar langer ondersteuning en ziet dat daardoor in december 2027 aflopen.

De LTS-uitvoeringen van de Linux-kernel krijgen voor langere periodes updates, inclusief bugfixes en beveiligingsupdates. Doordat de kern van het besturingssysteem in die periode niet verandert, kan dit gebruikers een hogere mate van stabiliteit geven.

Steeds minder jaren

Ondanks de nu aangekondigde verlengingen lopen de supportperiodes voor de LTS-releases van de Linux-kernel terug. De oude versie 5.10 van de LTS-uitvoering van de Linux-kernel heeft in totaal zes jaar ondersteuning, die in december dit jaar verloopt. In diezelfde maand vervalt de ondersteuning voor versie 5.15, die eind 2021 uitkwam. Versies 6.1 en 6.6, die respectievelijk eind 2022 en eind 2023 uitkwamen, krijgen na december 2027 geen ondersteuning meer. De nieuwere versies 6.12 en 6.18, die respectievelijk eind 2024 en eind 2025 uitkwamen, krijgen nog ondersteuning tot december 2028.

Linux-kernelversie	Releasedatum	Nieuwe einddatum ondersteuning	Extra ondersteuning	Totale duur ondersteuning
5.10	Eind 2020	December 2026	Geen	6 jaar
5.15	Eind 2021	December 2026	Geen	5 jaar
6.1	Eind 2022	December 2027	Geen	5 jaar
6.6	Eind 2023	December 2027	+1 jaar	4 jaar
6.12	Eind 2024	December 2028	+2 jaar	4 jaar
6.18	Eind 2025	December 2028	+1 jaar	3 jaar

Linux-kernel LTS-versies support (beeld: Greg Kroah-Hartman)

Reacties (20)

[Niema]

6 jaar voor de long term support versie lijkt me vrij irritant als hier bedrijfsprocessen op gedaan worden. Zodra je fabriek, waterpomp, machine, auto, bustijden informatiebord, McDonalds bestel scherm, server of fatbike schermpje af is en al een 2 jaar oude linux kernel gebruikt moet men bijna al weer upgraden. Vooral bij veel grootschalige low end apparaten lijkt me dit irritant. Ik weet niet of bijvoorbeeld de Deltawerken en andere Nederlandse anti overstromingensapparaten worden aangestuurd op basis van de linux kernel, maar 6 jaar support klinkt best kort. Windows 10 lts gaat een stuk langer mee. Wat mij dan ook verbaasd is hoe het kan dat windows servers zon beperkt success zijn. Veel mensen zijn er al bekend mee en de support periodes ook prima. Hogere uptime, minder onderhoud. Windows 10 iot Enterprise gaat 10+ jaar mee en vereiste upgrades zijn vaak traag, risicos op problemen en arbeidsintensief

[Reactie gewijzigd door Niema op 26 februari 2026 17:27]

[Mars Warrior]

Een gemiddeld infra-object (tunnel, sluis, dam) wordt bestuurd/bediend met een SCADA-systeem van bijv. Siemens of ABB. En die draaien weer op Windows Server vanzelfsprekend. Daar komt geen Linux aan te pas

De feitelijke besturing vindt natuurlijk plaats met PLCs, al dan niet redundant uitgevoerd en in een aantal gevallen bewaakt door aparte veiligheids-PLCs die ingrijpen als er toch iets misgaat.

Je hebt het dan over een levensduur van 10 jaar of zelfs tot 20 jaar (safety PLC's) . Beetje afhankelijk van de productserie. 6 jaar is in de industrie absurd kort.

[TheVivaldi]

Maar dan is Windows ook geen optie voor die servers, want Microsoft geeft ook geen 20 jaar ondersteuning aan een bepaalde serverversie.

Daarbij gaat het hier om ondersteuning vanuit de Linuxontwikkelaars, niet vanuit andere bedrijven. Red Hat en Suse bijvoorbeeld ondersteunen de kernel vier jaar langer (dus in totaal 10 jaar).

[Reactie gewijzigd door TheVivaldi op 26 februari 2026 19:19]

[Niema]

1 upgrade van 2*10 jaar lijkt me echt een stuk beter dan 4*6 jaar bijv. Ik zie nu idd dat Red hat fixes backport naar oudere linux kernels, maar vind dit ook niet echt logisch. Deze linux kenel versies zijn de long term support versies, niet de rolling releases. Als lts niet haalbaar is is dat prima, maar 6 jaar lijkt me niet bepaald long term

[gertjan!]

Laat je niet verwarren door de naam, maar Siemens verkoopt ook een SCADA-systeem welke op Linux draait. Alhoewel deze software 10+ jaren ondersteund wordt, is de ondersteuningsperiode van een bepaalde versie een stuk korter.

Upgrades van deze software (en het besturingssysteem) worden tijdens onderhoudsstremmingen uitgevoerd.

[onok]

Het verschil is dat upgraden naar een nieuwere kernel versie meestal vrij probleemloos gaat. Dat is bij windows toch wel ff anders :P

[Niema]

Hangt er vanaf wat er gebruikt wordt ig. Als je een upgrade niet goed voorbereid kan er best veel stuk gaan. Zie bijvoorbeeld https://www.reddit.com/r/Proxmox/comments/1pbv5t4/comment/nrtaopd/?utm_source=share&utm_medium=mweb3x&utm_name=mweb3xcss&utm_term=1&utm_content=share_button Ik heb geen professie in de IT, dus ik geloof best dat windows echt veel erger is. Ik zou de neiging hebben te denken: upgrades zijn kut

Na een beetje inlezen zie ik nu dat de grootschalige gebruikte distros, zoals red hat linux wel 10+ jaar ondersteuning geven dus dat verklaart voor mij al wel een hele hoop en valt het windows argument in het water

[Hydranet]

Bedrijven zoals Red Hat leveren 10 jaar support op hun kernels die met RHEL met backported security fixes komen. Canonical en Opensuse zullen waarschijnlijk ook zo iets van hetzelfde doen.

[Reactie gewijzigd door Hydranet op 26 februari 2026 19:28]

[TheVivaldi]

Precies, dit is meer zoiets als fabrieksgarantie vs wettelijke garantie. De fabriek geeft misschien maar één jaar fabrieksgarantie, maar je hebt wel langer winkelgarantie. Zo ook bij dit: Linux geeft zes jaar (fabrieks)garantie en Red Hat en Suse tien jaar (winkel)garantie.

[atthias]

enigsins hierop aansluitend vind ik het ook verbazend nu de verbeteringen van hardware en dus de veranderingen daarin teruglopen de support korter word

[Niema]

Ik vind het overkomen als luiheid(of capaciteitstekort ofzo). Ik denk niet dat het een technische beperking is, maar meer of het voor de ontwikkelaars interessant is om het langer vol te houden. Oude hardware wordt niet vaak eruit gegooid dus het zou bijvoorbeeld kunnen dat upgraden minder werk is dan ik me voorstel

[groene henk]

Je gaat toch niet voor een Linux kernel? Je gaat voor een distributie. Die geven support, niet meneer Torvalds. Dus ik snap de relevantie van dit bericht totaal niet.

[Llopigat]

De distro's steunen weer op upstream support. Vandaar. Deze support is juist voor hen bedoeld, niet voor de eindgebruiker.

Bovendien wordt deze kernel ook in andere dingen gebruikt zoals Android.

[Reactie gewijzigd door Llopigat op 26 februari 2026 17:28]

[Niema]

Uiteindelijk heeft dit vrij direct invloed op de support van je distributie. Een distributie heeft aanzienlijke vertraging om een bepaalde linux kernel te gebruiken en de kans dat je dus zonder heftige upgrades een distributie vind die langer werkt dan dit is klein. Langere support periodes zijn wenselijk als je niet constant je computer wil upgraden naar nieuwe versies aangezien dat uren kan duren. Maar ik denk dat dit vooral relevant is voor nerds of bedrijven(zoals mensen die iot apparaten programeren of linux distros ontwikkelaars ) idd. Iig heeft de support cycle van de linux kernel invloed op miljarden apparaten. Sommige bedrijven achter red hat of Ubuntu doen wel aan backporten van fikses naar niet meer ondersteunde kernelsu of tussentijds kernel upgraden

[Reactie gewijzigd door Niema op 26 februari 2026 17:42]

[psdata]

Aan de hand van deze garantstelling van de Kernels kunnen de distributie varianten hun LTS vastleggen.

Het is er gewoon 1 de schakels van de Longterm onderhoud ect.

[bbg0]

Degenen die aan de code werken, die leveren de daadwerkelijke support. Binnen de kernel development community (georganiseerd door de Linux Foundation) is dat dus volgens het LTS schedule zoals hier gepresenteerd. Als je als distributie dus buiten deze termijnen gaat werken, dan kan je niet meer rekenen op hulp van de bredere community.

Maar dat betekent niet dat het opeens onmogelijk is! Bedrijven als Red Hat hebben zelf veel kernel-developers in dienst, en die kunnen hun eigen support-windows dragen. Nog steeds is het goed als hun kernels overeenkomen met de LTS versies, om mee te liften op de hele gemeenschap.

[snoopdoge90]

In de Linux wereld zijn distributies een druppel op de gloeiende plaat. Er is veel meer zooi die de Linux kernel gebruiken dan je denkt. Denk aan je domme 5 euro netwerk switch, smart tvs, telefoons, routers, iot zoals esp, industriële sensoren en controlers, automotive infotainment, en weet ik veel wat ik allemaal nog vergeten ben. Allemaal Linux kernel gebouwd van de source, meestal customized, met een eigen userspace.

[DaggerGun]

Wel goed dat de Linux-kernel die extra LTS-support geeft, want anders heb je gewoon een probleem met security in productie. Maar het laat ook zien hoe langzaam veel bedrijven zijn met migreren. Dat heeft vaak te maken met certificering en dat soort dingen, dat snap ik, maar soms blijft het wel heel lang liggen.

Daardoor moeten kernel-ontwikkelaars hun support maar weer verlengen omdat gebruikers nog niet klaar zijn met overstappen. Technisch is het natuurlijk beter om sneller op nieuwere kernels te zitten, maar in de praktijk blijkt dat gewoon lastig.

[TheVivaldi]

Toch zullen ze wel wat sneller moeten. Je ziet dat bij Windows ook: Microsoft geeft minder lang ondersteuning op Windows dan vroeger (tenzij je de LTSC-versie gebruikt, maar dat doen de meeste bedrijven niet), en dan zullen bedrijven ook mee moeten naar een nieuwere versie. Met Linux zal de knop vast ook wel een keer omgaan.

[Sjah]

uname -r (om versie van je kernel te weten te komen in de bash)