Až taková náhoda to není. Mezi verzemi jádra je až na velmi řídké výjimky devět nebo deset týdnů (deset je častější) a LTS je už nějakou dobu poslední release v kalendářním roce. Takže je logické, že LTS je každá pátá nebo šestá verze, častěji pátá. Náhoda je jen to, že ten interval šesti verzí naposledy vyšel zrovna tam, kde se opticky zamaskoval tím, že po 4.20 následovala 5.0.
Vzhledem k tomu, že změna hlavní verze 4 5 je arbitrární rozhodnutí Linuse Torvaldse, odvozování LTS verze od čísla minor verze by znamenalo, že LTS verze budou určovány náhodně. Klidně by to mohlo vyjít tak, že by byly dvě verze po sobě minor verze, nebo by mezi nimi naopak byla dvojnásobně dlouhá prodleva.
Vám ten současný systém určování LTS verzí nestačí? Potřeboval byste vědět dřív dopředu, která verze bude LTS? Proč? Nebo by se vám prostě jen líbilo hezčí číslování na úkor logiky?
Bylo by to přehlednější, nicméně bych řekl že spíš je to o tom, že dopředu neví co bude už hotové třeba za půl roku, podobně jako vláda nemůže vědět jak se bude přesně vyvíjet pandemie, no a dost bude záležet jaká dobrá funkce dostatečně stabilní bude užitečná pro enterprise sektor, to je dle mě dost podstatný faktor.
Lepší bude zeptat se Linuse T nebo Grega K-H ;-)
Jaky vyznam ma delat jadra s LTS? Podle toho co vidim, tak to zpusobuje jenom to, ze embedded dlouhodobe zamrzlo prave na tech starych verzich.. tj. 4.4. a 4.9. tohle pak IT segmentu vubec nepomaha, protoze je to na 5 let nulova inovace :/
Jsem zpovykany rolling updatem v Gentoo, a rad bych aby vse melo posledni verze - vcetne jader. Kdo se chce drzet v minulosti.. at si to zpravuje sam prece.
Ono je to opačně. Spousta zařízení z nějakého důvodu zamrzá na staré verzi jádra. Proto začala vznikat LTS jádra – s myšlenkou: „Když už musíte zamrznou na nějaké staré verzi, zamrzněte aspoň všichni na stejné. My vám k ní pak budeme poskytovat bezpečnostní záplaty, a když už vám je takhle na stříbrném podnose nacpeme pod nos, buďte prosím té lásky a zazáplatujte ta vaše zařízení.“ Aspoň někdo pak ty záplaty opravdu používá, třeba zamrzlé distribuce jako RedHat nebo Debian. Takže nebýt LTS, neznamenalo by to, že nebude to dlouhodobé zamrzání – bylo by, stejně, jako dříve, akorát by byla ještě slabší podpora těch starých verzí jádra.
Což nic nemění na tom, že LTS je přežitý koncept. Pak se všichni diví, že jim uživatelé utíkají do cloudu. No jo, když on ten cloud nabízí aktuální věci a ne pět let staré…
Na LTS není nic přežitého, spíš naopak. On ten slavný cloud totiž sám musí na něčem běžet, a to pokud možno na něčem odladěném a podporovaném. K tomu útěku do cloudu, lidé k tomu mají všelijaké dobré i špatné důvody, ale pochybuju, že někdo by se přesunul do cloudu proto, aby mohl denně kompilovat kernel.
LTS není nic odladěného, právě naopak. Je to zcela nový kód, který se oproti aktuálním verzím testuje jen minimálně.
LTS není jen problém jádra, špatný je ten princip jako takový. Pokud má někdo v aktuální distribuci k dispozici rok starý PostgreSQL 11, samozřejmě kouká po Dockeru nebo cloudu, kde má PostgreSQL 13. A tak je to se vším. Zůstáváte (v lepším případě) na TLS 1.2 se známými slabinami, protože TLS 1.3 je pro vaši „aktuální“ distribuci hudba budoucnosti. Pak si tu někdo stěžuje, jak to, že velcí hráči nasazují HTTP/3, když web server v jeho distribuci teprve dospěl k podpoře HTTP/2.
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.
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í.
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.
[quote]
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.
[/quote]
Jenže těch backportů je relativně málo a prochází dalším protestováním než se to pustí do produkce.
Ostatně Váš názor můžete jít vysvětlit třeba Checkpointu, že než držet backporty na security +pár nově použitých karet v nových appliancích, že je lepší kompletně celý produkt přepsat od začátku a lépe než se držet 2.6.18 od Redhatu.
I když wait, oni to už udělali před hodně lety, až na to že 3.10 verze pořád není nejrozumnější nasazovat do produkce (a tuším že do nedávna bez VSX).
Nebo taková F5 by asi taky potřebovala poučit který směr je ten pravý.
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.
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(viacere priciny narocnosti) alebo nestaranie sa o system.
Ani jednemu z toho neexistencia LTS verzia nezabrani. Skor naopak, upgrade bude narocnejsi/problematickejsi.
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í.