Vlákno názorů k článku RPM, DEB, anebo něco zcela jiného – pár slov k nadcházející linuxové ®evoluci od nettreg - - Základní důvod pro sdílení závislostí není šetření...

- Základní důvod pro sdílení závislostí není šetření disku, ale šetřeni RAMky (sdílená knihovna může být v RAMce jen jednou pro víc různých aplikací). A velikost RAM sice taky narůstá, ale ne tak dramaticky jako SSD, plus velký rozmach neupgradovatelných pamětí v noteboocích atp. Takže toto je pořád věc, co má cenu optimalizovat.
- Megabalíčky typu flatpak často mají problém s včasnými bezpečnostními aktualizacemi závislostí. Plus to duplikuje práci, protože to musí řešit každý balíček sám za sebe.
- Přijde mi divné vypichovat "atomické a neměnné" jako protipól k balíčkům se závislostmi. To jsou dvě celkem ortogonální osy. Jenda je o tom, jak moc chceme dovolit modifikace systému mimo balíčkovací systém, druhá o tom, jakou máme granularitu balíčků (málo velkých vs hodně malých). Že jde relativně atomický systém s normálními závislostmi, viz třeba NiXOS (byť tam to není tak striktně enforcované, ale klidně by mohlo).

Plus to duplikuje práci, protože to musí řešit každý balíček sám za sebe.

To taky není úplně pravda. Flatpaky mají sdílené runtimy. Navíc v rámci Flathubu existují dál ještě sdílené moduly. U jejich aktualizace se sice musí aplikace rebuildovat, ale je to něco, co se dá automatizovat. Ve výsledku to množství závislostí, o které se musí správce aplikace starat, může být relativně malé. Na Flathubu třeba spravuju Datovku, která ke svému běhu potřebuje desítky závislostí včetně hromady Qt modulů, já se ale musím starat jen o tři z nich.

Sdílené knihovny jsou hezká teorie, ale v praxi se to moc neděje. https://drewdevault.com/dynlib.html

Výjimka jsou velké molochy typu Qt a GTK, ale ty (a některé další knihovny) jsou díky runtime sdílené i u Flatpaku.

Základní důvod pro sdílení závislostí není šetření disku, ale šetřeni RAMky (sdílená knihovna může být v RAMce jen jednou pro víc různých aplikací) … Megabalíčky typu flatpak často mají problém s včasnými bezpečnostními aktualizacemi závislostí. Plus to duplikuje práci, protože to musí řešit každý balíček sám za sebe.

A to je podle mne zcela zásadní důvod, proč je celá ta "moderní" koncepce úplně špatně. Když je podstatná bezpečnostní chyba v nějaké knihovně, kterou "používá (skoro) všechno", třeba OpenSSL, tak když vyjde distribuční balíček s opravou, vím, že to mám nainstalované (občas musím ještě restartovat pár běžících aplikací, přičemž mám nástroje, které mi řeknou, které to jsou). Kdybych používal ten "moderní" systém, budu muset hlídat, který z té hromady megabalíků už opravu má a který ještě ne. V podstatě je to jako návrat ke staticky linkovaným knihovnám, jen ještě s dalšími nevýhodami navíc.

Z nějakého důvodu si ta moderní koncepce myslí, že updaty v aplikacích jsou rychlejší, než v systému.
Na jedné straně to je pravda, zejména co se týče závislostí na ffmpeg & spol. Jenže pokud jde o bezpečnostní záplaty, tak majoritní distribuce OS vyhrávají na celé čáře!
(Ostatně, všimněte si, jak je - i tady - populární názor: hlavní je funkčnost, bezpečnost mi je vcelku ukradená.)

Z nějakého důvodu si ta moderní koncepce myslí, že updaty v aplikacích jsou rychlejší, než v systému.

Problém je v tom, že u některých to tak opravdu bude. U jiných to bude pomalejší. A pak se najdou i takové, které to neopraví nikdy - nebo přinejmenším ne dokud nevydají nový pack s novou verzí té své aplikace.

U bezpečnostních updatů bývá - dle mých zkušeností - rychlejší systém; v případě úpravy funkčnosti zase aplikace.

"Bezpečnost je mi ukradená" je celkem legitimní zkratka správně formulovaného "u velké části vulnerabilit v mém nasazení neexistuje realistický scénář, jak by jí mohl útočník zneužít k získání přístupu, který už nemá" (jasně, věci jako web browser popř. mail klient bude výjímkou, ale třeba riziko děravé komponenty Steamu, která se jinam než na Steam nepřipojuje je irelevantní, když Steam může nainstalovat breberku v rámci regulérního updatu)

Stejně tak mě třeba neuráží obráběcí linka řízená nějakým Win95...

Svět, kde je jedna knihovna a všichni na ni dynamicky linkují, je sice nádherný, ale z pohledu praxe utopistický. Svět se prostě vydal jiným směrem. Alternativou k flatpakům a snapům, které se tomu snaží dát alespoň nějakou štábní kulturu a přinášejí mechanismy, které bezpečnostní problémy mitigují, jsou instalačky se staticky slinkovanými bundly a random AppImage obrazy.
Aby si byl člověk jistý, že používá jen jednu opravenou knihovnu, musel by používat jen software z pomalu se tenčících (vůči celkovému objemu software) repozitářů a ani u nich by si nemohl být 100% jistý, protože pod tím povrchem pravidel a slibů se nachází realita plná kompromisů. Vzpomínám si, jak jsme dávali dohromady krypto v RHELu, kolik překvapení to přineslo. :)

Tak mimo to, že u flatpaku prostě updatuju runtime a update OpenSSL dostanou všechny balíky které ho používají, ty opravdu kontroluješ u všeho v systému jestli je to s knihovnama slinkované staticky, nebo dynamicky? Protože ani v tradičním balíku tu jistotu nemáš.

ty opravdu kontroluješ u všeho v systému jestli je to s knihovnama slinkované staticky, nebo dynamicky? Protože ani v tradičním balíku tu jistotu nemáš.

Nepoužívání staticky linkovaných knihoven je v pravidlech distribuce už dlouhé roky.

Tak to sa budes dost cudovat az zistis, co vsetko si take browsery nesu so sebou.

To je pěkná teorie. Praxe je taková, že se staticky linkované knihovny používají ve všech distribucích. I ve Fedoře jsme přiznali realitu a správci balíčků se aspoň žádají, ať to přiznají ve spec filu. Kolik z nich opravdu udělá? Nikdo neví. V RHELu vzhledem k tomu, že musíme podporovat i více než 10 let stará vydání, se v tomto ohledu musí dělat taky nepěkné kompromisy.