Je mi jasný, že budu za flame*, ale
> Uživatelé Linuxu tak nyní mají okamžitý přístup k aktualizacím a novým vydáním Firefoxu, podobně jako na Windows a macOS, aniž by museli čekat na aktualizaci distribučních repozitářů.
to doteď nešlo? Stejně jako snap/flatpak mohli balit deb/rpm, ne?
--
[*] NECHCI Z TOHO FLAME, jestli někdo ví o důvodech, které mozille bránily vydávat balíky tradičního formátu, rád si je poslechnu...
Ono to skutečně tak snadno nešlo, protože to předpokládalo vždycky připravit, testovat a podporovat jeden .deb pro Ubuntu 16.04, jeden pro 16.10, jeden pro 17.10..., pak jeden pro každou z podporovaných verzí Debianu, totéž u rpm distribucí atakdále. Kromě toho vydávat a udržovat deb nebo rpm je pracnější a náročnější, než snap (s balením ve flatpaku zkušenost nemám). To je ten hlavní důvod, proč prakticky žádný upstream vývojář aplikací, včetně samotného Linuse Torvaldse, nevydával hotové binárky pro Linux ale vždycky jenom zdroják, který kompilovaly a balily samy distribuce. U některých věcí je to jistě výborný způsob, ale u aplikací pro koncového uživatele, jako je prohlížeč, všelijaké přehrávače nebo kancl, je to spíš veliký opruz. To si právě snap (a appimage a flatpak) dali za úkol vyřešit.
K tomu "všude" mají oba ještě daleko, ale rozdíl je mj. v tom, že zatímco takový .deb nebo .rpm balík je specifický pro jednou danou verzi jedné dané distribuce, balík ve snapu bude fungovat na jakékoli distribuci, která tento formát podporuje. Konkrétně se tentýž snap dá přímo instalovat na všech verzích Ubuntu počínaje 16.04, na Debianu, Archu a s jistými omezeními na všech verzích Fedory počínaje 25. Stejně tak se tetnýž flatpak dá instalovat na všech Fedorách od 25 a s určitými (menšími) omezeními i na Debianu a Ubuntu.
Jsou i jiné výhody, osobně ve Snapu oceňuji to, že je možné snadno downgradovat na starší verzi, což v .deb i .rpm byl vždycky problém a často to prostě nejde.
".deb nebo .rpm balík je specifický pro jednou danou verzi jedné dané distribuce." nie je pravdive tvrdenie. pouzivam Debian stable a bezne don mixujem testing baliky. Ak naplnim zavislosti, nie je to problem. Dokonca aj par debianich balikov tu mam.
" s jistými omezeními" , "s určitými (menšími) omezeními" mi neznie uplne univerzalne, ale to sa zrejme casom urtrasie.
Dalsi potencialny problem, podla omgubuntu je snapovy FF velky 193 MB proti 73 MB "obycajneho" baliku. Je mi jasne, ze su to vsetky kniznice a spol, ale tie uz v systeme mam, mozno aj v novsej, zaplatovanejsej verzii ako v tom snape.
Budu vyvojari firefoxu vydavat novy snap zakazdym, ked sa zaplata niektora zo zavislosti, ktore su pribalene?
Právě, že ne. Můžete svoji aplikaci zabalit jenom jednou jako snap nebo jenom jako flatpak a v normálním případě si ji může instalovat každý nezávisle na distribuci. Není nutné podporovat současně snap i flatpak, v tom je hlavní rozdíl oproti deb/rpm. Je sice pravda, že jsou stále distribuce, jako např. Gentoo nebo (pokud vím) Slackware, kde to nefunguje, ale na těch se obyčejně stejně nepoužívají appky pro BFU vydávané jako binárky.
No, já to vidím trochu jinak:
- vydám program jako flatpak, pak jsou cílem instalace distribuce, které podporují instalaci flatpaku (a uživatel může změnit distribuci, nebo autory přesvědčit, aby flatpak podporoviali)
- vydám to jako deb, pak jsou cílem instalace distribuce, které podporují instalaci .debu (a uživatel může změnit distribuci, nebo autory přesvědčit, aby .deb podporovali)
Prostě to vydám v určitém používaném formátu a pak je na straně uživatele/správce, aby si s tím formátem poradil?
>Pro nainstalování debu stačí dpkg.
No, třeba u mě na Fedoře instalovat přes dpkg moc dobrý nápad není. Ony tyhle univerzální balíky mají hlavní výhodu v tom, že nejen že mohou fungovat všude, ale instalované věci nijak nesahají do systému a nekolidují tak se systémovými balíky. Když se přidá Flatpak sandboxing a oddělení oken aplikace ve Waylandu, je výsledek potenciálně mnohem bezpečnější než standardní balíky.
> No, třeba u mě na Fedoře instalovat přes dpkg moc dobrý nápad není.
To už je na vývojářích, kolik toho budou podporovat sami a k jakému zbytku dají zdrojáky... Pak by ukázal uživatelský zájem, na kolik je tohle a tamto potřeba. Třeba by fedora přišla k debu. Třeba by ubuntu přešlo na rpm. Třeba by se všichni poučili z archu.
> Ony tyhle univerzální balíky mají hlavní výhodu v tom (...)
Chápu výhody, ale vidím i nevýhody a je podle mě blbost, jak ta zprávička pro mě vyzněla - totiž "mozilla balí firefox do snapu, doteď nešlo, aby vývojář vydal koncový balík".
>a je podle mě blbost, jak ta zprávička pro mě vyzněla - totiž "mozilla balí firefox do snapu, doteď nešlo, aby vývojář vydal koncový balík".
Já v kontextu spíš nechápu proč Snap a proč ne Flatpak (případně appimage, ten snad běží opravdu úplně na všem). Snap zatím zas až tak univerzální není.
Jinak věta „Uživatelé Linuxu tak nyní mají okamžitý přístup k aktualizacím a novým vydáním Firefoxu, podobně jako na Windows a macOS, aniž by museli čekat na aktualizaci distribučních repozitářů.“ nijak neříká že doteď nešlo vydávat koncový balík. Jen říká že se konečně vybralo řešení a začalo se to dělat. V případě vydávání rpm a deb balíků by to znělo stejně, jen by neměli tak velké pokrytí distribucí.
Má ji lepší v tom smyslu, že většinou funguje více méně plnohodnotně, zatímco snap se degraduje na distribucích, které nepodporují AppArmor. Důležitá je ale podpora ze strany vývojářů. GNOME a související projekty evidentně preferují flatpak, ačkoli mě překvapilo, že v 3.28 začali u některých balíků upstreamovat i podporu snapu. Naproti tomu třetí strany, zejména komerční, se poslední dobou dost orientují na snap. Uživateli to může být jedno, protože v praxi může instalovat aplikace v obou formátech.
Taky by mě zajímalo, co jsou ta "určitá omezení", protože kromě toho, že má Ubuntu starou verzi Flatpaku, která neumí některé pokročilejší věci, o žádném nevím. Flatpak je ze svého návrhu lépe portovatelný, má minimum závislostí, proto dnes plnohodnotně funguje na výrazně větším počtu distribucí než snap.
S těmi závislostmi jsou na tom přibližně stejně. Snap předpokládá moderní kernel, seccomp, systemd a AppArmor (ale může fungovat i bez něj, ovšem bez některých bezpečnostních fičur např. na Fedoře). Flatpak, pokud vím, předpokládá moderní kernel, seccomp, systemd a případně SELinux (ale např. na Ubuntu se nepoužívá).
Flatpak na SELinuxu nikdy nezávisel (právě protože to je problém při portování stejně jako AppArmor) a na systemd už hodně dlouho nezávisí. Ale nejde jen o závislosti. Snap třeba umožňuje zpřístupnit libovolné části hosta, což zní jako dobrý nápad až na to, že už pak závisíme na hostu a přicházíme o tu univerzálnost. Tím mimochodem v ještě větší míře trpí AppImage.
Vždycky jsem si myslel, že Flatpak používá SELinux, tak díky za vyvrácení omylu :)
Co myslíte tím "zpřístupnit libovolné části hosta"? Host je přístupný jenom speciálním typům balíků, jako je classic nebo gadgety, což jsou režimy, jejichž obdobu Flatpak pokud vím nemá. U uživatelských aplikací, na které je Flatpak zaměřený, se snap chová v podstatě stejně. Hosta nijak jinak nezpřístupňuje, akorát umožňuje volitelně povolit používání určitých fičur jako je síť, joysticky, zvuk, GL atd. Ty se do snapového kontejneru ovšem namapují standardizovaným a dokumentovaným způsobem a ne libovolně, jak říkáte. Především to pak funguje stejně na všech distribucích podporujících snap, pokud ne, pak se jedná o bug v implementaci snapu to té které distribuce.
U "classic" snapů je sice celý host přístupný, ale i tyto aplikace se spouštějí ze svého vlastního prostředí a na lokálních knihovnách a konfiguraci nejsou závislé (pokud to nedělají vyloženě schválně).
Tahle řevnivost mezi snapem a flatpakem je ale především dokonale nesmyslná, protože zaprvé nikdo nemusí fatálně volit mezi snapem a flatpakem, na většině hlavních distribucí se dneska dají používat oba současně, a zadruhé mají trochu jiné cíle. Flatpak je primárně spojený s GNOME jako technologie vydávání a aktualizací jejich vlastních projektů. Snap se naproti tomu orientuje na vývojáře třetích stran, kteří chtějí vydávat něco pro Linux ale přitom nejsou nebo nechtějí být přímo zapojení do světa distribucí a FOSS komunity jako takové. Často se snapu vytýká, že je příliš vstřícný vůči proprietárnímu software, což je dle mého názoru kritika naprosto oprávněná.
Jj, myslel jsem ty classic a těch není málo. Ty mají volný přístup do hosta, často očekávají, že tam jsou věci stejně jako v Ubuntu a ono to nefunguje. Setkal jsem se s několika snapy, které ve Fedoře nefungovaly.
Pak jde i o to, jak se dělá sandboxing u snapů obecně. Z pohledu aplikace to je sice standardní seznam věcí, na které se můžou spolehnout, ale není to nic jiného otevírání cest v tom sandboxu. Aby to fungovalo i na straně hosta, vyžaduje to úpravy snapd pro každou distribuci a hlavně intenzivní testování, že se to na těch distribucích s novými verzemi nerozbíjí.
Flatpak přístup řeší přes portály, které jsou součástí té jeho platformy. Obecně právě to, jak mohou aplikace komunikovat se zbytkem systému, je na tom to nejzajímavější. Na běhu aplikace v izolovaném prostředí není nic zajímavého. To už máme dávno s LXC, chroot... A vývoj v této oblasti probíhá kolem Flatpaku. Ke cti vývojářů Snapu je třeba říct, že to postupně přebírají (třeba ty portály). Nejenže si tím odstraňují nedostatky vlastního řešení, ale hlavně unifikují API pro vývojáře aplikací, pro které tak bude jednodušší podporovat jak Flatpak, tak Snap.
Jinak Flatpak se rozhodně nezaměřuje jenom na GNOME, ale primárně na vývojáře třetích stran. Jen ta strategie je jiná. Canonical primárně prodává svůj Snap Store, to je samozřejmě víc na očích. Flatpak má teď nově Flathub, ale strategie je prosadit se jako formát v různých distribučních řešeních. Já vím o jednáních s několika firmami a ty kdyby převzaly Flatpak, tak by to byl obrovský úspěch pro něj jako formát. Jenže to trvá mnohem déle než jen zabalit aplikaci a zveřejnit ji v obchodě, u čehož, co mám informace, stejně to zabalení dělal přímo Canonical a danému vendorovi to poskytl, aby to měl bez práce.