Vývojář Alan Pope, který dříve pracoval pro Canonical a byl zastáncem snapu, vydal nástroj unsnap, který rychle převede balíčky snap na flatpak. Vlastní skript v bashi pracuje ve dvou krocích. V prvním vygeneruje převáděcí skript, který si může uživatel prohlédnout, než jej v druhém kroku spustí.
Unsnap je zatím v rané fázi vývoje. Alan říká, že je to pre-alfa, která jakýmsi způsobem funguje u něj na počítači.
(zdroj: gamingonlinux)
Tak tomu říkám vyhánět čerta ďáblem :)
Jakožto balič debianích balíčků často hořekuji na peklem závislostí. Například když chci zabalit něco v golangu a chci to udělat správně tak je balení závislostí závislostí činnost nemilá ale ta práce se v důsledku vyplatí.
Mám pak pocit že mám nad distribucí lepší kontrolu.
Protože jak jednou někdo začne s flatpakem, tak taky může skončit u Alpine ;)
Ač souhlasím s tou kontrolou na straně uživatele, není to tak černobílé.
SW je dnes vydáván poměrně často. Balíčky debianu nestíhají (např. Firefox, i když zrovna 99.0 se do Debianu dostala celkem rychle). V dobách, kdy jednou za půl roku někdo na FTP nahrál nový tarball nebyl pro distribuci problém zmáknout 20 000 balíčků. Dnes s releasem každých 14 dní to taková legrace není.
Některému SW tak moc nevěřím. Ač proces balíčkování v Debianu zajišťuje jistou kontrolu, kdybych např. vydal novou verzi SW jehož jsem maintainer, tak propašovat škodlivý kód je maličkostí (nezkoušel jsem to v praxi, ale v praxi nikdo diffy kódu neaudituje, potom co je balíček do repozitářů zařazen).
A nakonec, ač trochu smutně, musím souhlasit s slovy Linuse na DebConf - Parafrázuji "Myslím, že by vývojáři Debianu neměli trávit čas balíčkováním každé GUI aplikace, ale spíše věnovat úsilí core balíčkům.
A to řešení problémů uživatelů jde taky automatizovat? Ono samotné balíčkování se automatizovat dá, ale hlavní úlohou správce balíčků je poskytovat podporu: reagovat na hlášení uživatelů, zařídit, aby se problémy opravily atd. A to rozumně opravdu automatizovat nejde. Když počet správců balíčků zredukujeme opravdu jen na ty, kteří tu podporu zvládnou pořádně (např. jsou schopní backportovat opravu z upstreamu), tak se dostaneme na tak malé množství lidí, že očekávat od nich, že budou držet krok s množstvím open-source softwaru, který vzniká, je opravdu naivní. Balíčkování všeho starým dobrým způsobem přes distribuční procesy se ani trochu neblíží škálovatelnosti, která by byla potřeba.
Nakonec budou distribuce postavené před otázku, co má s omezenými zdroji smysl distribuovat a co už nechat na ostatních. Některé distribuce už si to uvědomují, jiné to čeká.
Prekvapivo so Snap balíčkami nemám problém a dokonca by som povedal že sú menej problematické... najme pre vývojárov je vytvorenie balíčka pomocou snapcraft záležitosť napísania 10 riadkového Yaml a spustenie jedného príkazu. Manažment verzií je tiež veľmi jednoduchý u Snapu. Skúšal som Flatpak, tam to bolo horšie. Aj keď zas jednu výhodu Flatpak má, a to predovšetkých rýchlosť spúšťania, aj keď poslednou dobou cítiť že sa na snapoch pracuje.
Ako ja som spokojný, samozrejme mohlo by to byť ešte lepšie ale i tak som spokojný... Linux svet má mnoho horších problémov než balíčky.
Osobne som rád za všetky čo máme a používam aj .deb (apt), aj snap, aj flatpak (i když ten len kvôli jednej aplikácii - EasyEffects)
Pokud budeme pracovat s premisou, že jedním z primárních cílů těch projektů je univerzální formát, který funguje napříč distribucemi, tak AppImage je z těch tří zdaleka nejhorší. Tu nezávislost na systému totiž principiálně neřeší. Je to ve stylu "něco si přibunduluju, u něčeho budu spoléhat na to, že je to v distribuci alespoň ve verzi XY". Jenže ono často není. Výsledkem je, že podobných problémů s AppImage je opravdu hodně.
Ono zdaleka nejde prave jen o to, jestli ta klihovna v distru je, ale jaka je verze. A to je casto katastrofa. Stare verze knihoven prinasi problemy nejen bezpecnostni, ale i funkcni.
Je sice hezky, ze se distro postara, pokud ma knihovna sec. problem, ale knihovny maji i obycejne chyby. Takova bezna, ale otravna chyba od nahlaseni, opravu a jeji zahrnuti do distro update hrozne zdrzuje vyvoj, pripadne prinasi zatez kvuli workaroundum.
Vysledek: tendence to linkovat primo do projektu, nebo si delat vlastni bundle knihoven. Sam posud, co je lepsi.
Ad verzie kniznic v distrach, mate nejaky link ktory by popisoval aktualny stav kniznic v jednotlivych distrach, ci je to hruby odhad?
Ad chyby v knizniciach. Radsej mat jednu zaplatovanu kniznicu, ako x desiatok kniznic roznych verzii s nezaplatovanymi chybami.
Ad stare verzie v distrach. Dost zavysle na distre, pravdepodobnost aktualizacie v distre je omnoho vyssia ako pravdepodobnost aktualizacie vo snape/flatpaku. Cize to ze kniznica v dostre bude starsia, je stav velmi pravdepodobne kratkodoby.
Co by som si vybral? Na widlach ma neskutocne s****lo mimo ine aj to ze co projekt to sada kniznic, ktore uz v systeme boli, len co projekt to ina verzia. Az som jedneho dna widle zmazal nadobro. Takze ja som si vybral uz davno...
"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...
ČLÁNKY DO MAILU