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 RRŠ - Linuxovými desktopy, které spravuji, jsou obvykle starší stroje...

Linuxovými desktopy, které spravuji, jsou obvykle starší stroje ve službách nenáročných uživatelů (dědečkové a babičky či školáci a jejich rodičové). Typický use case je starší notebook s několika základními aplikacemi k prohlížení internetu, přehrávání multimédií a nějaké komunikaci (e-mail, Signal...). Obvykle jsou na stroji dva aktivní uživatelské profily (dědeček+babička, sourozenci, rodiče+děti).
Větší administrátorské zásahy se konají několikrát do roka, u kafe, menší po telefonu nebo SSH.
Tyhle stroje uživatel ani administrátor nechce moc vylepšovat - a balíčkovací systém se elegantně postará o updaty, bezpečnostní záplaty systému i aplikací, případně mírný upgrade. Když se něco pokazí - zajdu na kafe.

Na několika strojích je i pár programů v kontejnerech (většinou snap, nějaký flatpack a jedna aplikace jako appimage). Zatímco o balíčcích v podstatě nevím, ty kontejnerové se co chvíli s něčím připomenou, nejčastěji se snahou o aktualizaci pod účtem, který na to nemá práva. (Ta appimageová sama detekuje update, stáhne si image pod uživatelský profil - a zhavaruje při pokusu o update. Po příštím spuštění nebo další den se to opakuje, a v adresáři se staženými soubory se dostává k e stovce stejných souborů... Ale uznávám, že tady je to především chyba pachatele aplikace.)
Snap, FlatPack, AppImage - to má smysl nejspíš zejména na jednouživatelských strojích, a spíš na těch, které si uživatel spravuje sám. Dokážu si to představi i ve firemním, centralisované řízeném prostředí, ale jakmile se na počítači střídá několik uživatelů, bude se to akorát plést pod ruce... (Zatím.)

V tomto je ešte horší homebrew na macOS - ten je doslova vytvorený s predpokladom, že ho bude používať 1 užívateľ

Neházel bych ty všechny zmíněné technologie do jednoho pytle a vyvozoval z toho obecné závěry.

AppImage je opravdu specifická věc. Jak už jsem tu psal, je to vhodné pro portable aplikace, protože se to dá spustit odkudkoliv bez dalších programů v systému - to je hlavní cíl a benefit ("Linux apps that run anywhere").
Nicméně to neřeší problémy, co můžou nastat při případném linkování na konkrétní verze systémových knihoven. Zároveň je to pouze standard pro formát, vytváření a sestavování těch obrazů. Nemá to žádnou formu sandboxování.
Není žádný standardní (oficiální) mechanismus, jak je automaticky aktualizovat, spravovat, integrovat do systému atp. - je to mimo rámec toho projektu na portable aplikace. Jsou možná nějaké horší či lepší utilitky třetích stran, co se o tohle snaží a například extrahují metadata, vytváří XDG desktop soubory (aka zástupce). Může tam být interní aktualizační mechanismus v zabaleném softwaru, co ale logicky nezafunguje, když je image na místě, kam uživatel nemůže zapisovat atp.

Použil bych to pouze pokud není žádná jiná alternativa (Flatpak, Snap, dist. balíček).
Kdyby to mělo popisovaný problém, řešil bych ty aktualizace sám pomocí nějakého skriptu (který má právo na zápis), anebo v případě jediné aplikace bych se tím vůbec nezabýval a normálně to rozkopíroval do všech profilů (~/.local/bin/), ať se to každému uživateli aktualizuje samo pomocí interního mechanismu.

Flatpak oproti AppImage řeší spousty dalších věcí, dá se říct, že to nejen formát a nástroje k sestavení, ale i komplet balíčkovací systém včetně uživatelských nástrojů, sandboxuje, drží se XDG standardů atp. Je tam jistá forma deduplikace pomocí linků. Sdílené runtime balíky šetří jak místo, tak velikosti stahování. atd.
Stran toho delegování administračních úkonů, např. aby běžný uživatel mohl aktualizovat také systémové flatpaky, tak dá vše systémově řešit pomocí PolicyKitu.
Jsou tam registrované všechny potřebné akce, takže stačí např. použít systémovou skupinu users, kde budou všichni uživatelé a napsat jednoduché pravidlo, co ty akce povolí.
Nebo založit novou (např. flatpak-adm), upravit pravidlo a přidat do konkrétní uživatele.

msmucr@msmucr-desktop:~> pkaction | grep -i flatpak
org.freedesktop.Flatpak.app-install
org.freedesktop.Flatpak.app-uninstall
org.freedesktop.Flatpak.app-update
org.freedesktop.Flatpak.appstream-update
org.freedesktop.Flatpak.configure
org.freedesktop.Flatpak.configure-remote
org.freedesktop.Flatpak.install-bundle
..
org.freedesktop.Flatpak.runtime-install
org.freedesktop.Flatpak.runtime-uninstall
org.freedesktop.Flatpak.runtime-update
org.freedesktop.Flatpak.update-remote

Snap řeší hodně podobných věcí jako Flatpak. Byť jsou tam samozřejmě funkční rozdíly.. a každý z obou může mít určité výhody proti tomu druhému.
Osobně mi přijde citelně pomalejší než Flatpak, a to jak na spouštění (komprimované image, inicializace služby po startu), tak i aktualizace (differenciální přenos - delty vyžadují jejich výpočet na klientu).
Navíc je to tak divně mezi - v Ubuntu se to používá jak na desktop aplikace, tak poslední dobou na některé systémové služby. Což mi přijde zbytečné.. specificky v situaci, kdy je jsou na služby zaběhnuté Dockery a OCI kontejnery s bambilionem nástrojů okolo. Podobně to má tvrdou vazbu na jediný repozitář (Snapcraft od Canonoicalu).
Za mě by bylo optimální, kdyby se s tím ještě chvíli vyblbli a pak se to přirozeně odložilo (podobně jako Mir, Upstart) :), aby se zbytečně nefragmentovaly používané formáty pro tyhle desktop kontejnery a zůstal opravdu jeden majoritní.
Koneckonců i na Ubuntu instalacích obvykle Snap deaktivuji a používám tam Flatpak.

Ta AppImage aplikace je opravdu jediná - a že se bude takhle nemravně chovat mne nenapadlo, dokud jsem neviděl, co napáchala. ;-) Vzhledem k tempu aktualisací to není problém, pokud nastane nutnost, lze to přes SSH srovnat do latě.
Snapu v Ubuntu jsou jak rakovina. Nic proti, ale - jak píšete - když to začalo metastázovat mezi systémové utility, stalo se to nanejvýš protivným.
FlatPacky nejsou špatné, osobně mi připadnou jako rozumná alternativa, ale přijde mi, že tak nějak předpokládají, že uživatelem je administrátor. Viz právě to přidělování práv. (IMHO se o tyhle věci uživatel starat nemá, natož abych mu musel delegovat práva.) Na jednouživatelském stroji bych jim asi dal šanci.

Celkově to opravdu na mne dělá dojem, že se tu (někdo) snaží řešit problém jak udělat nejlepší instalace na počítači pro jednoho uživatele, protože se pohybuje ve sociální bublině, kde pravidlo 1 počítač = 1 uživatel platí, kde jsou počítače opravdu osobní, stejně, jako mobily a tablety.
Proto ta snaha přiblížit instalace tomu, jak je to na mobilních platformách.
Jenže mezi prostým lidem tomu tak není - a PC/notebooků v rodinách spíš ubývá, přičemž zůstávají sdíleným prostředkem, pro situace, na které mobily či tablety nestačí nebo se nehodí.

FlatPacky nejsou špatné, osobně mi připadnou jako rozumná alternativa, ale přijde mi, že tak nějak předpokládají, že uživatelem je administrátor. Viz právě to přidělování práv. (IMHO se o tyhle věci uživatel starat nemá, natož abych mu musel delegovat práva.) Na jednouživatelském stroji bych jim asi dal šanci.

Takhle mi to nepřijde. Od začátku to právě počítá s více možnostmi používání a je to, podle mě, docela vymakané.

Můžete je instalovat jen pro všechny uživatele, a nedovolit normálnímu uživateli přidávat ani aktualizovat žádné aplikace. To je většinou i výchozí nastavení, třeba balíček flatpak na Suse, má polkit pravidla tak, že to povoluje jen uživatelům ve skupině wheel, ale můžete to dalšími pravidly upravit úplně dle libosti. Na Ubuntu je to zas skupina sudo.
Tohle je myslím asi to, co většina lidí očekává. Software spravují jen administrátoři, ale pokud je tam jen jediný přidaný účet v systému, má většinou také administrátorská práva.
Zároveň je na Suse připravený, ale neaktivní systemd timer, co spouští globálně: /usr/bin/flatpak --system update -y --noninteractive
Stačí ho zapnout a naplánovat podle potřeby.

Pokud pak chcete kombinaci, tzn. aby uživatelé měli k dispozici systémové (sdílené) aplikace, do kterých nemůžou sahat, ale zároveň si mohl nainstalovat něco jen pro sebe, tak to jde taky.
Jestliže uživatel používá příkaz flatpak z terminálu, mělo by stačit v shellu udělat alias, na flatpak, aby se to používalo s direktivou --user na konci. První pak přidat uživatelský repozitář na flathub přes flatpak remote-add. A pak už to normálně jede a všechno, co udělá, bude pouze u něj v profilu.
Samozřejmě pokud tam bude závislost na nějakém runtime, který už bude jednou nainstalovaný pro všechny, tak se nestahuje.
V případě, že pak používá např. GNOME software s pluginem pro flatpak, jde to taky, když se v u něj nastaví:
gsettings set org.gnome.software install-bundles-system-wide false (výchozí hodnota je true a chce to přihlášení, viz. to co jsem zmiňoval).
Všechny tyhle kroky se dají udělat samozřejmě udělat automaticky, když se vytváří nový profil nebo po nějaké jeho inicializaci.

Jo, něco takovýho jako /usr/bin/flatpak --system update -y --noninteractive jsem tam musel přidat do updatovacího scriptu. (Ono je to už pár měsíců, co jsem to potřeboval naposledy...)
Ale právě to, že na to člověk musí pamatovat, že se to neřeší v rámci běžného update-update, mi na tom vadilo.
(A taky to prvotní ladění souběhu apt + snapu + flatpacku v Ubuntu: doteď si nejsem jistý, že to mám úplně správně a že se něco samo nerozbije v budoucnosti po nějakém updatu.)

Já jsem právě pro tento use čase balíčky opustil. Zjistil jsem totiž, že uživatelé je neaktualizují. Došel jsem k nim po půl roce a měli třeba půl roku starý Firefox. Prostě i když stačí kliknout na notifikaci a potom na tlačítko Instalovat, nedělají to. A nemám koule jim to dělat na pozadí. V datech o pádech vidíme, že přepisování souborů za běhu programy pořád nemají rady a padají. U Flatpaku to problém není, protože nové soubory se načtou až po dalším spuštění programu, takže tam nemám obavu to dělat na pozadí automaticky.
Dalším důvodem je, že neměnný systém je prostě praktičtější, když se něco rozbije. Nestává se to často, ale občas prostě ano. A pak vysvětlujte po telefonu máti, která je 120 km daleko, jak si má downgradovat mesu, protože zrovna u jejího modelu GPU došlo k regresi. Takto jí řeknu, ať po startu počítače vybere druhou položku, čímž nabootuje do předchozího snapshotu, a používá ho, dokud se to neopraví. Vím, že dnes existuje díky Btrfs snapshotování i u balíčků, ale pořád to není tak přímočaré a univerzální jako ostree/bootc.

Já tu drzost nechat aktualizace na pozadí mám - byť uznávám, že je to částečně z mé nezkušenosti a z toho plynoucí nedostatečné opatrnosti. ;-D

Dědečka a babičky jsem naučil: Klikni na připojení k VPN, a počkej na telefonu. Zbytek přes SSH...
Občas je efektivnější povídat si se systémem, než s uživatelem.

U těch regresí v hardwarové podpoře je občas problém ten, že to ani do plného systému nenabootuje. A to je pak ještě těžší BFU vysvětlovat, jak nabootovat, připojit se k síti a VPN v nějakém failsafe módu.

A pak nastává čas na návštěvu na kafe... ;-D

(Nicméně variantu při startu honem vyber druhou volbu - předchozí verse - a pak se připoj... stařečkové už zvládli. Jen nesmím zapomenout jim na konci připomenout, že se mají zase vrátit na první řádek, jinak zůstanou na té předchozí versi věčně.)