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 vogo - Občas provozuji nějaký ten AppImage a dle mě...

Občas provozuji nějaký ten AppImage a dle mě je to nejlepší řešení, mám dojem že i velký Linus se někde vyjádřil, že AppImage je šikovné řešení, narozdíl od Flatpaku a Snapu.

Jinak mám vše v nativních balíčcích. Na začátku popisované „podivné“ závislosti mě vskutku pobavily, to je prostě problém distribuce, I use Arch BTW. K Flatpaku a Snapu mám zkrátka nějaký vnitřní odpor, jednou jsem z důvodu lenosti zkusil nainstalovat betaverzi Siril z Flatpaku. Potom co jsem ho odinstaloval i s celou tou vopičárnou okolo, jsem si napsal PKGBUILD.

Problém AppImage je v tom, že dovoluje libovolně linkovat na knihovny v systému. To zní jako super nápad, že? To nejlepší z obou světů. Co mi stačí ze systému, to použiju, co potřebuju jiné, to zabalím k aplikaci. Bohužel to vede k tomu, že vývojář udělá AppImage, který funguje u něj (typicky na nějakém Ubuntu), ale už ne na ostatních distribucích, protože ta knihovna, u které mu to v Ubuntu fungovalo i se systémovou verzí a proto se jí rozhodl použít, je v ostatních distribucích v nekompatibilní verzi.

Samozřejmě jde udělat AppImage, který bude spolehlivě fungovat všude, ale chce to dost zkušeností a opatrnosti. AppImagů, které byly na mém systému rozbité, jsem zažil v množství "větším než obrovském". Ten formát bohužel selhává v té nejpodstatnější úloze: zajistit, aby jedna instalačka fungovala všude.

Tohle nerozporuji, ale netvrdil bych, že je to bug, je to spíše vrozený rys AppImage. Pořád je to něco za něco, relativní jednoduchost vyžaduje více práce toho, kdo AppImage vytváří.

Osobně jsem narazil na na chybějící knihovnu u AppImage Prusasliceru, kdy mi chyběl gtkwebkit, který byl linkovaný, ale nebyl součástí obrazu. Důvodem bylo, že by pak AppImage byl asi o 200 MB větší, kdyby měl táhnout všechny závislosti. To že z Flatkapu mám tyhle závislosti nainstalované je sice pěkný, ale takového místa co mi to sežere, nedejbože ve více verzích...

Nejlepší je nativní balíček to mi nikdo nerozmluví. AppImage je šikovný, Flatpak a Snap podle mě zavádí systém v systému a to se mi prostě nelíbí.

1. 8. 2025, 09:11 editováno autorem komentáře

Jenže když chcete vytvořit něco, co bude spolehlivě fungovat napříč všemi distribucemi a jejich verzemi, tak vám nezbude nic jiného než vytvořit systém v systému. Ten společný jmenoval je hrozně malý. Běžný uživatel očekává, že po instalaci mu bude aplikace fungovat, ne, že bude řešit, jak a v jaké verzi doinstalovat webkitgtk.

Další věcí je pak samotná distribuce. Autor AppImage se nechal slyšet, že pro něj je vrchol distribuce aplikací doba Windows XP, kdy si lidi stahovali instalačky z webových stránek. Existuje sice AppImageHub, ale nevím, nakolik je to dělané s ním ve spolupráci a nakolik mu natruc, každopádně to je velká znouzecnost.

Na distribuci softwaru v Linuxu jsem vždycky považoval za jednoznačně lepší to, že uživatelé instalují software z jednoho, maximálně několika prověřených zdrojů. Opravdu bych se nechtěl dožít toho, aby se normou stalo to, že máti řeknu: "Vyhledej si ve vyhledávači GIMP, klikni na jeho stránky a stáhni si instalačku". Zvlášť v dnešní době, kdy je relativně jednoduché udělat phishingovou stránku gimp-app.org, která se v Googlu při vyhledávání GIMPu umístí nad gimp.org.

Chápu, že pro někoho, kdo se chce držet distribučních balíčků a jen občas udělat výjimku a kdo ví co dělá, to je jednoduché a lákavé, ale já tedy doufám, že se to jako formát pro distribuci aplikací v Linuxu příliš neprosadí, protože to je opravdu návrat do časů Win XP. A vývojáři dnes balíčky pro distribuce dělat nechtějí a je jim jedno, jestli tam jejich aplikace je nebo ne, takže z toho, co fungovalo na občasné výjimky, by se taky mohl stát majoritní způsob distribuce aplikací na Linuxu a v podobě, v jaké to je teď, by to opravdu bylo "velký špatný".

Na distribuci softwaru v Linuxu jsem vždycky považoval za jednoznačně lepší to, že uživatelé instalují software z jednoho, maximálně několika prověřených zdrojů. Opravdu bych se nechtěl dožít toho, aby se normou stalo to, že máti řeknu: "Vyhledej si ve vyhledávači GIMP, klikni na jeho stránky a stáhni si instalačku".

Přesně tak. Jinak problém s používáním dalšími zdrojů softwaru může klidně nastat i při použití nativního balíčkovacího systému a slepému přidávání repozitářů.

Typický scénář, kdy mě kontaktuje uživatel, že mu špatně fungují aktualizace v "tom" Linuxu a vypisuje to "nějaký" errory.
Po vzdáleném připojení do systému pak vidím jen nějaké neřešitelné závislosti nebo mrtvé vzdálené repozitáře.
- A jak se ti to tam dostalo?
- Ale potřeboval jsem XYZ, a tohle byl druhý blogpost, co mi našel Google. Tak jsem jen kopíroval řádky a spouštěl :)

Nebo je to může být i takové to klasické.
curl -sL https://blablbabla.github.io/thegreatapp/install.sh | sudo sh

Takže v porovnání s tím mi přijdou důveryhodné zdroje a Flatpak s těmi izolačními mechanismy jako velký posun.

A co izolacia? Ten GIMP nepustim na siet a na zapis dam mu iba jeden adresar napr '~/Picture/GIMP' a balickovac mu este prideli nejaky '~/.local/sha­re/gimp' pre zdielanie konfiguracie.
Potom sa radikalne zvacsi mnozstvo miest odkial mozem balik instalovat. System podobny ako ma Android. Izolacia aplikacii, nie ze kazda aplikaci vidi vsetko a moze si robit co chce. Viem ze sa to da nastavit ale skuste odizoval Chrome, to sa ani neda.

Podporovať 100 - 1 disturbácií je fuc7 ťažko riešiteľný problém.

- 1 ako Clear Linux

Pro uživatele rolling distribucí s bohatšími repozitáři Flatpak takový benefit nemá, možná mimo komerčních aplikací (typově Spotify, různé ElectronJS klienti atp.).
Nicméně pokud jedete na klasicky verzovaných distribucích, co mají třeba dvou, tříletý cyklus plus nějakou extended podporu, tak je to podle mě rozumný způsob jak mít v systému aktuální verze mnoha aplikací, které navíc často vydává a testuje přímo jejich autor.
AppImage je za mě zajímavý možná pro portable aplikace, co chcete spouštět bez dalších runtime, jinak ne. Nemá to, logicky, žádnou přímou integraci do systému, aktualizace (bez dalších služeb), žádné sdílení atp.

Jinak mi přijde, že to někteří lidé vnímají strašně fundamentalisticky. Takhle to má být, to je ta jediná správná "Linuxová" cesta. Naopak s troufám tvrdit, že většina uživatelů vnímá spíš benefit toho, že má dostupné aktuální verze aplikací, které může používat.
U pár lidí okolo mě to třeba byl jeden z důležitých aspektů vedoucích k tomu, že s Linuxem můžou pracovat většinu času jako s primárním desktopovým prostředím.

Pro vývojáře desktop aplikací, speciálně pokud jsou to jednotlivci nebo malé týmy, co dělají multiplatformní desktop aplikace, je tohle konečně způsob, jak přímo do pipeline dát jedno oficiální, univerzálně použitelné sestavení pro Linux, které můžou testovat, řešit vůči němu bugy bez toho, aby odhadovali, co s tím provede další balíčkář, vůči kterým knihovnám to sestaví atd.
Ano má to i své nevýhody (např. více zabraného místa, pro někoho to může být i bezpečnost v případě staších knihoven, ale to je obecný aspekt všech "kontejnerových" řešení). Nicméně i s nimi to může pro spousty lidí pořád být velmi rozumný způsob, jak přidávat aplikace, co nejsou v distribučních repozitářích, pokud zkombinují nativní balíčkovací systém a právě Flatpak.

Asi tak. Tyhle sandboxované balíky především strašně moc zjednodušily provozování LTS dister na desktopu, kdy si člověk jádro systému a důležité věci v userspacu může držet na stabilních verzích (takže neriskuje, že si updatem rozdrbe systém, případně v updatu bude nějaká výkonová regrese), ale desktop appky má aktuální a nehnijou mu tam na prastarých verzích.

Pamatuju si na doby, kdy jsem jel Debian 5 na ThinkPadu T30 a třeba dostat tam relativně aktuální LibreOffice byl strašnej porod. Dneska s Flatpakem nemám problém mít na notebooku LTS distro s aktuálníma appkama a vlastně vůbec nic řešit nemusím.

<trolling>
A proto je pořád nejlepší si stáhnout wokenní verzi a spustit ve Winu :-D Třeba u TNT simulátoru jsem to tak udělal, protože poslední Linuxová verze vyšla asi před 15 lety.
</trolling>

Jo a dopadne to jako Steam, pro každou gamesu wine (protonovej) kontejner, a po nějaké době to člověk celé radši stejně strčí na btrfs s deduplikací.