A hosszan támogatott Linux kernel (angolul: Long-Term Support kernel, röviden LTS kernel) a GNU + Linux és az Android operációs rendszer kernel (a rendszermag, ami a szoftver és a hardver közötti interfészt biztosítja), amely hosszabb időn keresztül kap frissítéseket és támogatást a fejlesztőktől és a közösségtől. A hosszan támogatott kernel fontos szerepet játszik a szerverek, beágyazott rendszerek és olyan eszközök esetében, amelyek stabil működést igényelnek hosszú távon. A jelenlegi támogatási struktúra szerint ezek a kernelek nem csak fél év hibajavító és biztonsági támogatást kaptak, hanem rendszerint háromtól hat évig terjedő kiterjesztett biztonsági támogatást is.

A hosszan támogatott kernel verziókat különböző Linux disztribúciók használják, például az Ubuntu, a CentOS, a Debian, a Red Hat Enterprise Linux és további hosszú támogatást építő terjesztések is. Vagy dönthetnek úgy is, hogy házon belül valósítják meg ezt a hosszú támogatást.

A héten Spanyolországban megrendezett az Open Source Summit Europe konferencián Jonathan Corbet, a Linux kernel egyik vezető fejlesztője bejelentést tett a hosszan támogatott Linux kernelekkel kapcsolatban. Jonathan Corbett, Linux-fejlesztő és az LWN vezető szerkesztője nyilvánosságra hozta, hogy a Linux kernel LTS-időszakát a korábbi hatéves időszakról két évre csökkentik. Jelenleg hat LTS Linux kernel van, a 4.14, 4.19, 5.4, 5.10, 5.15 és 6.1 amit karban kell tartaniuk a karbantartóknak. A jövőben, a 4.14 után, amikor a soron következő kettő kilép az LTS státuszból, nem fogják őket más kernelverziókkal helyettesíteni.

Az egyik ok, amit Jonathan említ, az a tény, hogy nem sokan használják a Linux kernel régebbi verzióit, így nincs sok értelme fenntartani azokat. A magam részéről úgy látom, hogy a régebbi kerneleket azért nagyon sok helyen használják és alkalmazzák – és ha nincsenek is szem előtt az ilyen eszközök, azért a régebbi Linux kernelt alkalmazó publikus infrastruktúra eszközöket, beágyazott eszközöket, telefonokat, routereket érinthet jelentősen ez az intézkedés.

Ezzel kapcsolatban felmerült, hogy a legnagyobb probléma, ami ennek a döntésnek megágyazott a Linux kernel kódjainak karbantartóinak kiégése. A kód ellenőrzése, illetve javítása egy LTS kiadáshoz egy komoly feladat, ami sok szaktudást, időt és energiát vesz igénybe.

Jonathan szerint a karbantartóknak két különböző akadálya van:

• az egyik, hogy sok karbantartó nem kap fizetést a Linux kernel karbantartásáért.
• A másik a „fuzzing” technika használata a hibák megtalálására, ami hasznos, de időnként számos kisebb hibát is felfedezhet, amelyek a karbantartók további beavatkozását is igénylik.

Amikor megkérdezték: „Hogyan kaphatnak segítséget a karbantartók?” – Jonathan azt javasolta, hogy beszéljenek a munkaadójukkal, hogy fizessék ki őket a Linux kernel karbantartói munkájukért. Majd azt is hozzátette, hogy „A vállalatoknak fel kell ismerniük, hogy vissza kell adniuk a Linuxnak, ha továbbra is élvezni akarják annak előnyeit.”

Ez a lépés csökkenti a karbantartók terheit, azonban a régebbi Linux kernelekre támaszkodó rendszereknek lehet, hogy el kell szenvedniük, hogy nem kapják meg az alapvető javításokat, vagy ezt házon belül kell megoldaniuk. A fejlesztőknek és a közösségnek szükségük van további erőforrásokra és munkaerőre ahhoz, hogy hosszú távon támogassák egy adott kernel verziót. Ha egy verziót már nem tartják fenntarthatónak, akkor a támogatási időszak csökkenthető annak érdekében, hogy az erőforrásokat más verziók fejlesztésére és támogatására fordítsák.

Nyilvánvalóan ez a döntés a felhasználók nagy részét nem érinti, de néhány szervezet számára további erőforrásokat kell biztosítani a biztonsági karbantartási feladatokra. A kernel verziók gyorsan fejlődnek, és új funkciókat és javításokat hoznak be. Ezért a frissebb kernel verziók használata előnyös lehet, mivel új hardverek támogatását és egyéb fejlesztéseket tartalmaznak. Az LTS kernel verziók továbbra is fontosak a stabil és hosszú távú rendszerek számára, de az idővel történő frissítések elkerülhetetlenek a biztonság és a teljesítmény szempontjából.

Két év a PC-k esetében jó támogatási időnek tűnik, de mi a helyzet az Androiddal? Az eredeti LTS kiterjesztés elsősorban az Android és az Internet of Things eszközökre gondolva készült - ezt a Google fejlesztője, Iliyan Malchev jelentette be egy Android Linux előadáson. A probléma az volt, hogy a PC-ken a két év csak a kernelfrissítések közötti időt jelenti, tehát ez egy jó időintervallum. A beágyazott eszközök azonban általában nem frissítik a kernelt, így ez a "két év" a fejlesztési ciklus nagy részét és a teljes fogyasztói támogatási ablakot jelenti, és ez nem elég hosszú idő.

Az eredeti kép, amelyet a Google 2017-ben festett, az volt, hogy a telefonok kifejlesztése két évig tart, és hogy a kernelt a mérnöki folyamat elején rögzítik. Az LTS kernel pont akkor érné el az életciklus végét, amikor a telefont végül kiszállítják, és az ügyfelek elavult kernelt használnának a készülékeik élettartama alatt. Az Android kernel fejlesztési folyamata egy rakás kódelágazás: Először a Google egy új Linux LTS-ről elágazik, hogy elkészítse az „Android Common” kernelt, majd ezt elküldi a SoC-gyártóknak, például a Qualcommnak, és minden egyes SoC-modellhez elágazik, majd ezt az elágazást elküldi a készülékgyártóknak, akik minden egyes készülékmodellhez újra elágaznak. Ez eltart egy darabig.

Jobbak lesznek a dolgok 2023-ban? Nem valószínű. Az Android kernel dokumentációjában van egy Linux „kompatibilitási mátrix” az Android minden egyes verziójához, és az Android 14 - amely bármelyik nap megjelenhet - még mindig támogatja az új eszközök indítását a Linux 5.4-es Linux 5.4-es verziójával, ami egy 4 éves kernel. Ez egy új támogatási ablakot fog indítani, ne feledd, így még egy szánalmas két éves tulajdonjoggal is 6 éves kernelről van szó. Ez is csak az új eszközökre vonatkozik. A Linux 4.14-ről frissíthetsz az Android 14-re, ami 2017-re nyúlik vissza. Láthatod, hogyan jutott a Google a hatéves számhoz. Nehéz tudni, hogy minden olcsó Androidos telefon mit csinál éppen, de feltételezem, hogy ezek mind támogatottak, mert még szükség van rájuk.

A hosszan támogatott kernel változatok időtartama általában 2-6 év között volt, de nem minden kernel verziót támogatnak hosszú távon. Azt, hogy egy kernel verziót mennyi ideig támogatnak, a fejlesztők és a disztribúciók határozzák meg. A 2 éves támogatási időszak azt jelenti, hogy a kernel verzióhoz kritikus biztonsági frissítéseket és hibajavításokat biztosítanak legalább 2 évig. Ezután a felhasználóknak át kell térniük egy újabb, frissebb kernel verzióra, ha további támogatást szeretnének.

Azt azonban nem lehet tudni, hogy ez a bejelentés mennyire érinti a Civil Infrastruktúra Platform (CIP) [Civil Infrastructure Platform] által felkarolt kernel verziókat. A Civil Infrastruktúra Platform (CIP) célja, hogy a Linux kernel és más nyílt forráskódú projektek felhasználásával létrehozzon egy ipari szintű eszközrendszer „alapréteget”. Ezt az alapréteget az ipari és polgári infrastruktúra-projektek szempontjából kritikus biztonsági, védelmi, megbízhatósági és egyéb követelményeknek megfelelő szoftver-építőelemeket létrehozó fejlesztők használhatják majd.

Ennek a kiadásaiból látszik, hogy marad továbbra is olyan Linux kernel, amelyeket nagyjából 10 évig támogatnak a fejlesztők. Kevesebb ilyen kernel van, de lényegi változást végső soron talán nem jelent.

A civil infrastruktúra platformnak több munkacsoportja van, amelyek biztosítják a dolgok folyamatos működését. Az alábbiakban a CIP Kernel csapatával folytatott kérdezz-felelek következik:

1. CIP Kernel Team: A CIP projekt célja egy ipari minőségű szoftverek nyílt forráskódú alaprétegének (OSBL) létrehozása, amely lehetővé teszi a polgári infrastruktúra szoftverépítő blokkjainak használatát és megvalósítását. A CIP Kernel Team a Linux kernelért felelős a rendszerépítő blokkban, és az ipari minőségű rendszerek és eszközök életciklusának fenntartását támogatja.

2. Célja: A csapat elsődleges célja a CIP kernel verziók hosszú távú karbantartása, legalább tíz évig, biztosítva ezzel a megbízhatóságot, fenntarthatóságot és biztonságot.

3. Fejlesztési elve: A CIP az "Upstream First" elvet követi, azaz először az upstream (fő forráskód) elfogadását részesíti előnyben. A javításokat csak akkor adják hozzá a projektjükhöz, ha már szerepelnek az upstreamben. Ez lehetővé teszi a kimeneteik megosztását az upstream projektekkel.

4. Upstream First: Az "Upstream First" elv azt jelenti, hogy a CIP Kernel Team először az upstream projekteket, mint például a Linux mainline és az LTS (Long-Term Support) verziókat használja, és csak azután végzi el a saját módosításait.

5. LTS kernel használata: A CIP Kernel Team az LTS kernel verziókat használja a CIP SLTS (Super Long-Term Support) rendszermagok kiadásához, amelyeket hosszú távon, tíz évig támogatnak.

6. CIP kernel használata: Az SLTS kernel verziók integrálásával az ipari rendszerek vagy eszközök fejleszthetők a CIP Core csomagokkal és további csomagokkal.

7. Eredmények: A CIP Kernel Team rendszeresen kiadja a CIP SLTS rendszermagokat az előre meghatározott kiadási ütemezés szerint.

8. Jövőbeli célok: A csapat folytatja a hosszú távú karbantartott kernel verziók kiadását, és a jövőben új SLTS kernel verziók kifejlesztésén is dolgozik.

Összességében a CIP Kernel Team az ipari minőségű rendszerek hosszú távú támogatását és fejlesztését tűzte ki célul, az „Upstream First” elv mentén, és fontos szerepet játszik a polgári infrastruktúra szoftverépítő blokkjainak fejlesztésében és fenntartásában.

Az "EOL" (End of Life) egy rövidítés, ami azt jelenti, hogy egy termék, szoftver vagy szolgáltatás elérte az életciklusának végét. Az EOL bejelenti, hogy a termék vagy szoftver már nem kap frissítéseket, javításokat, támogatást vagy biztonsági frissítéseket a gyártótól vagy fejlesztőktől. Amikor egy termék vagy szoftver eléri az EOL-t, az azt jelenti, hogy a gyártó vagy fejlesztő nem fektet több erőforrást abba, hogy fenntartsa vagy frissítse azt. Ezáltal az EOL termékek vagy szoftverek hosszú távon kockázatot jelenthetnek a biztonság és a kompatibilitás szempontjából, mivel már nem javítják a benne talált hibákat vagy sebezhetőségeket. Felhasználóként fontos figyelembe venni az EOL dátumát, és időben frissíteni vagy cserélni az érintett termékeket vagy szoftvereket, hogy biztonságosan és hatékonyan működjenek, és ne legyenek veszélyeztetve a potenciális biztonsági fenyegetésektől vagy kompatibilitási problémáktól. Az EOL információkat általában a gyártó vagy fejlesztő hivatalos weboldalán vagy közleményeiben teszik közzé.

Összességében tehát enyhül a nyomás a kernel karbantartóin, és a CIP program keretén belül, bár kevesebb kernel lesz hosszan támogatva, azok továbbra is 10 éven keresztül megkapják majd a frissítéseket.