Slo-Tech - Pred šestimi leti je Linuxova skupnost podaljšala podporo za verzije jedra z oznako LTS z dveh na šest let. Natanko šest let pozneje se to ukinja, saj bodo odslej verzije LTS podprte le še dve leti. Razloga sta pomanjkanje oziroma preobremenjenost vzdrževalcev jedra ter nesmotrnost tako dolge podpore, saj je uporabnikov malo. Spremembo je najavil Jonathan Corbet, razvijalec jedra in urednik Linux Weekly News. Sprememba velja za nove različice. To v praksi pomeni, da se bo s koncem podpore za Linux 4.14 januarja prihodnje leto začel prehod. Trenutno so podprte verzije LTS še 6.1, 5.15, 5.10, 5.4 in 4.19.
Corbet je pojasnil, da nadaljnja podpora starih verij ni smiselna, ker jih ljudje preprosto ne uporabljajo več. Druga težava pa so vzdrževalci jedra, ki jih je premalo glede na obseg kode in prirast nove. Večinoma za svoje delo niso plačani in ga opravljajo poleg rednih zaposlitev. Hkrati se povečuje število hroščev, ki se odkrijejo z orodji fuzzer, četudi ti niso kritični. Medtem ko Linux počasi migrira na jezik Rust, vzdrževalci kode ne dohajajo čedalje večjega obsega dela.
Prihodnost Linuxa še ni ogrožena, a organizacija podpore jedru se bo morala spremeniti. V Linux bo treba vlagati več, če želimo kot skupnost z njim pridobiti.
Software gre dandanes vedno bolj v inkrementalno smer, vedno bolj se dela na majhnih spremembah in tudi na svojih projektih vidim da je inkrementalnost edina vzdržna stvar, ker velike spremembe so nočna mora in na koncu več nestabilnosti povzročiš z veliki spremembami kot bi jih s sprotnimi inkrementalnimi.
Je pa naloga vzdrževalcev linux kernela, če se že gremo inkrementalnost, da skrbijo za čimvečjo stabilnost interfacov, potem so tudi bolečine ob nadgradnji manjše.
No sej userspace stvari, spisane za nek kernel, bodo delale tudi na novem kernelu. So where's the issue exactly? Zakaj LTS distroti sploh ostanejo na neki minor verziji, let's say 6.1.y, namesto da bi sam mel rolling release?
V kakšnih scenarijih Kernel ni fully backwards compatible?
me zanima če bo to vplivalo na android telefone. support za te naprave je mogoče šele zadnjih nekaj let postal "sprejemljiv" z do petimi leti supporta. bodo prisiljeni v več dela z backporti, ali bo stanje postalo nekaj podobnega tistemu, da je mesečni patch up to date, niso pa vsi popravki vključeni zraven.
Software gre dandanes vedno bolj v inkrementalno smer, vedno bolj se dela na majhnih spremembah in tudi na svojih projektih vidim da je inkrementalnost edina vzdržna stvar, ker velike spremembe so nočna mora in na koncu več nestabilnosti povzročiš z veliki spremembami kot bi jih s sprotnimi inkrementalnimi.
Pa ne samo nestabilnost. Prej lahko prides na trg z novimi funkcijami, in od tega nekaj dobis nazaj, ter vmes odlocas kaj je pomembneje, glede na sredstva, ki jih imas. Zato se pa tudi uveljavlja model z narocninami, ker licencni na vsako veliko spremembo nima vec smisla.
No sej userspace stvari, spisane za nek kernel, bodo delale tudi na novem kernelu. So where's the issue exactly? Zakaj LTS distroti sploh ostanejo na neki minor verziji, let's say 6.1.y, namesto da bi sam mel rolling release?
V kakšnih scenarijih Kernel ni fully backwards compatible?
Pojma nimam kaj je razlog za tem LTS, ker sam API kernela se tudi v notranjosti ne spreminja drastično (vsaj to kar sam uporabljam). Sem ravno pred kratkim uporabil svoj star driver (i2c->input) pa je šlo BP na 6.4. Tale teden sem portal en MIPI->LVDS bridge driver pa je bilo med 5.neki in 6.4 precej sprememb, ampak bolj takšnih, da so se kakšni headerji preimenovali, pa razne definicije, argumenti funkcij (še kakšen dodaten, drugi tipi returnov itd). Če bi šel kopati globje potem verjamem, da bi na kakšni grafiki/DRM našel kup sprememb v nekaj letih, a ko na splošno brskam po kernel strukturi je precej zadev ki se drastično niso spremenile že konkretno let.
Tako, da kdo te verzije uporablja in zakaj nimam pojma, pa sem sorazmerno kar precej v tem.
LTS-ji so potrebni za tiste, ki uporabljamo customizirana jedra. Predstavljaj si zdaj razne embedded naprave, ki uporabljajo močno pohekan kernel s kupom svojih custom driverjev. Vsake 2 leti bo treba vse portat na nov kernel. Pri teh LTS, ko se poveča samo bugfix, se ti vsi patchi ponavadi applyajo brez problemov.
Zdaj se bo burden za vzdrževanje takih jedel povečal za 3x, ker bo treba tako poratanje (+ debugiranje in testiranje) izvesti vsake 2 leti namesto 6.
Torej mehka prisila da se prisili vse kernel hackerje da mergajo cimvec svojih zadev v core kernel ;)
Torej, če tvoja firma proizvaja neke embedded sisteme, se bo pa vse custom driverje mergalo v upstream kernel? To pomeni še več dela, ker bo Linus zahteval maintainerje, ki bodo te driverje vzdrževali na vseh verzijah. Plus, če se to uporablja zgolj na neki specifični napravi dvomim, da se bo sploh kdaj odobrilo merganje v kernel.
Ne mergat je potrebno le hacke ki spreminjajo core kernel (ali pa jih odstraniti da sploh ni potreben merge), driverje pa spisat kot modul ki komunicira z kernel API. Je johnnyyy povedal da tako dela in so prilagoditve na nov kernel na ta način minimalne.
Če pa gre za kak low-level driver ki se tiče samega CPUja pa to seveda spada v merge in to načeloma poskrbijo že proizvajalci samih CPUjev, sicer menjaš CPU na takega z podporo.
LTS-ji so potrebni za tiste, ki uporabljamo customizirana jedra. Predstavljaj si zdaj razne embedded naprave, ki uporabljajo močno pohekan kernel s kupom svojih custom driverjev. Vsake 2 leti bo treba vse portat na nov kernel. Pri teh LTS, ko se poveča samo bugfix, se ti vsi patchi ponavadi applyajo brez problemov.
Zdaj se bo burden za vzdrževanje takih jedel povečal za 3x, ker bo treba tako poratanje (+ debugiranje in testiranje) izvesti vsake 2 leti namesto 6.
Če je močno pohekan kernel, pač ne greš na novo verzijo dokler RES ni treba...
"Life is hard; it's even harder when you're stupid."
LTS-ji so potrebni za tiste, ki uporabljamo customizirana jedra. Predstavljaj si zdaj razne embedded naprave, ki uporabljajo močno pohekan kernel s kupom svojih custom driverjev. Vsake 2 leti bo treba vse portat na nov kernel. Pri teh LTS, ko se poveča samo bugfix, se ti vsi patchi ponavadi applyajo brez problemov.
Zdaj se bo burden za vzdrževanje takih jedel povečal za 3x, ker bo treba tako poratanje (+ debugiranje in testiranje) izvesti vsake 2 leti namesto 6.
S čim se bolj natančno ukvarjate?
Ker mi smo tudi embedded oz. je to eno izmed področij. Pri nas delamo tako, da imamo nek čip (NXP, ST, Renesas, TI etc.) na katerem bazira (pol)produkt in proizvajalci za čip načeloma dajo kernel/BSP in ga tudi posodabljajo. Ko izzide nova verzija BSPja/vanilla kernela, gledam kaj je novega, katere so napake in kako to vpliva na nas. Potem se naredi odločitev ali se gre v posodobitev ali ne. Po navadi nekih drastičnih bugov/varnostnih popravkov vsaj kar se kernela tiče ni veliko, proti ostalim zadevam v userspacu. Kar se tiče naših driverjev niso "nič posebnega", saj ne delamo čipov. Tako se vse nanaša na neko komunikacijo - SPI/I2C/PCIE/MIPI, kjer se pač naredi kar se mora in potem ali to furamo iz userspace prek lastnega API večinoma pa se vzame nekaj kar že obstaja. In kot sem že prej omenil, da se načeloma ti notranji APIji spreminjajo, ampak ne drastično.
