Názory k článku
Linuxové jádro končí se šestiletou podporou LTS, je s ní příliš mnoho práce

Prozatím to situaci vyřešilo, tak uvidíme.

Tím úplně popíráte princip LTS verzí - na nichž je dokonce postavena většina příjmů z Linuxu.

Ano, popírám. To, že je na něčem postavena většina příjmů, neznamená, že to funguje tak, jak si mnozí myslí, že to funguje. LTS verze plní jednu ze dvou věcí, které slibují – mají dlouhodobě neměnné ABI. O tom, že by v nich byly zároveň opravené chyby, o tom já silně pochybuju. Přesnější je říct, že mají jiný a méně testovaný kód, než je v aktuálních verzích.

Pochybovat můžete. V nových verzích je sice více kódu opraveno, ale také je více jiného kódu změněno - včetně zanesení nových chyb. Však do těch LTS verzí se hrabe co nejmíň - prakticky pouze security updaty, a to ještě jen vybraných komponent. Bugy funkčnosti jsou features - zachování původního chování, některý software na tom může záviset (např. může mít workaround, který by po opravě chyby rozbil aplikaci). Ono to taky nikoho moc nebaví, ale funguje to - aspoň ekonomicky.

To, že se do toho hrabe co nejmíň, neznamená, že se tam nezanesou chyby. A nedělají se security updaty. Obvykle se dělá to, že někdo, kdo kódu moc nebo vůbec nerozumí, vezme něco, o čem se domnívá, že je to security patch, a backportuje to na starý kód. To ale v žádném případě není zárukou toho, že vznikne bezpečnostní aktualizace. Linuxové jádro je výjimka, tam to dělají lidé, kteří tuší, o co jde – ale stejně ten kód vidí daleko méně lidí.

Právě jste popsal backportování security updatů. A ne, ne každý je tak neschopný programátor jako vy.

Ano, popsal jsem backportování security updatů – i to, že vůbec není zaručeno, že výsledkem bude oprava bezpečnostní chyby. Zajímalo by mne, jak víte, jak schopný či neschopný programátor jsem. Každopádně to backportování někdy nedělají ani programátoři. Navíc pokud má takový správce na starosti vyšší desítky balíčku, těžko může dobře rozumět tomu, co který patch dělá.

Hádám podle toho, jak soudíte ostatní - zde často fulltime zaměstnance komerčních firem. Pokud se tam udrželi přes zkušební dobu, tak asi tak neschopní nejsou. Ano, třeba neprogramují, ale kódu rozumějí aspoň na úrovni čtení, bez toho by mergování nemohli dělat (znám kolegy, co tuhle práci dělali). Žádná cesta nic nezaručuje, ani ten váš rolling update.

Problém je, že asi nevíte, co se očekává od bezpečnostních oprav. Od bezpečnostních oprav se očekává, že že chybu opraví skoro vždy. To by ale ti vaši fulltime zaměstnanci komerčních firem museli pokrývat všechny bezpečnostní patche. Jakmile ale bezpečnostní patche do nějaké nezanedbatelné míry vyrábí i méně zkušení lidé, najednou nemůžete vědět, zda opravu té chyby, která vás zajímá, dělal někdo zkušený nebo nezkušený. Takže se na ty opravy nemůžete spolehnout.

No a pro pochopení spousty bezpečnostních oprav opravdu nestačí umět číst kód. To platí pro nějaké jednoduché chyby typu buffer overflow, ale když je ta chyba někde ve špatně navrženém procesu, ve špatném časování apod., opravdu nestačí umět číst zdrojový kód.

„Backport bezpečnostní chyby“ v distribuci také může vypadat tak, že maintainer aplikuje na předchozí verzi patch, který označuje nezabezpečenou metodu jako zastaralou a v dokumentaci uvádí, že se místo ní má používat nová metoda. Tato metoda je zavedena tím stejným patchem, a má (logicky) nové rozhraní, tj. není součástí API ani ABI té předchozí „patchované“ verze. Takže jsou tam dokonce dva důvody, proč se dál bude volat ta stará nebezpečná metoda – ale to je maintainerovi jedno, on si udělá čárku, že backportoval bezpečnostní opravu. Ano, tenhle konkrétní příklad je z Debianu, takže je to trochu specifické –ale jak jako koncový uživatel distribuce poznáte, který backport bezpečnostní opravy dělal někdo příčetný a který byl udělá jenom pro tu čárku?

To spíš vy nevíte. Ty bezpečnostní patche tyhle firmy většinou nedělají, jen backportují. A za to se jim platí. Já neříkám, že lidi, co jen umí číst kód, dělají všechny patche. Ty firmy tam mají i experty, kteří řeší ty speciální situace, které popisujete. Jinak ty změny API/ABI jsou běžná věc, ono taky X let záplatovaný RHEL nebo Ubuntu LTS nejsou zas tak moc podobné původní verzi. A někteří zákazníci požadují původní API/ABI, i kdyby bylo označené za nebezpečné. Aspoň budou informování a danou situaci zabezpečí jinak nebo už je v aplikaci, která není z venku přístupná.

Jenom potvrzujete, že to opravdu nefunguje. Žádný bezpečnostní patch neexistuje. Je bezpečnostní oprava, která se v jedné verzi kódu řeší jedním patchem, a v jiné verzi kódu to může být úplně jiný patch, nebo to dokonce bez porušení zpětné kompatibility vůbec vyřešit nejde. Ano, někdy ty patche mohou být podobné nebo stejné, ale není to nijak zaručeno.

Představte si, že někdo v rámci vývoje vylepší funkci X – třeba tam přidá i novou funkcionalitu a při tom lépe ošetří vstupy. Pak je nalezena bezpečnostní chyba ve funkci Y a vyřeší se tím, že se začne volat funkce X, protože už v ní je vyřešen ten problém, který byl ve funkci Y. Když pak někdo jenom backportuje opravu funkce Y, která bude v backportované verzi volat původní funkci X, může tam zůstat pořád stejná bezpečnostní chyba (protože ta původní nevylepšená funkce X mohla mít stejný problém, jako funkce Y), nebo dokonce může vzniknout zcela nová bezpečnostní chyba (způsobená třeba tím chybějícím ošetřením parametrů v původní funkci X).

Ty firmy a jejich experti neřeší všechno. Ani RedHat nemá lidi na to, aby detailně sledovali vývoj všeho, co mají v distribuci. Dokonce ani vývojáři dané aplikace si ne vždy uvědomí, že opravují chybu, která by se dala bezpečnostně zneužít.

Zkrátka je chyba dívat se na backporty jako na přenos hotového a ověřeného kódu do starší verze. Backportem vzniká zcela nová verze kódu, která by potřebovala stejné zacházení, jako běžný nový vývoj – stejné code review, stejné testování. A takové zacházení backporty nemají – ani v LTS verzích kernelu, natož jinde.

To přece neznamená, že backporty nemají smysl. Třeba ne pro vás, ale pro většinu platících uživatelů Linuxu ano. A jejich peníze pohání vývoj i toho Linuxu, o kterém máte idealistickou představu, že to dělají lidi, "kteří tomu rozumí", o volném času po práci.

Pokud backporty nesplňují to, co se od nich očekává, pak nemají smysl v tom, co se od nich očekává. Mohou mít jiný smysl, a nebo také nemusí mít žádný smysl. To, že že se za něco platí, neznamená, že to musí dávat smysl. Peníze na vývoj by byly i z toho, kdyby se přestalo předstírat, že se backportují bezpečnostní opravy do starých verzí, a místo toho by se řešila to, aby bylo možné používat aktuální verze.

Ona to není náhoda, že jsou tak oblíbené webové aplikace, které jsou pořád aktuální. Jsou oblíbené mezi vývojáři i mezi uživateli. Admini mají své teoreticky stabilní programy s málo testovanými backporty, a uživatelé a vývojáři jim zatím utíkají k webu, případně kontejnerům.

Nemusíte mi pořád něco podsouvat, nic o „dělají lidi, "kteří tomu rozumí", o volném času po práci“ jsem nepsal.

> Pokud backporty nesplňují to, co se od nich očekává, pak nemají smysl v tom, co se od nich očekává.

Naštěstí splňují, co se od nich očekává.

> Ona to není náhoda, že jsou tak oblíbené webové aplikace, které jsou pořád aktuální...

Pak nepotřebujete Linux a stačí vám třeba ChromeOS. Oblíbenost webových aplikací je, že programátoři jsou levnější, dají se více přivázat uživatelé a neřeší se GUI toolkit of the year. Taky jde rozdělit práce na specialisty, např. HTML + CSS + nasázení grafiky nedělá programátor. Jinak i desktopová aplikace jde udělat, aby byla aktuální (to, že to neumíte, neznamená, že to nejde). A obráceně deploy webové aplikace vám obvykle shodí sessions, takže odhlásí uživatele.

> Nemusíte mi pořád něco podsouvat, nic o „dělají lidi, "kteří tomu rozumí", o volném času po práci“ jsem nepsal.

Navážel jste se do fulltime zaměstnanců firem zaměřených na Linux.

23. 9. 2023, 14:17 editováno autorem komentáře

Naštěstí splňují, co se od nich očekává.
Očekává se od nich, že budou udržovat kód stejně kvalitní, jako byl v okamžiku, kdy se ta původní verze sestavila a otestovala. A to backporty prostě nesplňují, protože se jim věnuje podstatně méně péče a pozornosti, než měla ta původní verze.

Pak nepotřebujete Linux a stačí vám třeba ChromeOS.
Což je Linux.

Oblíbenost webových aplikací je, že programátoři jsou levnější
To je dost odvážné tvrzení. Docela pochybuju o tom, že programátoři, kteří ve webových technologiích napíšou Google Doc, jsou levnější než ti, kteří v C++ napíšou LibreOffice Writer. Nebo že programátoři Photopea jsou levnější, než programátoři Photoshopu.

dají se více přivázat uživatelé
Jo, a proto si uživatelé pochvalují svobodu, že mají hned nejnovější verzi a nemusí čekat několik let, než jí různí správci schválí.

Taky jde rozdělit práce na specialisty, např. HTML + CSS + nasázení grafiky nedělá programátor.
To můžete u nativních aplikací udělat také.

neřeší se GUI toolkit of the year
To byste se divil.

Jinak i desktopová aplikace jde udělat, aby byla aktuální (to, že to neumíte, neznamená, že to nejde).
Umíte diskutovat jinak, než bez neustálého podsouvání?

Ano, desktopová aplikace jde udělat tak, aby byla aktuální – zařídí si svůj vlastní distribuční kanál a obejde distribuci. Třeba jako webové prohlížeče.

A obráceně deploy webové aplikace vám obvykle shodí sessions, takže odhlásí uživatele.
Nesmysl.

Navážel jste se do fulltime zaměstnanců firem zaměřených na Linux.
Nenavážel. A i kdyby ano, máte s takovým tvrzením polemizovat, ne mi podsouvat něco, co jsem nepsal.

1) Očekáváte špatně.
2) Nemusí být vždy postaven na Linuxu. Stejně jako některé distribuce mají jako plán B i variantu postavenou na jiném OS.
3) Teď nevím, jestli jen netrollíte, jak je u vás zvykem. Mimochodem Photopeu dělá jediný člověk (Ukrajinec žijící v Praze, ale už mnoho let) a moc mu nevydělávala (vím i částku). Snad si nechal poradit, a teď už mu dává víc, vzhledem k tomu, kolik toho ten software umí.
4) Ne, nemají nejnovější verzi (vím, to, protože se tím živím) a jsou plně rukojmími těch, kdo to v dané firmě spravují.
EDIT: Mimo firmy, resp externí uživatelé to samé - my řešíme, kdo uvidí jako verzi.
5) Jak mi u nativní aplikace ne-programátor udělá UI ve Win32/MFC/Gtk*/Qt kód/Qt QML/XML pro WPF/XML pro Android/... I ta řešení postavená na plaintextu (XML, QML, ...) vyžadují možnost program zkompilovat a spustit. Pokud je nějaký náhled, je v programátorském IDE, kde je otevřen program včetně zdrojových kódů.
*) Nejblíž je asi Glade pro Gtk, ale po mnoho let byl kód pro Gtk 3 mixem kódu pro Gtk 2 a 3. Nevím, jak je to dnes, ale vidím, že sekci Issues na GitHubu radši schovali.
6) Už jsem se pár let nesetkal s novými toolkity pro Web, ale jo, dřív to bylo běžné - i když ve větších firmách byly obvykle ignorovány. Dnes jsou spíš toolkity, které se snaží řešit více platforem naráz, ale pokud člověk dělá jen web app, tak je v klidu.
7) Vy se občas ptáte tak, že se domnívám, že nevíte.
8) Ve firmách to jde v nastavení domény. U osobního počítače jak říkáte, vlastní distribuční kanál.
9) Jde to udělat tak, aby je to neodhlásilo. Bohužel běžný level webových programátorů je takový, že to nezvládnou, ani když jim vysvětlím, jak v případě jejich aplikace to udělat (i přes více možností).
10) Ale vy jste to napsal.

23. 9. 2023, 19:24 editováno autorem komentáře

1) To nejsou moje očkávání. Ale je to očekávání většiny lidí.
2) ChromeOS je v tuto chvíli postaven na Linuxu.
3) Psal jste o platech programátorů. Tahle vaše odpověď s tím souvisí jak?
4) Mohou mít chvilku o stupeň starší verzi, ale rozhodně je provozovatel nebude dobrovolně držet na několik let staré verzi.
5) I nativní aplikace se dají programovat v něčem, co má oddělený návrh UI od kódu. A pak tu máme třeba Electron, kde můžete použít pro vývoj webové technologie.
6) Nových nástrojů pro web je spousta. React SSR, Bun, věci kolem Deno, UI knihovny také vznikají jedna za druhou.
9) Tak netvrďte, že se to tak vždy děje. Mimochodem, webové aplikace často na serveru žádnou session nemají.
10) Nenapsal.

1. Většina volí peněženkou a víme jak.
2. Ale pochopil jste z mého příspěvku, že v budoucnu nemusí?
3. Vy mi nevěříte, že jim platí méně?
4. Rozhodně ne?
5. a) Žádný příklad b) Argumentovat Electronem, který je HTML/CSS? To jsme se kruhem vrátili k webařům.
6. Mimo startupy se jedou industry standards. Např Indie je React Native a Japonsko je .NET.
9. A co když je přihlášený?
10. Napsal. Stačí odskrolovat.

1) Znovu opakuji, že to, co lidé dostávají, nemusí být shodné s tím, co očekávají.
2) Pochopil. Ale to nic nemění na tom, že nyní na Linuxu postavený je.
3) Ne.
4) Rozhodně ne. Protože se mu to nevyplatí.
5) Třeba JavaFX. Ano, Electron umožňuje vytvářet desktopové aplikace, nad jejichž distribucí bude bdít správce, a ty aplikace zároveň mohou psát „levní“ weboví vývojáři a UI dělat ne-vývojáři.
6) To vy jste přišel s tím, že se na desktopu řeší GUI toolkit of the year.
9) Vážně nevíte, jak se už hezkou řádku let dělají webové aplikace? Frontend si drží token autentizující uživatele a potřebná data. Na server posílá požadavky spolu s tím tokenem, server je bezestavový, takže každý požadavek může jít na jiný server, což umožňuje backend snadno škálovat. Vás někdy odhlásil GMail, Facebook, Twitter při aktualizaci aplikace?
10) Nenapsal. Stačilo by uvést odkaz na komentář nebo z něj citovat. Jenže žádný takový komentář neexistuje, takže jej nemůžete ani odkázat ani citovat.

1. Znovu opakuji, že to co dostávají, je to, co očekávají.
2. Dnes není zítra.
3. Snad si dokážete vyjet třeba nabídky práce?
4. Třeba za to zákazník zaplatí.
5. JavaFX umřelo a bylo odstraněno z Javy. Ani nemá nativní vzhled. U Electronu jsme tam, kde jsme byli v mě původní argumentaci u HTML/CSS.
9. Takhle se nedělají typické webové aplikace, na které seženete místo v českých firmách. Mimochodem i u klasické session jde nastavit, aby nebyla "in process". A jak říkám, já to umím, ale bojuju s autory jiných aplikací.
10. Vždyť jsem vám řekl, ať si kousek odskrolujete. Ani si nepamatujete, co jste napsal.

Dobře, přesvědčil jste mne, jste troll.

Tak já to o vás věděl, setkali jsme se dřív. Proto taky na vaše příspěvky nereaguju. Ale vy jste si nemohl pomoct a přidal se do vlákna se mnou.

23. 9. 2023, 21:52 editováno autorem komentáře

Takže tu budeme slovíčkařit? Nikde nic takového netvrdím. Do LTS se backportují různé věci. A ne, neoznačuji je jako nová jádra.

"Když to jádro necháte dva roky uležet, tak se tam ta chyba sama spraví?

Asi budete tvrdit, že se tam backportuje oprava té chyby. Jenže tím backportem vznikne nové jádro. Takhle vzniklé nové jádro je řádově méně testované, než aktuální jádro. Nejvíce opravených chyb je zkrátka v nejnovějším jádru, a dlouhodobá podpora je taková hra, která má vzbudit zdání stability."

Jak může být staré jádro ménně testované, když logicky už proběhlo přes více strojů? Nové jádro nemá šanci toto dohnat.
Nejvíc opravených a zanesených chyb je logicky v novém jádru.
Žádná pochybná hra na stabilitu neexistuje.
Nové jádro např. ztrácí data v nějakém případě. Proto se tomu patrně vyhne ten kdo použije LTS verzi.
Co na tom dále nechápete?
Tu předchozí diskuzi přehlédnu. Pana Ladise považuji za fundovaného člověka.

24. 9. 2023, 13:36 editováno autorem komentáře

Jak může být staré jádro ménně testované, když logicky už proběhlo přes více strojů?
Jenže jádro s backportem patche není staré jádro, je to nové jádro.

Co na tom dále nechápete?
Proč si myslíte, že když se vezme starý kód a udělá se v něm úprava, dostanete v jednom případě nový kód, ale v jiném případě vám zůstane ten starý kód.

1. 99,99 % je původní kód. Minimálně řádově více než u nového jádra, kde je třeba otestovat i hodně nesouvisející věci.

2. Jde o cíl. Např přidání nové funkčnosti vs oprava existující.

99,99 % je původní kód.
Jenže chyba je myslet si, že jde o kód. To, co aplikace dělá, je nad kódem – v procesech a postupech.

Je to jako kdybyste chtěl nepravdivá vyjádření v knize hledat tak, že byste se soustředil na písmena a slova, ale neřešil byste význam vět a odstavců.

Ty procesy a postupy jsou vně aplikace. V aplikace je až jejich implementace - kód.

Nevidím v další diskuzi na toto téma smysl.

A ani ste mi nereagoval na hlavní myšlenku prvního příspěvku.

24. 9. 2023, 14:17 editováno autorem komentáře

Příspěvky p. Jirsáka působí jako akademický/fi­lozofický trolling. Podle jeho logiky např nejde udělat oprava v existující verzi* a celý systém LTS podpory je pro něj nesmysl. Mně zas přijde nesmysl jeho tvrzení, že Linux by podobné peníze vydělal jinak, např zmiňovaným přidáváním nových funkcí. V určitý moment je funkcí dostatek, proto spousta closed source software přechází na subscription.

*) Opravy v existující verzi Ubuntu LTS (řekněme že už jsou i novější ne-LTS verze) vytvoří verzi o 0.0.1 vyšší. Takže je to nová verze, není není? Lidi to chápou, ale p. Jirsák se bude hádat.

Podle jeho logiky např nejde udělat oprava v existující verzi*
To jsem nikde nenapsal. Jenom se vám snažím vysvětlit, že tou opravou vznikne nová verze aplikace (ne nutně nové číslo verze, číslovat si to můžete, jak chce – nová verze programu, tj. program, který se chová jinak, než předchozí verze).

celý systém LTS podpory je pro něj nesmysl
Já jsem nepsal, že je to nesmysl. Psal jsem že systém LTS verzí nesplňuje to, co od něj spousta lidí (včetně vás) očekává. Vy očekáváte, že v změny v kódu při vývoji hlavní verze mohou vést chybám, a zároveň očekáváte, že změny v tom samém kódu od těch samých lidí procházející daleko menším testováním k chybám nevedou, pokud ty změny nazvete „backportováním“.

Ostatně, ive zprávičce máte citovaného Jonathana Corbeta, že LTS jádra využívá málo uživatelů.

Mně zas přijde nesmysl jeho tvrzení, že Linux by podobné peníze vydělal jinak, např zmiňovaným přidáváním nových funkcí.
Pořád vycházíte z mylné představy, že když za něco lidé platí, dostávají vždy to, co očekávají.

V určitý moment je funkcí dostatek, proto spousta closed source software přechází na subscription.
Jestli je funkcí dostatek nebo nedostatek je filozofická debata. Na subscription přecházejí firmy proto, že náklady mají průběžně – zaměstnanci chtějí výplatu každý měsíc (analytici, designeři, programátoři, Q&A, support), náklady na provoz jsou také průběžné, takže je pro firmu výhodnější, když má i příjmy průběžně. Navíc je pro všechny lepší, když se software vyvíjí po menších částech a ty se dostávají k zákazníkům průběžně, než když uživatel dostane jednou za několik let podstatně upravenou verzi.

Opravy v existující verzi Ubuntu LTS (řekněme že už jsou i novější ne-LTS verze) vytvoří verzi o 0.0.1 vyšší. Takže je to nová verze, není není? Lidi to chápou, ale p. Jirsák se bude hádat.
Já ale nepíšu o číslování nebo jiném označování verzí, píšu o verzích programu. Dvě verze programu jsou různé, pokud se chovají různě (alespoň v jedné situaci).