Vlákno názorů k článku Neměnný operační systém: odolný útokům nebo uživatelům? od mikro - "Ve zkratce jde o to, že Flatpak může...

malý dokonalý svět bez valných šancí jej prosadit v reálném světě

Ale tohle za mě není vůbec špatně. Každý profi produkt je pro velmi omezenou skupinu lidí. To, že něco v nějakém OS nejde, vůbec automaticky neznamená, že je to špatně. To, že něco nejde je velmi často velmi dobře.

A jinak by mě fakt zajímalo (podruhé), co touhle větou myslíš. Linux se v reálném světě velmi dobře prosadil už před těmito technologiemi.

Ale tohle za mě není vůbec špatně. Každý profi produkt je pro velmi omezenou skupinu lidí. To, že něco v nějakém OS nejde, vůbec automaticky neznamená, že je to špatně. To, že něco nejde je velmi často velmi dobře.

Tohle je mentalita, která dostala BSD tam, kde je. Mnohé věci dělají čistěji, konzervativněji, ale taky se prosadili jen v relativně úzké množině nasazení. Linux se umí okolnímu světu přizpůsobit lépe. Platilo to před 20 lety, kdy se prosadil, a platí do i dnes, kdy si udržuje dominanci.

A jinak by mě fakt zajímalo (podruhé), co touhle větou myslíš. Linux se v reálném světě velmi dobře prosadil už před těmito technologiemi.

Linux se prosadil v jiném kontextu, než jaký platí dnes. Pokud by se pořád držel jen toho, co fungovalo před 20 lety, tak nebude mít odpovědi na dnešní dobu. IT před 20 lety bylo přece jen dost odlišné. Už jen personálně: před 20 lety Linux ujídal komerčním Unixům, to znamená, že na něj přecházeli admini, kteří měli unixové návyky v krvi. Jenže pak se tento růst vyčerpal a Linux musel začít růst na úkor Windows nebo získávat nové instalace s úplně novými adminy. A tihle lidi mají úplně jiné návyky a schopnosti a i tomu se musí Linux přizpůsobovat. Kdyby se Linux nepřizpůsoboval a byl jen pro úzkou skupinu expertů, kteří mají Unix v krvi, tak si to dominantní postavení neudrží.
A úplně stejně to platí pro vývojáře: před 20 lety pro Linux psali software lidi, pro které to byla primární, nebo i jedná platforma, kterou dokonale znají. Dnes pro něj píše podstatně větší množství vývojářů, ale takových, pro které je to třeba druhý nebo až třetí systém, který musí podporovat.

Jinak asi je chybné se bavit o Linuxu jako o nějaké entitě. Nic takového není. Ultimátně mají kontrolu nad nějakými pravidly distribuce a žádná sama o sobě nemá dostatečnou váhu, aby něco opravdu natvrdo prosadila. To si může dovolit Apple, který má do svého ekosystému uzamknuté stovky milionů lidí s iPhonem, ale my kdybychom začali něco natvrdo prosazovat, tak za pár měsíců jsou zákazníci na AlmaLinuxu, nebo do roka na Debianu nebo Ubuntu. Kvůli tomu, jsou tvůrci linuxových distribucí spíše ve vleku celého odvětví, než že by mu mohli něco diktovat. Na jednu stranu je to nutí odpovídat na poptávku a držet si tak uživatele a zákazníky, na druhou stranu to s sebou nese omezené možnosti, jak věci ovlivnit.

Kdyby tu nebyl Flatpak, tak se budou uživatelům distribuovat balíčky s binárkami, které do systému instalují kdoví co, AppImage, které do systému mountují kdoví co apod. Tvůrců, kteří by šli a dali si tu práci udělat aplikaci pro Linux pořádně a řádně ji udržovali, by navíc bylo minimum. V tomto jsem realista. I když okno do alternativní reality nemám a dokázat to tak nemůžu.

20. 9. 2024, 18:28 editováno autorem komentáře

Tohle je mentalita, která dostala BSD tam, kde je.

Ano, za mě super.

úzké množině nasazení

Což není špatně.

A tihle lidi mají úplně jiné návyky a schopnosti a i tomu se musí Linux přizpůsobovat.

Ne nemusí. Tohle je blbost na entou. Když mi do kuchyně začnou chodit pekaři, tak to fakt neznamená, že začnu guláš kynout.

A za druhé, už je tady jedna generace, která se narodila a vyrostla už v době dávno po unixu, po vzniku linuxu. Tohle není žádný problém z hlediska starých unixových adminů. Tyhle lidi lze naučit linux přímo od nuly. A není to žádný problém. Ve své (skoro už 20 let) praxi jsem vychoval několik linux adminů. Vůbec není důvod se odkazoval na Windows. Ti lidé moc dobře vědí (tak jak jsme to věděli my), že existuje více OS, mají zvědavost (tak jako my), takže není vůbec žádný problém z kompletního nováčka udělat za rok, dva linux admina a současně není žádný problém se od nich učit. Takže fakt vůbec není potřeba linux přizpůsobovat windows nebo čemukoliv jinému. Tohle mám ze své každodenní praxe.

kdybychom začali něco natvrdo prosazovat, tak za pár měsíců jsou zákazníci na AlmaLinuxu, nebo do roka na Debianu nebo Ubuntu

No a v čem je problém? Ať si každý používá co chce. Já Debian a FreeBSD a nosím trička ArchLinuxu.

Kdyby tu nebyl Flatpak, tak se budou uživatelům distribuovat balíčky s binárkami, které do systému instalují kdoví co, AppImage, které do systému mountují kdoví co apod.

Tohle si nemyslím. Osobně si myslím a celý život to tak praktikuju (a určitě nejsem jediný), že když něco nejde, tak se zamyslím nad tím, jestli to dělám dobře. Potom zjistím, že ne, a udělám to lépe. Z tohoto plyne moje přesvědčení, že čím více různých zakrývacích vrstev existuje, tím nakonec hůře.

Triviální příklad. Někdy kolem roku 2010 jsem přešel na Debian (z CentOSu), věděl jsem, že nechci dělat bash skripty na kde co a hledal jsem systémový způsob. Prakticky měsíc po přechodu na Debian jsem se naučil dělat deb balíčky a do nich vkládat závislosti. Takže dneska i když znám třeba Ansible, tak jej (pro soukromé projekty) nepoužívám, protože po minimální instalaci debu stačí nainstalovat jeden balíček a systém mám v odpovídajícím stavu.

Kdyby do mě někdo narval, že existuje Ansible a Flatpak a že deb je dáběl ;-), tak bych to dodnes dělal blbě. Takto mi fakt stačí minimální instalace a s využitím standardním prostředků distra se obejdu bez ansible a flatpaku a hromady dalších věcí.

Ne nemusí. Tohle je blbost na entou. Když mi do kuchyně začnou chodit pekaři, tak to fakt neznamená, že začnu guláš kynout.

Když jsme u těch kuchařů, tak pokud mám jednu špičkovou michelinskou restauraci, můžu tam mít špičkové nároky na kuchaře. Pokud potřebuju zajistit chod 200 restaurací, tak prostě nemůžu mít nároky na úrovni michelinské restaurace, protože tolik kuchařů na takové úrovni prostě neseženu. Budu rád za kuchaře s mnohem menšími schopnostmi a možná budu rád i za toho pekaře. Ho nenechám kynout guláš, ale recepty pro něj budu muset patřičně zjednodušit, protože nejenže nikdy před tím pořádně nevařil, ale ani nemá čas se do toho pořádně ponořit, protože půlku směny musí pořád péct.

No a v čem je problém? Ať si každý používá co chce. Já Debian a FreeBSD a nosím trička ArchLinuxu.

V čem je problém? No samozřejmě v penězích. Ukaž mi firmu, která ti řekne, ať jde klidně většina zákazníků používat konkurenci, že budou jen rádi. Ale tohle neplatí jen pro komerční distribuce. I dobrovolník třeba v Debianu je motivovaný tím, aby zrovna Debian používalo co nejvíc lidí. Kdyby všichni utekli k jiných distribucím, protože se Debian uživatelům nepřizpůsobil, taky by z toho nadšený nebyl.

Jinak díváš se na to optikou špičkového admina s dekádami zkušeností, ale takových lidí je zoufale málo. Šlechtí tě, že jsi vychoval pár dalších dobrých adminů, ale my to vidíme v trochu jiném měřítku, kdo ty naše systémy obsluhuje. Čím populárnější RHEL a Linux obecně je, tím se laťka lidí, kteří ho obsluhují snižuje. Gaussova křivka je v tomto neúprosná. A není to nutně o inteligenci nebo schopnosti těch lidí, ale často to jsou lidi, pro které je to naprostá bokovka a nemají motivaci a čas se v tom výrazně zlepšit. Nemělo by to tak být, ale je.

I dobrovolník třeba v Debianu je motivovaný tím, aby zrovna Debian používalo co nejvíc lidí.

To teda fakt nevím. Já tu snahu o co největší zastoupení linuxu nikdy neměl a nikdy jsem ji nechápal. U spousty činností vidím lidi, kteří moc nemají rádi, když jejich produkt používá někdo, kdo tomu vůbec nerozumí a neváží si toho.

Gaussova křivka je v tomto neúprosná.

Pokud se kvalita lidí s počtem snižuje, tak to znamená pro ně vytvářet takové prostředí, které je nasměruje tu věc udělat snadno a správně. A to fakt neznamená tam dávat další vrstvy, které zakryjí nějakou chybu a nebude na ni vidět. Protože ta chyba někdy vyhřezne. A kdo to potom bude řešit? Další, méně zkušení admini?

ale často to jsou lidi, pro které je to naprostá bokovka a nemají motivaci a čas se v tom výrazně zlepšit.

Tohle je hromada dalších problémů k diskusi. A i tihle lidi a možná o to víc, potřebují snadný přístup k pravdivým informacím o tom, jak daný systém konfigurovat.

Jo, prostě v žádném argumentu nevidím důvod přizpůsoboval linux třeba například windows a takto nalákat další adminy. No a pokud ano, tak se klidně můžem vrátit cca 20 let na zpět, kdy tady byl Mandrake, kde už v té době vše bylo klikací a člověk do /etc/ vůbec nemusel. (Dneska už si nevzpomenu na jméno toho nástroje, ale když jsem v roce 2006 nastoupil do první práce, tak tehdy tam linux ovládal pomocí nějakého webového nástroje napsaného v perlu a už tehdy jen klikal do webu. A udělal tam úplně všechno od sítě až po rozdělení disků. Takže pokud někdo touží po klikacím Windows adminovi, tak tohle už tady bylo.)

webového nástroje napsaného v perlu

Webmin.

S těmi adminy jsem trochu uhnuli od tématu. Já je uváděl jen jako příklad, proč se musí Linux vyvíjet a nezůstávat tam, kde byl před 20 lety, ale oni nejsou ten důvod, proč vznikají věci jako Flatpak nebo Docker. Ty vznikly kvůli vývojářům, ale tam byl ten vývoj podobný. Před 20 lety dělala software pro Linux jen linuxová komunita. Ti, pro které to byl primární platforma. Distribuční repozitáře fungovaly jako síto a motivace.

Jenže ta základna se tak rozrostla, že linuxová komunita je dnes v menšině. Dělají to často lidi, pro které je Linux jen jedna z platforem, nebo firmy, pro které je to platforma s nejmenším počtem zákazníků (když se bavíme o desktopu) a ti ti na rovinu řeknou: buď to pro nás bude tak snadné, že úsilí bude odpovídat počtu zákazníků, kteří to chtějí, nebo to vůbec dělat nebudeme. Že by na to najali zkušené linuxové vývojáře, je úplné sci-fi. Zaprvé je takových hrozně málo a zadruhé to je úplně mimo rozpočet, který jsou ochotní do toho dát. U serverového softwaru je to trochu jiné, tam si nemůžou dovolit Linux zcela ignorovat, ale zase to dělají cestou nejmenšího odporu.

Myslím, že máme i trochu jiný názor na to, co je příčina a co důsledek. Flatpak nebo Docker nejsou příčinou současného stavu, ten panoval dávno před nimi, jen ten trend postupně sílil a oni na něj odpověděly. A nikdo se linuxových distribucí neptal, jestli chtějí Docker. Oni ho prostě udělali a lidi ho začali masově používat. Linuxová komunita to mohla ignorovat, ale moc by s tím neudělala, jedině by musela zakazovat technologie, které to potřebuje, což úplně náš styl nikdy nebyl. Kdyby to ignorovala, nijak to nezastaví. Jen by se dočkala něčeho, co je extrémně populární a vyrostlo do platformy, která sice běží na Linuxu, ale jinak si vše řeší sama a nemusí se na nikoho ohlížet. Tím, že to linuxová komunita přijala, si zajistila určitý vliv na to, jak to bude vypadat.
Důvod, proč BSD taková dilemata řešit nemusí, je ten, že mimo BSD komunitu velice nikoho nezajímá, je tam, kde byl Linux před 20 lety. Můžeme se na to dívat tak, že Linux se stal obětí svého úspěchu, nebo tak, že BSD se stalo obětí svého elitářství. :)

Myslím, že máme i trochu jiný názor na to, co je příčina a co důsledek.

Myslím, že se míjíme v mnoha věcech. Pro mě podíl linuxu na trhu nic neznamená a považuji to za dost špatnou metriku. Mě je fakt jedno, jestli ten který OS má 40% nebo 0,01%.

Na boom dockeru se mělo reagovat: "vývojáři, vytvářet balíčky je snadné, vůbec nepotřebujete novou platformu" a prostě to zpropagovat tímto směrem. Protože já se v praxi setkávám s tím, že mnoho progs vůbec neví, jak lze vytvářet balíčky, nikdy se s tím nesetkali a pokud ano, tak mají dost hrůzné představy, co to vlastně je. Na tuto situaci se nemá reagovat propagací dockeru nebo flatpaku, ale má se na to reagovat stylem: "tohle máme v systému už 30 let, balíček vytvoříte jedním příkazem".

A (tohle píšu už taky několik let) pokud má někdo problém s vytvořením balíčku, tak to skoro automaticky znamená, že je ten projekt špatně vedený. A čímž dřív to ten prog zjistí, tím lépe. Mě například v jednu chvíli přestalo bavit dělat balíčky pro python, tak jsem přešel na golang. Statická binárka, linux, freebsd, windows z jednoho Makefile. Balíčkování je trivka, vůbec nemusím řešit závislosti na python modulech (které jsou nebo taky nejsou v distru) apod. Jinými slovy, nepříjemnost v balíčkování pythonu mě přinutila zamyslet se a teď mám lepší řešení po všech stránkách.

Proto říkám, že není úplně vhodné do systému dávat a ještě navíc propagovat kdejaké ulehčení, protože to potom ve výsledku znamená, že ta bude jen více nepořádku.

Ale balíčky jim nedají to, co jim dá ten kontejner, tedy společně s aplikací distribuovat i prostředí, v kterém to mají otestované, že to funguje. A to není jen o pohodlnosti vývojářů a špatně napsaných aplikacích.
Mám v týmu zkušené linuxové vývojáře, kteří ví, jak aplikace pro Linux psát a stejně s tím zápasí. I když uděláš aplikaci, která nevyžaduje konkrétní verze knihoven, tak stejně narazíš na to, že v jedné distribuci tu knihovnu buildí nebo patchují způsobem, který upstream nezamýšlel, v další zase něco odstraní (třeba z patentových důvodů), další zase kašle na opravy a má tam upstreamem dávno opravené chyby apod. U takových Boxes to řešíme každou chvili, protože s virtualizačním stackem dělají distribuce divy. A domluva není možná, protože oni pro to mají zase svoje důvody.
Flatpak je v tomto případě darem z nebes, protože v něm ta aplikace běží v prostředí, v kterém byla jeho vývojáři otestovaná, bez ohledu na to, co za podivnosti v distribuci dělají.
Jasně, mohli bychom udělat balíček s velkým staticky slinkovaným blobem, ale je to opravdu lepší než aplikace, která je do velké míry izolovaná ve Flatpaku?

Ale balíčky jim nedají to, co jim dá ten kontejner, tedy společně s aplikací distribuovat i prostředí, v kterém to mají otestované, že to funguje. A to není jen o pohodlnosti vývojářů a špatně napsaných aplikacích.

Jenže to prostředí považuju za blábol už od roku 2006. Tehdy jsem programoval v javě a dodnes všechny moje programy fungují. A už tehdy jsem nadával na to, že si kdejaký program si tahá vlastní konkrétní verzi JRE (především do Windows).

Tedy už 18 let jsem svědkem toho, že vůbec není potřeba žádné speciální prostředí, programy napsané před 18 lety fungují v dnešní javě.

Totéž v php (ano, už je to trapné, tohle píšu asi tak po sté). Jsou programy v php, které bylo obtížné nainstalovat a následně i provozovat. Ty jsem dal na blacklist. Nezajímají mě. Vedle toho existují už dávno mrtvé programy, napsané pro php 5.1.6, které fungují dodnes na php 7. Není s tím žádný problém.

Pokud si někdo vybere knihovnu, která má problémy s licencí, tak je to problém toho proga nebo týmu.

Já tohle myslím fakt vážně. Jestli si někdo v IRL háže klacky pod nohy a hledá co možná nejméně kompatibilní věci, tak ať si to užije. Já to dělám přesně naopak. A od zástupce distribuce (tebe), bych také čekal apel na to to dělat správně, dodržovat nějaké good practices, tyto průběžně upravovat, nabízet sadu co nejméně problematických knihoven a tímto celé prostředí vylepšovat.

> Vedle toho existují už dávno mrtvé programy, napsané pro php 5.1.6, které fungují dodnes na php 7. Není s tím žádný problém.

Tohle mi spíš přijde jako štěstí než důkaz kvality kódu daného vývojáře. Nebyly mezi 5.1.6 a 7 zpětně nekompatibilní změny jazyka? Jestli to pořád funguje, měl vývojář štěstí že na nic takového nenarazil, ale bez křišťálové koule to jde těžko predikovat.

Tohle mi spíš přijde jako štěstí než důkaz kvality kódu daného vývojáře. Nebyly mezi 5.1.6 a 7 zpětně nekompatibilní změny jazyka?

To já nevím, já v php napsal možná sto řádků. Já bych neřekl, že je to štěstí. S tímhle se potýkám 20 let své praxe. Vždy někdo přijde s tím, že je potřeba speciální verze doslova čehokoliv (jádra, ovladače, hw, knihovny, překladače, prohlížeče), zatímco hned vedle toho existují projekty, které nemají vůbec žádný problém a jsou starší než linux samotný (což se teda netýká Gallery 2).

https://www.php.net/manual/en/migration70.incompatible.php

Existuje spousta vlastností a funkcí jazyka, které byly v 5.1.7 v pohodě, a v 7.0 skončí pádem aplikace. Některé z nich byly deprecated v pozdějších verzích 5.x, ale ne v době 5.1.x

Co jsem si je prošla, nejspíš nebude problém narazit na aplikaci vyvinutou pro 5.1 která nebude mít problém v 7.0, ale rozhodně se nedá ten zbytek hodit jen na vývojáře.

Pokusy o to to vylepšovat probíhaly více než 20 let a situace si nijak nezlepšovala. Kdyby byla po těch 20 letech situace nadmíru výtečná, tak vývojáři tak masově neskočí po kontejnerech. A opravdu to není jen o lenosti a neschopnosti psát dobrý kód.
Je prostě realitou, že člověk nepíše proti jedné knihovně, ale proti X jejím variantám, které jsou v různých verzích, a i ve stejných verzích se v různých distribucích můžou chovat různě. Rady, že si má vybrat tu správnou knihovnu, jsou opravdu knížecí, protože v některých oblastech prostě na výběr není (viz. ta virtualizace).
Efektivně to vede k tomu, že si vývojáři musí omezovat výběr funkcí na ty opravdu neproblematické všude a případně reimplementovat, či forknout a skrytě bundlovat ty problematické. A situace je ve výsledku ještě horší, protože je to nepřiznané. Člověk používá aplikaci, která má nádherně dynamické linkování na své závislosti, ale ve skutečnosti má celou vlastní implementaci krypta, kdysi forknutou z nějaké knihovny. A že jsem takových případů viděl...

Jo jo :(
https://xkcd.com/2347/

Jako vývojář s povahou, že se snaží udržet zpětnou a dopřednou kompatabilitu, tak čím větší rozptyl verzí, tím to je těžší a těžší.

Když budu psát v PHP7, tak to vyžaduje určitou pečlivost, a otestování aby to na 8čce neházelo noticky.

Psát v PHP8 aby to běželo i na PHP5 je zase sebemrskačství. Ten jazyk používá nové konstrukce které prostě chceš používat.

> Ale balíčky jim nedají to, co jim dá ten kontejner, tedy společně s aplikací distribuovat i prostředí, v kterém to mají otestované, že to funguje.

Navíc i ten kontejner jde napsat i dost minimalisticky, pokud tu technologii člověk použije správně. Můj výstup konterjnerů builděných z nix packages je v podstatě jen serverová aplikace samotná (A občas busybox, pokud do kontejneru chci občas vlézt s shellem). Mohla bych to instalovat i jako normální balík a občas to dělám, ale kontejnery mají výhody větší než jen „bundlované prostředí“. Navíc díky podmanu a systemd integraci už není potřeba řešit moloch Docker.

>Statická binárka, linux, freebsd, windows z jednoho Makefile.

Jedna z největších kritik Flatpaku co vídám je „bundluje to celé prostředí, takže je to nebezpečné, protože nejde updatovat závislosti bez upgrade aplikace“. Osobně s tím nesouhlasím a ty zjevně taky ne, jinak nepoužíváš Golang, ale je v tu chvíli opravdu velký rozdíl mezi tím distribuovat kompletně staticky slinkovanou binárku a flatpakem?

Flatpak mi dá tohle všechno a navíc aplikační sandbox, mám velkou šanci že pokud je aplikace napsaná správně a používá XDG portály, nemůže vést chyba v aplikaci k přístupu mimo sandbox.

Osobně s tím nesouhlasím a ty zjevně taky ne, jinak nepoužíváš Golang, ale je v tu chvíli opravdu velký rozdíl mezi tím distribuovat kompletně staticky slinkovanou binárku a flatpakem?

Já jsem měl a stále mám se statickými binárkami problém. U golangu pro mě převážily jiné výhody a také zatím velmi snadná rekompilace na všechny OS. Navíc já celkem zásadně používám pouze standardní knihovnu + connector do postgresu, takže těch případných bezpečnostních chyb tam není tolik.

Ale obecně, za mě jsou sdílené knihovny skvělý vynález a základ. A myslím si, že za těch 50 let jako lidstvo známe způsob jak je psát a používat. To, že se to v nějakém prostředí neděje vnímám jako problém toho prostředí. (Ale celkově je to samozřejmě složitější.)

Zažil jsem přechod středně velké aplikace z PyQt3 na PyQt4, pak PyQt5 a pak PyQt6. Vím dvě věci - (Py)Qt ty migrace měla docela dobře podchycené a ty změny v API většinou rozumně náročné. A nebylo to C. Tipnul bych si, že Gtk+ a C je dost větší oříšek a každá z těch věcí tam přidává svoji část problému.

Qt má určitě podstatně větší zdroje na vývoj a a údržbu a tudíž i na držení zpětné kompatibility, takže v tomto ohledu na tom bude líp. Mezi GTK 2 a GTK 3 bylo prakticky 10 let a musel se tam udělat velký řez. Od verze 4 už se počítá s menšími inkrementálními změnami a vydáním co cca 3 roky.
Ono dost záleží na tom, jak je i ta samotná aplikace napsaná a udržovaná. Mezi GTK 2.0 a poslední verzí GTK 2 před vydáním GTK 3 byl taky docela velký rozdíl. Postupně se to modernizovalo, starší věci se označovaly za deprecated... když aplikace ten vývoj sledovala, nebyl přechod na GTK 3 takový problém. Když zamrzla někde v raných dobách GTK 2, bylo to mnohem více práce. To si myslím, že je problém i GIMPu.

Když zamrzla někde v raných dobách GTK 2, bylo to mnohem více práce. To si myslím, že je problém i GIMPu.

No vida, a jsem u toho...

No a pokud se vrátíme na začátek, jak toto vyřeší kontejner? Nijak, jen to zakryje. Ale to shnilé zůstane shnilé pořád.

Mimochodem, používaní kontejnerů má svůj smysl - pro rozdělení ekosystému aplikace na samostatné části a jejich izolace, tam, kde to má smysl. U serverových aplikací asi nikdo příčetný nebude rozporovat výhody. Ale i tam se to musí dělat pořádně a s rozmyslem.

A kde jsem psal, že zrovna toto má řešit kontejner? :)

Kontejner je dobrý od toho, když mám aplikaci otestovanou proti GTK 4.2 a v distribucích se začne objevovat 4.3, která sice drží zpětnou kompatibilitu, ale nemusí se chovat 100% stejně a kontejner mi umožní používat 4.2, dokud si nenajdu čas a neodladím a neotestuju to s 4.3. Nebo když aplikaci potřebuju dostat i k uživatelům, kteří jedou na nějakém hodně konzervativním distru, které má pořád GTK 4.0, ale moje aplikace používá vlastnosti, které se tam dostaly s 4.1 a 4.2, a zároveň nechci, aby uživatelé trpěli chybami, které se od verze 4.0 opravily.

Kontejner ale za aplikaci opravdu nevyřeší, že roky nesleduje vývoj grafického frameworku a pak má problémy přejít na novou verzi. Může maximálně pomoct v tom, že takovou aplikaci můžu šoupnout do izolovanějšího prostředí a nemít kvůli ní komponenty, které nejsou upstreamem dávno podporované, přímo v systému.

Zrovna v tomto případě, nebylo by jednodužší a přímočařejší řešení:
libGTK-4.0.so
libGTK-4.1.so
libGTK-4.2.so
?

pokud by slo o balicek se shel scriptem tak ano, ale jakmile jde o binarni obsah kterej ma zavislosti na dalsich binarnich baliccich ktere se mezitim (s povysenim verze distribuce) aktualizujou, tak jaksi proste pises z neznalosti pekne kraviny ;-)

takze znovu si precti co sem psal, vyber si nejakou moznost a zkus si to sam...