Názory k článku
Firefox 59 vyšel jako snap
-
Zdravím, stalo se to až nyní. Doposud jsem podobnou chybu ve FF neviděl. Viz https://i.nahraj.to/f/1XXB.png
-
KateStříbrný podporovatelOtázka byla jestli je to FF z distribučního balíčku, nebo FF instalovaný ze Snapu.
-
Pokud to někoho zajímá https://support.mozilla.org/cs/questions/1209121 ...
-
Ravise (neregistrovaný)
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.
-
KateStříbrný podporovatel
Zdaleka ne všechny distribuce používají deb nebo rpm. Snaha Flatpaku a teď už i Snapu je fungovat všude.
-
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.
-
KateStříbrný podporovatel
Proto píšu snaha :) Jinak ono univerzální rpm / deb docela více méně jde, jen je holt nutné všechno linkovat staticky :)
-
mngnt (neregistrovaný)
".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?
-
KateStříbrný podporovatel
Nevím jak tohle řeší Snap, ale Flatpak odděluje běhový runtime a aplikaci. Takže když vyjde záplata závislostí, updatuje se runtime (Neoficiální Firefox Flatpak používá třeba runtime Gnome) a aplikace samotná může zůstat stejná.
-
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.
-
Ravise (neregistrovaný)
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?
-
KateStříbrný podporovatel
Nestačí pro instalaci Flatpaku instalace balíčku Flatpak? Některé distribuce ho mají už v základu včetně integrace do grafického správce balíků, ale mělo by to fungovat prakticky všude. I pro Gentoo je overlay.
-
KateStříbrný podporovatel
>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.
-
Ravise (neregistrovaný)
> 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".
-
KateStříbrný podporovatel
>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í.
-
KateStříbrný podporovatel
>To už je jeden z nevyhnutelných rituálů
Pokud vím, Flatpak má momentálně o dost lepší podporu mezi distribucemi. Ale možná se mýlím? -
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.
-
Karel (neregistrovaný)
Ale i tak se dá, jen je potřeba mnohem víc tlačit na engejdžment. Že není badžet není nepřekonatelná čelenč.
Už 20 let pracuji pro zahraniční firmy. A přestože jsem pořád v ČR tak přiznávám, že některé výrazy mi v češtině nenaskočí. Jak moc je to špatné si uvědomím jen ve chvíli, kdy některý z juniorních kolegů použije slovo, které neumí správně napsat nebo vyslovit. Na schůzce jsem nebyl už ani nepamatuji, máme jen meetingy. Tedy kromě občasného meatingu. No a na nich procházíme trackery, výjimečně i truckery. A přiznávám, že se na každý rok schvaluje budget. Rozpočet se neschvaloval už ani nepamatuju.
-
A bude to někdo chtít?
Mám sice starší verzi firefoxu (ESR), ale až se zase něco semele, tak mi přijde jedna aktualizace. Kdybych měl všechno ze snapů, tak musím kontrolovat všechny nalezené chyby, kontrolovat které snapy používají které knihovny, reinstalovat znovu všechno a ještě doufat že každý vývojář vydá snap nový ihned po nalezení chyby.
Kdyby to sponzoroval M$, tak bych se vůbec nedivil, protože mi to přijde ve stylu WinXP.
-
Ono to s těmi knihovnami je velmi dvojsečná zbraň. Je sice pravda, že například k tomu, aby se všechny aplikace ochránily proti Hartbleedu stačí teoreticky jednou instalovat opravenou verzi openssl. Jenže nějaký zásah do system-wide knihovny může i nechtěně způsobit, že některé z aplikací přestanou fungovat. Problémy s konflikty mezi knihovnami, pády kvůli náhle nevyřešeným symbolům (ačkoli až do poslední aktualizace to fungovalo) apod. přece jenom nejsou tak vzácné. Právě to vedlo na Windows (ovšem až 7, ne XP) k zavedení adresáře winsxs, kde jsou všechny verze všech DLL jedna vedle druhé.
Nevýhoda plynoucí z toho, že oprava knihovny vyžaduje rebuild balíku, je reálná, ale bohužel nelze mít obojí současně. Snap to aspon částečně dohání třemi způsoby. Zaprvé, všechny důležité knihovny, jako mj. kompletní stacky GNOME, Qt atakdále jsou přece jenom sdílené ze snapu gnome-platform-3-26-1604, stejný mechanismus má i flatpak. Zadruhé ve snapu aplikace standardně běží pod apparmorem a seccompem, stejně tak ve flatpaku pod SELinuxem, takže značná část potenciálních exploitů to má přece jenom těžší (záleží samozřejmě na typu chyby). No a konečně nevím sice jak u flatpaku, ale u snapu je vydání aktualizovaného balíku v typické situaci až směšně snadné.
-
mngnt (neregistrovaný)
Niektore (len niektore) kniznice mam aj na Debiane vo viacerych verziach a prelinkovane. Je rozdiel medzi novou udrzbovou verziou a novou major verziu, ktora rozbija spatnu kompatibilitu. V idealnom svete udrzbova verzia funguje presne rovnako ako predchadzajuca, nerozbija kompatibilitu.
"všechny důležité knihovny, jako mj. kompletní stacky GNOME, Qt atakdále jsou přece jenom sdílené ze snapu gnome-platform-3-26-1604" Takze snap obsahuje vsetky zavislosti danej aplikacie. Okrem tych, ktore neobsahuje, lebo su v inom snape.
"snapu aplikace standardně běží pod... " doraz na slovo standardne. Nie vzdy to je realne sandboxovane a zavsi to ciste na vyvojarovi. Vid Skype.
"snapu je vydání aktualizovaného balíku v typické situaci až směšně snadné." znamena co? Ako je to technicky riesene na strane distributora? Pokial viem, uzivatelovi sa update nainstaluje automaticky...
-
Aktualizace balíku na straně distributora se dá dělat různými způsoby. Tím směšně snadným myslím ten, kdy distributor v souboru snapcraft.yaml změní verzi potřebné knihovny (nebo checkout zdrojáku, atd.), comituje to na github a to je v podstatě všechno. Build bot si to vyzvedne a pokud build proběhne úspěšně, nová verze balíku se hned vypustí do větve "edge", kde ji autor může otestovat. Pomocí jediného příkazu snapcraft release (...) ji lze uvolnit do dalších větví (stable, candidate atd...), odkud se pak automaticky aktualizuje uživatelům.
Pokud v projektu používám knihovnu z repozitářů Ubuntu, což je nejběžnější a nejsnažší způsob (ale nijak povinný), a pokud má repozitář aktualizovanou verzi, kterou chci použít, většinou nemusím ani nic editovat a komitovat. Na snapcraft.io stačí kliknout na "build now" a nový balík se objeví v edge.
Samozřejmě tohle není nijak nutné, distributor může kompilovat a pracovat lokálně a naprosto nezávisle na jakékoli vnější infrastruktuře, ale uživatelsky přívětivější už to snad být ani nemůže.
-
Existuje i jiná databáze SNAP než:
http://www.snapfiles.com/new/list-whatsnew.html -
Hm, opravy zatím původních příspěvků nejsou, takže správný odkaz:
Existuje i jiná databáze SNAP než:
https://snapcraft.io/ -
Kkt1 (neregistrovaný)
Ono to tak stejne hloupe je. Problem je, ze v dnesni dobe lidi na kvalitu kaslou, tudiz se misto rpm ktere je plne zavislosti instaluje snap/flatpack ktere si ty zavislosti nese s aplikaci a kasle na system wide knihovny. Tudiz aplikace A ma sebou knihovnu X ve verzi N a aplikace B ma sebou tu samou knihovnu. Misto sdilene knihovny ve stylu rpm zavislosti ted mate na disku 2x tu samou knihovnu, cekate 2x na aktualizaci te knihovny ve dvou aplikacich a jako uzivatel vubec netusite co si ta aplikace nese sebou protoze vse je zabaleno v aplikaci misto jasnych zavislosti ve stylu rpm. Ono je to desne cool mit vsechny zavislosti v jednom aplikacnim balicku, ale uz nemuzete jako uzivatel rictze nechci pouzivat aplikace s vulnerable openssl, proste musite cekat az autor fixne svou aplikaci. Vyhoda ze aplikace je dostupna ve snapu rovnou pro podporovane distribuce je vyhodou pro autora aplikace, ale ne pro uzivatele.
-
Na kvalitu vůbec nekašlou, naopak si na základě dlouholetých zkušeností s rpm a deb uvědomili, že ta kvalita je širší a složitější problém. To, že aktualizace jedné knihovny rozbije nějakou další aplikaci, která na ní závisí, se stává celkem pravidelně, zvlášť, pokud někdo používá PPA a další podobné neoficiální repozitáře. To je ta známá hra na "co dneska nebude fungovat", hlavně u rolling dister, a když zrovna nefunguje něco, co nutně potřebuju, tak to do nějaké kvality má dost daleko. Jindy naopak důležitou aktualizaci kvůli dependence hellu provést nejde. Zvlášť pro někoho, kdo má zajišťovat smluvní podporu, to je dost zlé.
S těmito novými formáty by u openssl konkrétně problém nenastal, protože ta je součástí sdílených runtime knihoven, ale u nějaké jiné "nestandardní" knihovny je na vývojáři aplikace, aby to sledoval a balíky aktualizoval dle potřeby. Celkem vzato je to vlastně tak logické a i když je pravda, že tradiční model, kdy se jedna knihovna sdílí pro všechny instalované aplikace a dá se nezávisle aktualizovat, má nesporné výhody, způsobuje příliš mnoho problémů. Snap a flatpak v podstatě nedělají nic jiného, než co je dávno zavedenou praxí na Windows i na Macu, a mají k tomu dobrý důvod.
-
Řešení dle MS-Windows bych moc nechválil (a nebo jsem obsah příspěvku nepochopil). V profi praxi s koupeným drahým SW Microsoft updatne knihovny (záplaty) a náhle drahý SW je nefunkční. Jeho update je dražší, jak vlastní Windows (navíc 10 zadara).
Takže se často přejde na virtualizaci a SW se provozuje ve virtuálu bez záplatování. -
KateStříbrný podporovatel
Aplikace A a aplikace B mohou sdílet obě stejný runtime s knihovnou X a aktualizuje se jednou.
