Vlákno názorů k článku
Unsnap převede snap na flatpak od dw - Prevod z 8 na 10 bez 2... Tiez vam...

"Dost zavysle na distre, pravdepodobnost aktualizacie v distre je omnoho vyssia ako pravdepodobnost aktualizacie vo snape/flatpaku.

Snap, Flatpak, i ten AppImage jsou generovány v pipelině jednotlivých projektů, takže nová verze, včetně nových závislostí, se objeví při každém novém releasu. U některých projektů to je třeba i jednou za týden. Takový Debian dokáže mít nepříjemné bugy v balíčcích po celou dobu své životnosti. Přitom jde o chyby, které byly opraveny třeba ještě před tím, než daná verze Debianu vůbec vyšla, ale z upstreamu se tam ta změna nikdy nedostane.

" Dost zavysle na distre, pravdepodobnost aktualizacie v distre je omnoho vyssia ako pravdepodobnost aktualizacie vo snape/flatpaku."

Povedz to projektu EasyEffects, ktorý je v Ubuntu 20.04. starý vo verzii 4.7.1, zatiaľ čo vo Flatpaku je už verzia 6.2.4 (2 major verze popredu, počas ktorých sa prešlo z GTK3 na GTK4 a z PulseAudio na PipeWire)... takže asi toľko o aktualizáciách...

Node.js, ešte pred rokom aj pol bolo podľa ofiko návodu inštalácie na Ubuntu (.deb) to inštalovalo verziu 8, zatiaľ čo SNAP už bolo verzia 14.

Aktuálne mám pocit že práve SNAP a Flatpak sú aktuálnejšie než .deb / apt či .rpm

btw. tie príklady na Ubuntu sú skúsenosti, a podobné skúsenosti mám aj vo Fedore, taktiež tam boli staršie balíky než vo Flatpaku.

10. 4. 2022, 19:58 editováno autorem komentáře

Samotné aplikace budou na Flathubu určitě aktuálnější než v distribucích. Nakonec to je i jeden z cílů: dostat aplikace přímo od autorů k uživatelům co nejrychleji. Třeba Evolution na Flathubu většinou vydám ten samý den nebo nejpozději druhý potom, co to vydáme v upstreamu. Tomu nemůže žádná distribuce konkurovat.

Myslím si, že co se týče aktuálnosti, mají lidi obavy ze závislostí. Tam by to stálo za nějakou hlubší analýzu a srovnání. Nejen z pohledu novější verze, ale i z pohledu toho, jestli jsou ty starší verze záplatované. Starší verze nemusí nutně být špatná věc, ale pokud není záplatovaná, špatně to je. Já na Flathubu spravuju dvě aplikace a zrovna Evolution není úplně triviální (16 modulů a manifest má přes 500 řádků) a přesto mám až na jednu knihovnu, kde musím zůstávat u staré verze kvůli regresi v novějších, všechno aktuální a závislosti aktualizuju maximálně v řádu týdnů. Dneska už na Flathubu existuje nástroj, který se to snaží automatizovat, hlídá nové verze závislostí, automaticky vytváří pull requesty s aktualizovaným manifestem. Je tam rozhodně snaha to systémově řešit, i když zodpovědnost je nakonec na samotném správci aplikace. Ostatně stejně jako v distribuci.

Pak jsou tam sdílené runtimy. Tam si myslím, že je úroveň podpory srovnatelná s distribucemi. FreeDesktop runtime, který slouží jako základ pro ostatní, je AFAIK udržovaný placenými lidmi. Celkově nejsou ty runtimy tak rozsáhlé, aby to nešlo rozumně udržovat. Když se runtime, který aplikace používá, blíží konci podpory, správce dostane echo, že by měl přejít na novější.

Ona samozřejmě jedna systémová knihovna, kterou všichni dynamicky linkují, univerzální pravidla pro kvalitu softwaru v distribuci atd. zní v teorii hrozně pěkně, ale v praxi to bohužel tak dobře nefunguje. Pravidla se v praxi nedodržují. Čím obsáhlejší repozitáře jsou a čím starší distribuce je, tím je to horší, protože to je těžší. Repozitář Universe v Ubuntu je extrémní příklad, ale máslo na hlavě má ve větší či menší míře každá distribuce. Takže dávat to za vzor nějakého dokonalého modelu moc nejde.
No a pak je tu ta věc, že jedna verze nevyhovuje všem a čím je starší, tím víc to platí. A lidi to začali obcházet nejrůznějšími PPA. Uživatel se může rozhodnout, jestli bude používat starý a často nezáplatovaný balíček v distribuci, nebo si nainstaluje balíček od třetí strany, kde není vůbec žádná kontrola a na rozdíl od Flatpaku mu dává práva roota (při instalaci) a přístup do celého systému.
Je dobré ty nové formáty jako Flatpak posuzovat ne podle toho, jak ten tradiční distribuční model by měl ideálně fungovat, ale jak ve skutečnosti funguje. Pak bude zřetelnější, proč vznikají.

Flatpak má jednu a to zcela zásadní a neakceptovatelnou botu. Když jsem si nainstaloval z Flatpaku nový Gimp, přebouchal mi všechny možné Mimetypy tak, že se mi otevíraly v Gimpu. Jenže takovým způsobem, že Flatpak předřadil svoje adresáře násilně před systémové a tudíž jsem musel hodinu hledat, co se stalo. Tohle snad přece nemůže být legitimní přístup. Gimp šel ven a celý Flatpak za ním.

Toto jsem u sebe nikdy nepozoroval. Už před pěti lety se udělala změna, aby exportované mime types měly nejnižší prioritu a bylo tak prakticky nemožné, aby přepsaly ty již existující.
Je možné, že někde se takové problémy dějí, ale spíš než na chybu samotného Flatpaku bych to viděl na chybu na straně integrace Flatpaku do distribuce.

Nenam link, mam vlastni zkusenost. Predstav si, ze mas projekt a udrzujes .deb balik pro vetsinu debian-based dister.
Najdes funkcni chybu v knihovne a ve funkci, kterou pouzivas. Opravis ji, posles patch. Nez se ale ten patch objevi ve vsech distrech, musis resit co s tim. Ani jedna varianta NENI dobra.
V hrubych rysech:
0/ funkcni nepouzijes :-P, nebo pouzijes workaround s detekci verze knihovny
==> ne vzdy to jde, nekdy je funkce uz pouzita nebo ji nejde odebrat

1/ pouzijes upraveny fork knihovny a staticky nalinkujes. Za nejaky ten mesic, rok sledovani se oprava dostane do vsech dister a muzes fork zrusit a pouzit opet distro verzi
2/ pri buildu zbuildis i tu knihovnu z GITu, ale s tvym patchem, snad ti patch nerozbiji vyvojem, pripadne buildis proti git verzi s tvou opravou
==> Ve vsech pripadech obchazis distro baliky, alespon docasne

3/ Krome svyho baliku zacnes udrzovat distro baliky knihoven, ktery pouzivas tak, aby tam byly opravy vcas
4/ na knihovny se vybodnes a pouzivas vse vlastni
===> Pokud nejste zaopatren jinak, tak na to neni cas

Snap/Flatpak neni vselek, ale pomuze aleposn s tim nedelat vse x-krat trochu jinak pro kazdy podporovany system. Snap/flap se buildi stejne pro vsechny podporovany platformy. Usetreny cas se muze venovat bezpecnosti a napr. tvorbe confined snapu, apparmor atd, protoze prostredi je nezavisly od systemu.
.Deb se buildi stokrat jinak, stokrat vic prace a prostoru pro chyby.

Samozrejme, vsechno ma svou cenu. Ta cena na strane vyvojare je temer nulova. Yaml se jednou napise a v podstate do nej nezasahujes, pokud se nemeni zavislosti, atd.
Cena na strane uzivatele je delsi load, tu jsem ale ochotny zaplatit (humor).
Asi by se melo prihlednout k tomu, ze bez snap/flap/appimage by treba ten projekt dostupny pro danou platformu vubec nebyl...