Názory k článku
Jádra Super Long-Term Support s podporou 10 let

Hmm a není to málo, Ivan Pavloviči? Chci říct, když existuje SLTS, má vůbec cenu držet ostatní, byť zkrácené jako 4.14, 5.15 etc?

Na 4.14 a 5.15 už dávno někdo postavil řešení, která bude prodávat roky, takže říct "tak na to kašlem" nejde.

Určitě se LTS podpora jader v budoucnu změní, ale rozhodně ne již pro vydaná jádra. To by mohlo způsobit nepříjemný precedens a to, že se firmy nemohou spolehnout na správce jádra..

4.14 je pořád novější, než 4.4, takže pokud se někdo v době, kdy bylo vydáno 4.14, rozhodoval, které jádro použít a délka podpory 4.14 mu stačilo, byla ta rozhodně lepší volba – protože už tehdy existovaly chyby opravené v 4.14 a neopravené v 4.4. No a desetiletá podpora založená na jediném člověku – nic proti Pavlovi, ale jeden člověk nemůže usledovat po dobu deseti let, co všechno se v jádru děje a jestli to nemá dopad na bezpečnost deset let starého jádra.

Ad jeden člověk nemůže usledovat po dobu deseti let, co všechno se v jádru děje: ani Linus ne? ;o)

Ani Linus ne.

No je jich tam na to více, a nezapomeňte, že ta jádra jsou "podobná" - sdílí nemalou část kódu, tzn. pokud s něco bugfixuje v upstream jádrech je třeba pouze kontrolovat do jaké až verze zpětně je třeba to backportovat.

Jenže to právě předpokládáte, že někdo dokáže sledovat všechny patche, které jdou do jádra. To je nereálné. Navíc předpokládáte, že oprava bezpečnostní chyby je vždy v jednom patchi. Jenže ani to není vždy pravda. Stává se, že někdo opraví nějakou chybku ve funkci a(), přičemž to vůbec nevypadá jako oprava bezpečnostní chyby. Pak někdo třeba za rok opraví funkci b(), která interně používá a() – a tou kombinací oprav a() a b() se opraví bezpečnostní chyba. Přičemž ten, kdo opravuje b(), si může a nemusí být vědom, že opravil bezpečnostní chybu. Nebo dokonce ani oprava b() nemusí bezpečnostní chybu opravit, protože zneužití chyby zabránila už oprava a().

Nebo jinak – je naivní si myslet, že pokaždé, když se opraví bezpečnostní chyba, ví se o tom, že to byla bezpečnostní chyba. U linuxu bych si tipoval, že tam podíl těch oprav, kde se to ví, bude ještě poměrně vysoký, ale ani tam to nejsou všechny.

Ano i ne. Některé části jádra se výrazně mění, odebírají se porpory různých starých zařízení atd. Může se stát, že v 4.4 je třeba ovladač pro gpuaaa, používající funkci a() a s bezpečnostní chybou o které se ví, ale v 4.14 byl odstraněn cely ovladač včetně funkce a(), kterou jako jediný používal protože byl deprecated a s chybou. No a třeba v 5.1 zase někdo funkci a() znova napsal, protože se zjistilo, že komunita chce gpuaaa pořád podporovat, ale a() je teď napsaná s použitím nějakého rozhraní využívající funkcionalitu přidanou v jádře 5.0, protože ta z 4.14 je deprecated. A backportujte tohle;)
Vím, je to vymyšlený scénář, ale není zas tak daleko od reality.

Docela zajimavy talk na tohle tema mel Ulirch Hecht (maintainer SLTS v4.4) na EOSS2023:

https://www.youtube.com/watch?v=aHnFCd5z3OM
(The End of the Paved Road: Maintaining Linux Kernel 4.4 Beyond LTS - Ulrich Hecht)

Nejsou to verze, která používá android (samozřejmě patřičně ohackované)?

Koukám, že moje oblíbené jádro 2.6.x už asi nikdo neřeší :-(

Podpora 10 let je místy tak o 30 let méně, než ty jádra někde budou dožívat.

Na druhou stranu, je spousta případů, kdy to tak moc vadit nebude. Třeba u malých blackboxů, které sbírají hodnoty z nějakého čidla a umožňují je vyčíst. Takový crosscompilovaný image systém leckdy nepotřebuje ani podporu pro klávesnici.