Firefox 59 vyšel jako snap

Tak nevím, zda to souvisí primárně s touto verzí FF, ale přestaly se mi občas (nahodile) zobrazovat některé prvky na webových stránkách, třeba zmizí tlačítka, zmizí text a podobně. Zavřu prohlížeč, znovu otevřu a stránka je OK.

A to se vám stává ve FF obecně, nebo konkrétně u tohoto snapu?

Zdravím, stalo se to až nyní. Doposud jsem podobnou chybu ve FF neviděl. Viz https://i.nahraj.to/f/1XXB.png

Otá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 ...

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.

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.

Proto píšu snaha :) Jinak ono univerzální rpm / deb docela více méně jde, jen je holt nutné všechno linkovat staticky :)

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.

Autor zprávičky nechť příště zváží nahrazení slova "disponibilní" slovem "dostupný". Bude to mnohem čitelnější.

Děkuji za připomínku. Když člověk žije trvale mimo ČR a česky mluví málokdy, některé obraty holt nenaskočí tak, jak by měly :-(

Ovsem jen v pripade, ze nedoslo k brutalnimu katovani badzetu

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é.

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.

"Uživatelé Linuxu tak nyní mají okamžitý přístup k aktualizacím a novým vydáním Firefoxu"

To ale maj uz davno pokud pouzili tar balik. Ten podporuje automaticky aktualizace jako na Windows...

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/

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í.

Aplikace A a aplikace B mohou sdílet obě stejný runtime s knihovnou X a aktualizuje se jednou.