Ontwikkelaars verlengen ondersteuning voor Linux 5.10 LTS-kernel tot eind 2026

Linux-ontwikkelaars Greg Kroah-Hartman en Sasha Levin gaan de Linux 5.10-kernel ondersteunen tot december 2026. Genoeg bedrijven en organisaties hebben toegezegd de Linux-kernel te gaan gebruiken, dus willen de ontwikkelaars deze kernel langer ondersteunen.

De nieuwe looptijd voor de verlengde ondersteuning is te zien op The Linux Kernel Archives. Daar staat dat kernel-versie 5.10 pas in december 2026 de end of life-status bereikt. Eerder was versie 5.4 de versie die het langst ondersteund zou worden. Volgens Phoronix bevestigt Kroah-Hartmen dat de kernel nu langer ondersteund gaat worden omdat meer organisaties de Linux-versie gebruiken. Onder meer Debian 11 en Android 12 gebruiken Linux 5.10.

Eind januari meldde Kroah-Hartman nog dat Linux 5.10 LTS slechts tot december 2022 ondersteund zou worden. Hij zei destijds al dat dit besluit niet definitief was, maar zei te willen zien dat meer bedrijven de kernel zouden gebruiken. Anders zou hij niet weten 'of het het waard was om de kernel langer dan twee jaar te ondersteunen'. Linux 5.10 LTS verscheen op 13 december 2020.

Versie	Releasedatum	Voorlopige EOL
5.10	13-12-2020	December 2026
5.4	24-11-2019	December 2025
4.19	22-10-2018	December 2024
4.14	12-11-2017	Januari 2024
4.9	11-12-2016	Januari 2023
4.4	10-01-2016	Februari 2022

Reacties (20)

[The Zep Man]

Eind januari meldde Kroah-Hartman nog dat Linux 5.10 LTS slechts tot december 2022 ondersteund zou worden. Hij zei destijds al dat dit besluit niet definitief was, maar zei te willen zien dat meer bedrijven de kernel zouden gebruiken. Anders zou hij niet weten 'of het het waard was om de kernel langer dan twee jaar te ondersteunen'. Linux 5.10 LTS verscheen op 13 december 2020.

Normaliter worden LTS kernels ook 5-6 jaar ondersteund. Dat 5.10 initieel slechts 2 jaar ondersteuning zou krijgen lijkt op een proefballonnetje, want het week af van wat men in het verleden deed.

Kan er verder weinig over zeggen. Heb verschillende Arch Linux systemen draaien die bij elke update de laatste mainline kernel krijgen, en dat werkt goed. Enkel bij het gebruik van exotische DKMS modules (zoals OpenZFS on Linux) schakel ik voor het specifieke apparaat over van mainline naar LTS releases, omdat de ontwikkeling van de modules nog wel eens achterloopt qua ondersteuning van nieuwe major versions van de kernel.

Daarom ben ik blij met het LTS initiatief. Hiermee blijven systemen die afhankelijk zijn van complexe uitbreidingen aan de kernel doorwerken, terwijl er toch de nodige beveiligingsupdates uitkomen.

[Reactie gewijzigd door The Zep Man op 27 juli 2024 02:25]

[UPPERKEES]

https://external-preview....45ca57868d45413cdcedefd21

[The Zep Man]

De distributie die ik gebruik noem ik in de context. De mainline kernel wordt standaard niet op veel andere distributies aangeboden.

[e.dewaal]

Is het niet beter om de ondersteuningsperiode kort te houden zodat softwaremakers geforceerd worden om goede updatepolicies te hebben?
Geldt ook voor IT beheerders natuurlijk. Als bedrijven processen hebben om systemen in rap tempo te kunnen upgraden zijn lange ondersteuningsperioden helemaal niet nodig.

[Giesber]

Het probleem zit hem erin dat veel producten de nieuwe features niet nodig hebben. Voor een PC geeft een kernel upgrade doorgaans niet al te veel problemen, maar als een set-top box voor bij de TV na een kernel upgrade plots niet meer goed werkt is dat soms lastiger. Als dat bijvoorbeeld zou komen omdat de gebruikte (misschien iets of wat exotische) SOC niet goed samenspeelt met nieuwe kernel code om de slaapstand van een CPU te regelen dan is het nog maar de vraag wie dat gaat oplossen.

De leverancier van de SOC die misschien een andere interpretatie had van een API ergens? Maar die leverancier gaat mogelijk gewoon zeggen dat ze de nieuwe kernel niet ondersteunen. En de kernel developers gaan misschien zeggen dat ze de standaarden volgen, en stiekem interesseert die ene problematische SOC hun niet echt. Maar uiteindelijk is het probleem wel veroorzaakt door een aanpassing die de SOC helemaal niet nodig had.

Vandaar is het zeker voor een OS als Linux, waarvan de kernel op heel veel uiteenlopende systemen gebruikt wordt, een goed verkoopsargument om een versie van de kernel lang te ondersteunen.

Een kortere ondersteuningsperiode kan trouwens ook het omgekeerde effect hebben: als de leverancier van de SOC uit bovenstaand fictief voorbeeld merkt dat die set-top box het enige product is wat nog gebruikt maakt van die versie van de SOC, gaan ze misschien de moeite niet meer doen om te upgraden (wegens verhoogd risico dat er iets stuk gaat), terwijl ze een security patch al wat rapper zullen doen. Dat zou kunnen resulteren in een systeem met gekende beveiligingsproblemen. Je weet wel: winst gaat meestal voor op beveiliging, tenzij beveiliging zo belangrijk is dat het nodig is om winst te maken (zoals bijvoorbeeld bij een bank).

[SVMartin]

Lang niet alle bedrijven hebben de mankracht/kennis/noodzaak om continue systemen te upgraden, daar is het prettig wanneer een distributie wat langere tijd mee kan zonder grote upgrades. Daarnaast kan ik me heel goed voorstellen dat er bedrijven zijn die apparatuur ontwikkelen waar ze een aantal jaren support op willen leveren aan hun klanten. Denk aan mediaspelers, routers/AP's of industriele apparatuur (bijv. meten van luchtvochtigheid/temperatuur in kassen). Ook dan is het prettig dat je de kosten lager kunt houden door een aantal jaren gebruik te maken van een stabiele en veilige kernel en daar bovenop je drivers/software kunt ontwikkelen en testen. Zo'n apparaat heeft geen baat bij de nieuwste software, maar moet wel beschikbaar en veilig blijven.

[Olaf van der Spek]

Ook dan is het prettig dat je de kosten lager kunt houden door een aantal jaren gebruik te maken van een stabiele en veilige kernel en daar bovenop je drivers/software kunt ontwikkelen en testen.

Wat gebeurd er dan als de kernel end-of-life gaat, end-of-support van de hardware?
Klinkt niet als een fijne lange termijn oplossing.

[Reactie gewijzigd door Olaf van der Spek op 27 juli 2024 02:25]

[Maurits van Baerle]

Waarom zou het geen fijne lange termijnoplossing zijn?

Er komt zo’n beetje om de maand een nieuwe Linux kernel uit. Of je om de maand al je software moet testen en eventueel aanpassen of om de paar jaar als je naar de volgende LTS overstapt maakt enorm veel verschil uit.

Als ik bijvoorbeeld naar OpenWRT kijk schat ik dat ze hooguit één keer per jaar upgraden naar de volgende LTS kernel. En dat is best logisch als je ziet wat een werk het is om voor alle architecturen die ze ondersteunen alles iedere keer te moeten nalopen en updaten om het fijn met de nieuwe kernel te laten werken.

Ondertussen updaten ze wel voortdurend de security fixes voor de LTS kernel die ze gebruiken dus de veiligheid komt niet in het geding.

[madcow22]

Ik heb een redelijke moderne PC met een x570 moederbord van amd.
En laatste keer(maand terug) dat ik 5.10 had geprobeert werkte de helft van mijn drivers niet meer. (Audio, LAN, bluetooth, WiFi)
Terwijl in 5.4 zonder problemen al mijn hardware werkt.

[Reactie gewijzigd door madcow22 op 27 juli 2024 02:25]

[sfranken]

Drivers zitten niet in de kernel vaak he, maar worden erbuiten ontwikkeld. Toegegeven, ze maken gebruik van kernel API's, maar dat wil niet zeggen dat de kernel dan meteen "de schuldige" is.

[Verwijderd]

Ja, dat zou men een duw in de rug geven maar ik denk niet dat het hun de juiste 'mentaliteit' geeft.
Die mentaliteit komt eerder als men de applicaties gaat bouwen op moderne technieken zoals containers. Maar ook daar moet men nog steeds een goede update en release cycle aanhouden. Het wordt enkel eenvoudiger om te updaten.

[beerse]

Er zijn altijd meerdere redenen om een korte of een lange life-cycle aan te houden.

Bedenk daarbij ook dat het onderhoud van een stuk software gaat om de bestaande functionaliteit. Als blijkt dat daar issues mee zijn dat die verbeterd worden. Het gaat bij onderhoud beslist NIET om nieuwe functionaliteit. Vergelijk het met een auto: om te blijven rijden heeft de auto onderhoud nodig waarbij soms onderdelen vervangen moeten worden. Maar als je nieuwe/andere functionaliteit nodig hebt zul je een andere moeten kiezen: een opvolger van je huidige model met nieuwe opties of een heel ander model.

[Wolfos]

Dat doet Microsoft tegenwoordig met .NET Core. Wat een drama is dat zeg. Zelfs LTS word maar 3 jaar ondersteund, en updaten is bepaald niet makkelijk.

[bwerg]

geforceerd worden om goede updatepolicies te hebben

Er zit naturlijk wel verschil tussen updaten en upgraden.

De updates binnen een LTS bevatten bugfixes en security-patches. Die zijn in de meeste contexten wel nodig en wil je dus forceren. Maar een upgrade naar een nieuwe LTS zal vooral nieuwe features omvatten, of interne wijzigingen die voor de toekomst leuk zijn. Er is geen enkele reden dat je wie dan ook wil forceren om die laatste categorie wijzigingen binnen te halen - anders dan dat je als ontwikkelaar gewoon niet te veel verschillende versies wil ondersteunen.

[Reactie gewijzigd door bwerg op 27 juli 2024 02:25]

[N8w8]

Er is al het nodige gezegd, maar belangrijk punt is nog dat die ondersteuningsperiode vroeger al kort was. Dat leidde niet tot updates, maar tot apparaten die gewoon niet ondersteund worden.
Vlgs mij was dat ook juist de aanleiding om het te verlengen.

[beerse]

Even rekenen:
4.4: jan 2016 - feb 2022: 6 jaar en 1 maand.
4.9: dec 2016 - jan 2023: 6 jaar en 1 maand.
4.14: nov 2017 - jan 2024: 6 jaar en 2 maand.
4.19: okt 2018 - dec 2024: 6 jaar en 1 maand
5.4: nov 2019 - dec 2025: 6 jaar en 1 maand
5.10: dec 2020 - dec 2026: 6 jaar.
Stiekum toch iets korte? Gewoon weer als-van-ouds ruim 6 jaar ondersteuning?

Volgens mij vragen bedrijven om continuïteit. Voor de kernel zitten daar de distibuties nog tussen, zij leveren de linux aan de gebruikers. Zij bieden vaak ook nog 'back ports' van patches en updates omdat zij de zaken nog langer ondersteunen.

Tussen de 'distributies' moet je ook alles organisaties zien die de linux kernel gebruiken in hardware zoals in nassen, routers en dergelijke. En vergeet ook android niet! De telefoon gebruiker wil langer gebruik maken van haar telefoon. In alle hardware met 'exotische' onderdelen of 'creatief' gebruik hebben speciale aanpassingen nodig voor modules en drivers en zo. Dergelijke aanpassingen zijn in een nieuwe kernel versie niet altijd eenvoudig door te voeren.

[Eonfge]

Standaard Linux LTS is 6 jaar, dus al die andere hebben er gewoon een maand cadeau gekregen.

Maar ja, het is niet altijd zo concreet. 4.4 heeft bijvoorbeeld 10 jaar, maar alleen voor de ARM versies omdat die gebruikt worden in de SCADA controllers van CIP:

https://www.cip-project.o...-the-next-cip-slts-kernel

[DDX]

Wel heel veel LTS smaken die ondersteund moeten blijven worden.
En dan heb je ook nog RedHat die ook hun eigen 'lts' kernel versies kiest.
RHEL7 draait bijvoorbeeld op 3.10 en RHEL8 draait op 4.18

[wpoely86]

De kernel versie bij RHEL vallen niet te vergelijken met de upstream versie. De 3.10 wijst er enkel op dat ze orgineel begonnen zijn met 3.10. Er zijn stukken van veel recentere versie volledig gebackport naar die kernel.

[Frame164]

Hoe moet ik dat eigenlijk zien? Zijn het slechts deze 2 mannen die voor de support zorgen of zit daar nog een groot team achter?