Nemrég olvashattunk róla, hogy harmadára rövidülhet a hosszan támogatott Linux kernelek élettartama. Így a Linux kernel LTS-időszakát a korábbi hatéves időszakról két évre csökkentik a fejlesztők. 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 említettek akkor, hogy nem sokan használják a Linux kernel régebbi verzióit, így nincs sok értelme fenntartani azokat. Én már akkor is azt gondoltam, 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 érinthette jelentősen ez az intézkedés.

A másik, nagyobb probléma, 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. 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.

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.

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.

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.

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.

Szerencsére a fentiek semennyire sem érintik 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.

Öröm olvasni, hogy a Linux kernel 6.1-es verziója is elnyerte ezt a státuszt, így tíz évig lesz támogatva.

A Civil Infrastruktúra Platform projekt tehát kibővítette a szuper hosszú távú stabil (SLTS) rendszermag programját a 6.1-es verziójú sorozattal. A korábban elindított kernel-sorozatokhoz (4.4-cip, 4.19-cip és 5.10-cip) hasonlóan a projekt a 6.1-cip kernel karbantartását is vállalja a kezdeti kiadástól számított legalább 10 évig.

A CIP projekt egy ipari minőségű Linux nyílt forráskódú alapréteget hoz létre, amely lehetővé teszi a polgári infrastruktúra szoftveres építőelemeinek használatát és megvalósítását. A CIP rendszermagok karbantartása a szokásos hosszú távú stabil (LTS) rendszermagokhoz hasonlóan történik, és a CIP rendszermag fejlesztői is részt vesznek az LTS rendszermagok felülvizsgálatában és tesztelésében. Míg a hagyományos LTS rendszermagok karbantartása 6 évről 2 évre csökkent, a CIP rendszermagok 10 éves időtávon kapnak , szükség szerint, javításokat. E meghosszabbított élettartam lehetővé tétele érdekében a CIP rendszermagok aktívan támogatott rendszermagfunkciókat és célarchitektúrát tartalmaznak. Ugyanakkor a CIP rendszermagok befogadják az új hardvereket lehetővé tevő, nem invazív backportokat az újabb fővonalbeli rendszermagokból. A CIP projekt tagjai határozzák meg ezeket a hatóköröket. A CIP projekthez való csatlakozást kéri a projekt, amennyiben valaki számára érdekes ennek az erőfeszítésnek a megerősítése vagy hatókörének bővítése.

„A CIP kernelek fejlesztése és felülvizsgálata ugyanolyan aprólékos odafigyeléssel történik, mint a hagyományos, hosszú távon stabil (LTS) kerneleké” - mondta Yoshi Kobayashi, a CIP projekt TSC elnöke. „Fejlesztőink aktívan részt vesznek az LTS kernelek felülvizsgálatában és tesztelésében, hozzájárulva ezzel a platform általános minőségéhez és biztonságához. Kiemelkedő jelentőségű az IEC 62443 biztonsági szabványon végzett munkánk, amelynek célja a kritikus infrastruktúra-rendszerek ellenálló képességének megerősítése”.

„A 2023-as év végéhez közeledve a CIP projekt a stabilitás és az innováció irányfénye, és elkötelezett az együttműködés előmozdítása mellett, hogy megerősítse ezt az alapvető fontosságú kezdeményezést” - mondta Urs Gleim, a CIP projekt igazgatótanácsának elnöke. „A közösségi szerepvállalás mindig prioritás marad a CIP számára, és az olyan eseményeken való részvétel is kulcsfontosságú, mint a prágai Embedded OSS és a japán Open Source Summit, lehetővé teszi számunkra, hogy kapcsolatba lépjünk közösségünkkel, és még több érdekelt felet hívjunk meg a CIP-projektbe való bekapcsolódásra.”

A Civil Infrastruktúra Platform az ipari automatizálásban és a polgári infrastruktúrában, például a vonatokban és az elektromos hálózatokban használt termékek ipari minőségű szoftvereivel kapcsolatos nyílt forráskódú együttműködést és innovációt ösztönzi.

A Linux kernel 6.1-es verziója mellett is 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.