Názory k článku
Jádro 5.10 bude LTS, tedy s dlouhou podporou do roku 2026

Nechápu, odkud se bere ta představa, že v LTS verzích nejsou chyby. Vývojář napíše nějaký kód. Když v něm je chyba, backportováním toho kódu ta chyba nezmizí. Když v něm chyba není, může se udělat backport špatně a chyba tím vznikne. Takže zatím tu máme větší množství chyb v backportovaných verzích. Dále aktuální verze se testují podstatně víc, než backportované – tedy i šance, že se chyba v aktuální verzi najde, je podstatně vyšší. Pak tu máme chyby, které se prostě opraví v průběhu vývoje, a třeba si toho ani nikdo nevšimne, že to byla významnější chyba. Nebo nikoho nenapadne to backportovat – opět to vede k menšímu množství chyb v aktuální verzi než v LTS.
Takže pak už zbývají jenom chyby ve zcela novém kódu,který v LTS vůbec není. Což lze zase rozdělit do dvou kategorií. Přepsání existující funkcionality – ke kterému se přistupuje ve chvíli, když je ta stará verze beznadějně zabugovaná, takže ten nový kód nejspíš bude mít výrazně méně chyb. A nebo je to nová funkcionalita – kterou prostě nemusíte používat, když se bojíte, že v ní budou chyby.
Pořád mi z toho vychází, že LTS verze má podstatně víc chyb, než aktuální verze. Ono je to taky logické – kdyby veškerý vývoj software směřoval k tomu, že bude čím dál hůř fungovat, bylo by to beznadějné a už bychom se na vývoj dávno vykašlali.

Nerikam, ze tam nejsou chyby. Ty jsou ve vsem.

Rikam, ze tam je chyb mene nez na bleeding edge a ze jsou casto zname a existuji workaroundy.

To je další důležitá věc: co enterprise zákazníci opravdu nemají rádi, to jsou regrese. Pokud něco nefungovalo pět let a nikdo na to v provozu nenarazil, je docela dobrá šance (samozřejmě ne jistota), že na to nenarazí ani dál, pokud nezmění workload. A pokud ho změní, je velká šance, že ten problém odhalí už předprodukční testy. Oproti tomu, když jim v produkci po běžném updatu najednou přestane fungovat něco, co dosud bez problémů fungovalo, tak dokážou být opravdu hodně nepříjemní.

Michal Kubeček: To ale píšete o případu, kdy se na produkci neupdatuje vůbec. Jakmile tam začnete aplikovat jakékoli záplaty, zavádíte tam změny.

Jenže jsou změny a změny.

Je naprosto zásadní rozdíl mezi backportem vybraných změn (do starších LTSS produktů typicky jen bezpečnostní chyby a chyby přímo nareportované nějakým zákazníkem) a upgradem na nové upstream verze, který často kromě nechtěných regresí přináší i nějaké záměrné (i z linuxového jádra se občas vyhodí nějaká funkcionalita).

Na druhou stranu, oficiální LTS větve, které spravují Greg Kroah-Hartman a Sasha Levin, už dnes pro tento účel (chceme jen důležité a neinvazivní opravy, důraz na stabilitu) moc použitelné nejsou.

Jenže jsou změny a změny.
Je naprosto zásadní rozdíl mezi backportem vybraných změn (do starších LTSS produktů typicky jen bezpečnostní chyby a chyby přímo nareportované nějakým zákazníkem) a upgradem na nové upstream verze, který často kromě nechtěných regresí přináší i nějaké záměrné (i z linuxového jádra se občas vyhodí nějaká funkcionalita).

Není vám podezřelé, že je to tvrzení, kterému lze buď věřit nebo nevěřit, ale není to nic, co by se dokládalo nějakými argumenty? Prostě když vezmeme kus kódu a nazveme ho backportem, stává se téměř bezchybným. Věřte nebo ne.

No, tak já tomu nevěřím. Protože vím, že spousta oprav se nedá udělat bez rozbití starší funkcionality. Navíc u spousty oprav jde o koncepční změny a nějaké úpravy v kódu jsou jen třešnička na dortu.

Nebo taková F5 by asi taky potřebovala poučit který směr je ten pravý.
Ano, to je dobrý příklad. „Proč používáte zastaralé protokoly a algoritmy, které budou za chvíli označené jako nedostatečně bezpečné a přestanou být podporovány?“ „No když my tam máme F5, ono to nic novějšího neumí.“

Ondra Satai Nekola: Fascinuje mne tahle víra, že vývojář nějaké aplikace, který ji dobře zná a vyvíjí ji léta, opravuje nějakou chybu a při tom udělá jinou chybu. Pak k tomu přijde někdo, kdo řeší záplaty pro stovky aplikací, takže o té konkrétní aplikaci neví nic – a vezme příslušnou část kódu, čímž ta chyba zanesená tam upstream vývojářem zázračně zmizí, a příslušnou záplatu bezchybně aplikuje (protože to je fyzikální vlastnost záplat, záplatu nelze aplikovat chybně). A kdyby se přeci jen tímhle zázračným procesem do aplikace zanesla chyba, odhalí se během testování té patchované verze. Zatímco když se původní kód testuje řádově víc, na chybu se samozřejmě nepřijde.

Omlouvám se, že ten popis zní tak směšně, ale nedokážu s vážnou tváří popisovat, jak při patchování všechny chyby z kódu mizí a žádné nové vzniknout nemohou.

Chcete vědět, jak to vypadá doopravdy? V letité knihovně máte funkci, která převolává systémové volání, přičemž se zjistí, že to systémové volání má nebezpečně nastavené defaulty. Sice je to chyba toho systémového volání (a uživatel má možnost ve vaší knihovně nastavení změnit), ale rozhodnete se udělat úpravu i ve vaší knihovně. Jenže změnou nastavení té funkce byste rozbil vše, co očekává, že je tam ten default. Takže nezbývá, než označit tu původní funkci za zastaralou a vytvořit místo ní novou, která obejde ty špatně nastavené systémové defaulty. A doporučíte používat tu novou funkci a ve stávajícím kódu najít, kde se ta stará funkce používá a upravit kód tak, aby byl bezpečný – např. přechodem na novou funkci, pokud je to možné.

Pak přijde správce balíčku z nějaké distribuce a zeptá se: „Tohle je commit, který opravuje tohle CVE?“ Vy mu potvrdíte, že ano, a tak on vesele aplikuje patch, který přidává novou funkci, do své distribuce, a má odškrtnuto, že je CVE vyřešeno. Přitom ale veškerý kód dál volá tu starou nebezpečnou funkci – a novou funkci ani volat nemůže, protože v oficiálním API té verze, kterou používá, ta nová funkce vůbec není. A uživatelé jsou spokojeni, mají LTS verzi s backportovanou opravou bezpečnostní chyby. Naštěstí je to chyba, která nemá své jméno a web, nikdo na ní neútočí, takže to ani nikdo nepozná, že celý ten slavný backport opravy je k ničemu.

Ano, regrese tohoto typu se opravdu také stávají, ale je to řádově méně často než regrese při upgradu na novou upstream verzi.

Michal Kubeček: Ty regrese, o kterých víte. Když ale někdo backportováním vyrobí zcela novou chybu (protože výsledek backportování je jiný kód, než je kdekoli jinde), nejspíš na ni nepřijdete.

Ty regrese, o kterých víte. Když ale někdo backportováním vyrobí zcela novou chybu (protože výsledek backportování je jiný kód, než je kdekoli jinde), nejspíš na ni nepřijdete.

Nevidím jediný důvod, proč by procento objevených regresí vůči všem regresím mělo být u backportů nějak zásadně nižší než u upgradu na novou verzi. (A i kdyby bylo, znamenalo by to v důsledku, že jsou méně závažné.) A zkušenost z těch necelých deseti let, co se tím živím, je taková, že těch známých regresí ve střízlivě prováděných backportech je řádově méně než v nových verzích. Takže mám dobrý důvod předpokládat, že podobně je to i s počtem všech regresí.

Aby nedošlo k nedorozumění: nebavím se tady o všech možných drobných chybách, na které se někde přijde. Bavím se o chybách, na které nějaký skutečný zákazník narazil v praxi a nareportoval nám je. Např. regresí, na které zákazníci narazí při upgradu ze SLE12-SP2 nebo SLE12-SP3 (jádro 4.4) na SLE12-SP5 nebo SLE15-SP1 (jádro 4.12), je řádově více než těch, které se objeví ve SLE12-SP2/3 kvůli backportům. I když je riziko pro jednotlivý backport vyšší než u upstreamové opravy (dejme tomu), celkový počet regresí je podstatně nižší už prostě proto, že se těch backportů dělá mnohem méně - a v nových verzích navíc nejsou zdaleka jen opravy. (Tohle je právě v posledních letech problém s oficiálními LTS jádry, kam se už backportuje kde co.)

Oni ti enterprise zákazníci nejsou úplně hloupí, aby platili nemalé částky za LTSS, kdyby ve výsledku měli kvůli tomu nakonec víc regresí než při neustálých upgradech na nové verze. Nebo myslíte, že ty backporty až někam do 2.6.16 (a ještě se zachováním kABI) děláme proto, že nás to baví?

@Michal Kubeček

Hezké zkušenosti. Čistě ze zvědavosti, segmentovali jste ještě nějak incidenty podle zákazníků, jejich zaměření a účelu systému? Protože kromě této statistiky, které naprosto věřím, mě napadá, že o updaty s backportovanými fixy možná stojí jiní zákazníci a v jiných užitných případech, než ti, kteří raději updatují. Tím se taky může lišit jak jejich citlivost na chyby, tak intenzita testování (jinou intenzitou testujete systém, který intenzivně vyvíjíte a zároveň necháváte aktualizovat i systém, a jinou intenzitou už v podstatě zmražený systém, kde preferujete backporty). Máte k tomu nějaké poznatky?

Takhle do hloubky jsem to nezkoumal, to by byla spíš otázka pro product management nebo markeťáky. Ale na základě toho, co vidím, bych souhlasil, že je to do velké míry dáno charakterem konkrétního nasazení, kde se ten SLES používá, jestli je to spíš něco, co se samo rychle vyvíjí a je důležitá podpora nového hardware a nové featury OS, nebo produkt, který má spolehlivě fungovat roky v pokud možno neměnné podobě a kde je primární minimalizovat riziko nežádoucích překvapení.

Michal Kubeček: V tom je právě ten rozdíl. Že vy píšete o vybraných chybách, které objevil zákazník a reportoval je. Když server podporuje TLS 1.1 a nic novějšího, je to z vašeho pohledu v pohodě – není to regrese, naopak je to feature, že má zákazník přesně tu sadu vlastností, které si kdysi koupil. Akorát že já to považuju za dost velký bezpečnostní problém.

Oni ti enterprise zákazníci nejsou úplně hloupí, aby platili nemalé částky za LTSS, kdyby ve výsledku měli kvůli tomu nakonec víc regresí než při neustálých upgradech na nové verze.
Ono to také může být dané tím, že tu verzi po enterprise zákazníkovi požaduje jiný enterprise dodavatel řešení. Pro kterého je to samozřejmě snazší – a to, že je kolem toho jeho systému spousta chyb, to není jeho starost.

Jenom si na to, jak super jsou ty LTSS verze, vzpomeňte, až zase někde v diskusi budeme číst nářky nad tím, jak se ty nové aplikace distribuují nemožně pomocí Docker kontejnerů nebo snapů, do kterých administrátor nevidí. On si život samozřejmě cestu najde – akorát ta cesta možná nebude za dlouhodobou podporu považovat záplatování historického kódu.

Když server podporuje TLS 1.1 a nic novějšího, je to z vašeho pohledu v pohodě

To je ovšem vaše tvrzení, že je to podle mne v pohodě, takže si s tím polemizujte dle libosti, ale budete muset sám, mne se to netýká.

Jenom si na to, jak super jsou ty LTSS verze

Netvrdil jsem, že jsou super, tvrdil jsem, že LTSS má svůj smysl a že pro konkrétní zákazníky a konkrétní účely, se hodí víc. Netvrdil jsem, že je vhodné pro všechny nebo dokonce všude (koneckonců už v 10:27 jsem tvrdil opak).

...vzpomeňte, až zase někde v diskusi budeme číst nářky nad tím, jak se ty nové aplikace distribuují nemožně pomocí Docker kontejnerů nebo snapů, do kterých administrátor nevidí. On si život samozřejmě cestu najde – akorát ta cesta možná nebude za dlouhodobou podporu považovat záplatování historického kódu.

LTSS je tady proto, že po něčem takovém je ze strany zákazníků a partnerů poptávka a proto, že jim to pro konkrétní use case vyhovuje lépe než průběžné upgrady. Opravdu to není tak, že bychom je nutili zůstat na starém produktu a oni to chudáci museli obcházet dockerem nebo něčím podobným. Nemluvě o tom, že v rámci LTSS udržujeme i jádra, nad kterými by žádný docker běžet ani nemohl.

Především je chyba představovat si, že všichni zákazníci jsou stejní a chtějí nebo potřebují totéž. Někteří zákazníci opravdu chtějí co nejnovější featury a ideálně i ty, které ještě nejsou ani v 5.9, ale jiní jsou naopak ochotni platit nemalé peníze za to, že jim supportujeme jádro 3.0 nebo dokonce 2.6.16. To, že je těch první víc než dřív, neznamená, že ti druzí zmizeli. (Někdy navíc nejde ani o různé zákazníky, stejná firma může potřebovat různé věci pro různá nasazení.)

Jedna věc je, co kdo chce, druhá je, co si od toho slibuje. Že je po LTS verzích stále velká poptávka je samozřejmě pravda. Akorát že LTS verze nezajišťují to, co se od nich očekává. Očekává se od nich totiž stabilita, bezpečnost a nechybovost. Přičemž všechny tři věci nelze zajistit současně. LTS verze jsou stabilnější (ve smyslu menšího množství změn). Ale za cenu většího množství chyb, včetně bezpečnostních. A zejména ty bezpečnostní chyby si může dovolit čím dál méně uživatelů.
Bohužel je ten přístup „nevadí, že tam jsou bezpečnostní chyby, hlavně když se to nemění“ pořád příliš častý – což vidíme pokaždé, když vyjde zpráva o nějaké vážní bezpečnostní chybě, na kterou existuje oprava, ale pak ještě měsíce vycházejí zprávy, kolik je ještě postižených systémů.

LTS verze jsou stabilnější (ve smyslu menšího množství změn). Ale za cenu většího množství chyb, včetně bezpečnostních. A zejména ty bezpečnostní chyby si může dovolit čím dál méně uživatelů.

Do oprav v LTS verzích se už více promítá úvaha o závažnosti chyby, její zneužitelnosti v praxi, úvaha o tom, jestli je přínosnější chybu opravovat, nebo kombinovat s workaroundem. Od zákazníků LTS verzí se více očekává, že (si) tyto otázky kladou a umějí ve svém případě vyhodnotit.

Aktuální verze proti tomu víc tíhne ke koncepčnímu vyřešení chyb, i za cenu způsobení dočasné, méně závažné chyby, nebo poklesu výkonu z nutného kompromisu. To je pro aktuální verzi zdravé, protože pokládá základy na další roky dopředu.

Podle mě nelze hodnotit, co z toho je "lepší" nebo "horší", oba přístupy jsou platné a hodí se do jiných situací.

Bohužel je ten přístup „nevadí, že tam jsou bezpečnostní chyby, hlavně když se to nemění“ pořád příliš častý – což vidíme pokaždé, když vyjde zpráva o nějaké vážní bezpečnostní chybě, na kterou existuje oprava, ale pak ještě měsíce vycházejí zprávy, kolik je ještě postižených systémů.

To ovšem popisujete jiný problém. Takto nekompetentně by se nemělo přistupovat k vývoji ani u aktuální, ani u LTS verze, pokud chcete mít kvalitní produkt.

Každopádně je na vztahu výrobce-zákazník, aby si mezi sebou určili jakost výrobku a jeho podporu. Odrazí se to i v ceně, a to je opět na jejich vztahu. Vím, že mi namítnete, že tím trpí všichni ostatní - ale to tak prostě je, ti ostatní se mohou chovat stejně nebo jinak, ale musejí s tím počítat. Stejně jako musím počítat, že moje ekologicky solidní auto nevypouští kila mouru, ale sousedovo mi pod okny smrdí, když v zimě ráno túruje motor.

Zrovna zabezpečení sítí se dá obstojně řešit odpovědností. Způsobuje tvoje zařízení problémy?: odpojíme ti přípojku, dokud si to nedáš do pořádku. Způsobuje opakovaně a nepodnikáš kroky k nápravě? Dáme ti výpověď služeb. Poskytovatelé mají v ruce nástroje i možnost spočítat si, jestli se jim vyplatí provoz sanitizovat, nebo se problematických zákazníků zbavovat (nebo jim třeba nabídnout pomoc, pronájem ověřeného zařízení, ...). Ta čísla totiž nejlehčeji rozhodují o tom, kde je optimum. Představa, že silou všem vnutíme to, co si myslíme že je "nejlepší", je naprosto zcestná.

Suhlas.
Tu sa nebavime o PC, ktore ked prestane fungovat alebo sa spomali, tak sa nic neudeje.
Dovodov preco este dlho po zverejeni chyby a zaplaty pocuvame, ze kolko zariadeni je este zranitelnych je viacero. Ani jeden z nich ale nieje o LTS kernelu.
Dve najhlavnejsie dovody su - bud o potrebe dlhsieho casu na aktualizaciu(vi­acere priciny narocnosti) alebo nestaranie sa o system.
Ani jednemu z toho neexistencia LTS verzia nezabrani. Skor naopak, upgrade bude narocnejsi/pro­blematickejsi.
Z mojho pohladu existencia LTS prave pomaha lahsie udrziavat system funkcny a zabezpeceny.

Takto nekompetentně by se nemělo přistupovat k vývoji ani u aktuální, ani u LTS verze, pokud chcete mít kvalitní produkt.
Přesto takto nekompetentní přístup obhajujete. Upstream vývojář (v tom lepším případě) rozumí podstatě chyby, jejím dopadům a souvislostem – a navrhne podle svého vědomí a svědomí nejlepší opravu chyby. Pak k tomu přijde někdo z distribuce, kdo je obvykle daleko méně kompetentní co se týče toho kódu, řešení upstream vývojáře zahodí a navrhne vlastní (ve kterém použije nějaký kus kódu toho upstream vývojáře). A pak ještě přijde koncový správce, který je většinou ještě méně kompetentní, než ten distribuční správce, a rozhodne se, že ta chyba vlastně nevadí.

Samozřejmě, že rozhodnutí, jak je chyba závažná a zda není větší riziko jiných neočekávaných dopadů, je vždy na koncovém správci – který toho bohužel o té chybě většinou neví skoro nic. Akorát bychom si neměli nalhávat, že vytváření backportů je jakýsi magický proces, při kterém se z kódu odpařují chyby. Ne, pokud se bojíme, že upstream vývojář při opravě chyby zanese do programu jinou chybu, pak při backportování té opravy je to riziko ještě daleko větší.

Přesto takto nekompetentní přístup obhajujete.

Obhajuji, aby se optimum hledalo na trhu a ne v laboratoři. Historie mnohokrát ukázala, že lidstvo posunula víc vpřed technicky horší, ale fakticky zvladatelnější technologie.

Pak k tomu přijde někdo z distribuce, (...) řešení upstream vývojáře zahodí a navrhne vlastní (...) A pak ještě přijde koncový správce, (...) a rozhodne se, že ta chyba vlastně nevadí.

Ano, to je to hledání optima. Vývojář by chtěl mít vše nejlepší a mít na to maximum času. Jenže to taky musí někdo koupit. Až v následné praxi se ukáže, že z deseti vytipovaných chyb jen jedna způsobuje problémy. Nebo i často se ukáže, že existuje jedenáctá, daleko závažnější překážka, pro kterou je těch deset vytipovaných naprosto okrajových.

Akorát bychom si neměli nalhávat, že vytváření backportů je jakýsi magický proces, při kterém se z kódu odpařují chyby.

To si nikdo, kdo se v tomto procesu skutečně pohybuje, nemyslí. Jako u všeho, pak se na to nabalí i spousta neumětelů, kteří si to myslí - ale to opět není o tom, jestli bude, nebo nebude existovat LTS vydání. Se stejnou naivitou budou přistupovat i k aktuálnímu.

Ne, pokud se bojíme, že upstream vývojář při opravě chyby zanese do programu jinou chybu, pak při backportování té opravy je to riziko ještě daleko větší.

To si třeba nemyslím. Nad LTS vydáními staví svá řešení i spousta kvalitních vendorů. Díky LTS je jejich pozornost nakoncentrována na několik málo verzí. U aktuálního vývoje se naopak nezřídka stává, že vznikají zmatky, v jaké verzi je chyba objevena a dohledává se, jestli a jak se projevuje v novějších (a někdy i starších). Pozornost je naopak rozdrobená.

Nelíbí se mi Vaše představa, že nešvary lidí, jejich nezodpovědnost, se dají "léčit" tím, že seberete možnosti, které aktuálně považujete za neoptimální. To nefunguje ani v programování, ani jinde.

Miroslav Šilhavý: LTS vydání jsou jen špička ledovce. Já jsem psal o backportování oprav obecně. Oficiální upstream LTS verze jsou při backportování to nejmenší zlo. Já kritizuju především tu představu, že upstream je plný chyb, které backportováním zázračně mizí. Takhle explicitně to tu nikdo nepíše, ale jenom proto, že to opisujete – jakmile se píše o aktuální upstream verzi, řešíte, jak jev ní spousta chyb. A když začnete psát o backportování, najednou tam žádné chyby nejsou a backportováním nevznikají.

Nikde jsem nepsal, že se má nějaká možnost sebrat. Jenom tvrdím, že bychom si konečně měli přestat lhát do kapsy a tvářit se, že aktuální verze jsou plné chyb, ale backporty jsou prakticky bezchybné. To možná platilo před pár desetiletími, kdy většina chyb bylo přetečení bufferu v C a spravilo se to třířádkovým patchem. Dneska už je vývoj software úplně jinde.

@Filip Jirsák

Díváte se na to moc úzce, jako kdyby byla bezpečnost jen skalární a absolutní veličina. Bezpečnost je relativní vůči spolehlivosti (stabilitě) a obojí je relativní vůči zamýšlenému užití. Najdete hodně situací, kdy lze opravdu říct, že LTS vydání je v konkrétním případe bezpečnější volba.

Ale myslím, že toto Vám nemusím vysvětlovat, to vlastně sám píšete. Pak ale možná naopak sklouzáváte do druhého extrému. Jedni možná považují LTS za absolutně nejlepší volbu, Vy naopak za existující zlo, které (jen) křiví vnímání.

Souhlasím, že existuje spousta výrobků na trhu, které ustrnuly i se svými, dodatečně nalezenými chybami. Souhlasím i s tím, že LTS vydání možná přispělo při rozhodování k falešnému pocitu bezpečí. Já k tomu jen dodávám, že to je přirozený a zdravý důsledek hledání optima na trhu. Z dlouhodobého hlediska přežijí ti výrobci, kteří dokáží najít rovnováhu mezi cenou a podporou.

Stačí si přečíst zdejší forum, viditelná část dotazů je na to, jak co nejjednodušeji něco naflikovat - lidé ani sami pro sebe příliš neřeší bezpečnost, a spolehlivost jen do určité míry. Pokud jde o výrobek na pultech, je tento tlak ještě znatelnější. Kolik dotazů tu už bylo "jak oddělit sítě", "chci chránit přístup do banky", a které stejně skončily řešením, které dává jen pocit bezpečí?

Souhlasím i s tím, že LTS vydání možná přispělo při rozhodování k falešnému pocitu bezpečí.
Ne, podle mne za to nemůžou LTS verze v upstreamu – ty jsou důsledek, ne příčina. Za primární problém považuju představu, že dlouhodobě lze podporovat jenom něco, co je neměnné. Ve skutečnosti je to naopak, aby bylo možné něco dlouhodobě podporovat, musí se to přizpůsobovat okolí. No a aby bylo možné téhle divné představě vyhovět, je potřeba si nalhávat, že backportované patche vlastně nic nemění.

Za primární problém považuju představu, že dlouhodobě lze podporovat jenom něco, co je neměnné.

Já si myslím, že taková představa neexistuje. Jen v některých prostředích je to výhodnější (= menší zlo).