Názory k článku
Firefox ve snapu startuje o asi 50 % rychleji než dříve

No, typicke... nejdriv to cele dokonale zmrsime, abysme se pak mohli chlubit, jak to "vylepsujeme".

Doslova rovnák na vohejbák.

I ten titulek by možná chtěl trochu lásky, z "ve snapu startuje o 50 % rychleji" by si neznalý čtenář mohl odnést, že Firefox ve snapu startuje rychleji než na železe, přitom je myšleno "než jiné balení ve snapu, které je oproti nativnímu 15x pomalejší."

By ma zaujimalo preco nepouzili ZSTD

Oni ho pôvodne používali... len to bolo ešte pomalšie.

Tohle je takový urban legend podobně jako když spadne nějaký server a někdo se diví, proč ta služba nejela i na druhém. Při psaní software se provádí optimalizace až na základě nějaké zpětné vazby, protože optimalizovat jde všechno a přitom jen velmi málo problémů je ve skutečnosti důležitých.

@by_cx

Ano, tento přístup je velmi obvyklý. To se pak člověk může v jednom kuse divit proč je všechno zmatlané a pak se to musí v jednom kuse opravovat.

Já preferuji při psaní software popřemýšlet co je důležité, co hrozí, a těch pár nepředvídatelných případů holt opravit po tom. Docela bych se i vsadil, že s tím přístupem často předěláváte i polovinu aplikace "po zpětné vazbě".

Osobně si myslím že tento omyl vzniknul na základě té známé metafory o budování softwaru jako když se po stupně buduje ulita. Jenom lidi zapomínají, že ulita nezačíná jako třeba kopyto nebo ocas, a pak se neupravuje "až po zpětné vazbě". Od začátku začíná jako ulita, s tím že to bude ulita. S tímto omylem se setkávám často - to mě donutilo se tím více zabývat.

ne, při psaní SW již začínám s nějakým očekáváním, vzniká architektura a pokud to tady je špatně, dodatečná optimalizace jen hasí požáry. Snap je právě nešikovně postavená technologie už od počátku.

V realnem svete je potreba software taky nekdy vydat.

Ale oni už Firefox vydávali. "Lepší" řešení (aspoň z jejich pohledu) tak nebylo tlačeno časem.

Na druhou stranu, pokud shipujes neco, jako je nedovareny snap zakaznikum, tak se nediv, ze se tvari nemile. Tohle je neco, co mela zastavit QA.

Heh, to je blabol.
Kdyz udelam nejaky balik, tak to snad po sobe aspon spustim, kdyz uz to nikdo netestuje.

Nebo tam vazne delaj takovi autisti, kteri udelaj balik firefoxa co startuje pul minuty a cekaji jestli se nekdo ozve?

Třeba tam má každej Threadripper a 128G paměti, a nenapadlo je to zkusit na něčem přízemnějším, třeba s pouhými 8 jádry.

Vzhledem k tomu, že rozbalování snapu (a vlastně skoro celý proces spouštění snapu) je jednovláknový, tak můžeš mít klidně dual socket epycy kterým by se cely ff vešel do L3 a nepomůže ti to...

To fakt ty matlalové tahali doteď všechny jazykový mutace?! A já chtěl zrovna spílat Mageie, že Firefox táhne jako závislosti vedle firefox-cz ještě taky firefox-en. No tedy klobouk dolů před Canonicalem, že takovýhle matláky je ochotnej platit.

To je důsledek těch novodobých bludů ve stylu "storage/CPU time is cheap, an engineer's time is not". Člověk s tímhle nesmyslem v hlavě pak na nějakou efektivitu naprosto ███ a i věhlasné firmy pak vydávají software narvaný O(n²) nebo horšími algoritmy. Máme počítače tisíckrát rychlejší než před pár dekádami ale latence v UI je pořád stejně špatná.

On to nie je až taký nezmysel, hlavne keď si uvedomíme, aký je trh pre softvér a koľko sú ľudia ochotní platiť (teraz abstrahujem od skutočnosti, keď sa doja eurofondy... myslím bežný softvér).

No a počítače síce máme rýchlejšie, ale vstupné a výstupné zariadenia majú vyššiu latenciu než pred pár dekádami. Všetky tie usb stacky, kompozitory a hdmi/dp enkodéry/dekodéry majú svoju réžiu. Ako si svojho času povzdychol Carmack, dá sa rýchlejšie poslať IP packet z Ameriky do Európy ako zobraziť pixel na monitore.

Mě tolik nebolí poll rate mojí USB myši, nebo můj na dnešní poměry obstarožní pouze 60Hz monitor, nebo dokonce moje bezdrátová sluchátka s víc než 100ms latencí (kterou ale pulse/pipewire zná a kompenzuje, když koukám na film), protože to jsou všechno známé a ± konstantní latence.

Daleko víc mi vadí, že mezi kliknutím na tlačítko a zavoláním požadované funkce to propadne skrz desítky, v případě webových aplikací stovky vrstev (jen v callbacích poslední iterace Vue.js to tráví vyšší desítky ms), a některé z nich mají proměnlivé latence přímo v blokující cestě. Ať už je to synchronní API call, přístup na disk, IndexedDB v browserech... někdy to reaguje okamžitě, jindy po sekundách. Kde to jsme. Když to srovnám s něčím opravdu rychlým (nativní aplikace na waylandu), tak mi je až smutno :-)

9. 7. 2022, 00:04 editováno autorem komentáře

Canonical může mít desktop na háku, nic z něj nemá. Pokud to prošlo review, tak zjevně měli dobrý důvod to tak udělat.

To je oprava na strane Mozilly: https://bugzilla.mozilla.org/show_bug.cgi?id=1297520

jj, moje blbost, napadlo mě to až po nějaké době od komentáře. anyway, je to taky legrace. když člověk vypíchne z toho bugu tohle: "We plan to ship multilocale Firefox snaps. This may negatively affect start-up and runtime. We should figure out what the penalty is here." ... což autor Rail Aliiev napsal v srpnu 2016, tak si nelze nepoložit řečnickou otázku: jaktože o 6 let později jsme v této situaci?

To nikoho při vývoji nenapadlo, že když něco co startuje normálně sekundu najednou startuje 30 sekund, tak to asi bude velkej problém? Neřeknu, kdyby to byla nějaká beta. Ale vnutit to násilím všem uživatelům, a pak se několik let tvářit, že je vše ok? Ubuntu mám rád ale tohle fakt nechápu.

Jak už bylo řečeno, desktop jim nevydělává peníze. Takže do něj jdou i řešení, která jsou pro něj přímo nevhodná.

Coz zni jako prvotridni argument se k Ubuntu na desktopu ani nepriblizovat...

Ondra Satai Nekola
Coz zni jako prvotridni argument se k Ubuntu na desktopu ani nepriblizovat...

neberu ti tvoji volbu, ale pises nesmysl... vychazejici z nesmyslu predrecnika/u

Funguje to?
Ne.

Prolezlo to přes QA?
Jo.

WTF?
Maximální.

@bez přezdívky

- co startuje 30 sekund, FF99 v 20.04 na Atom 1gen?
- co vnutili uzivatelum? pred nekolika lety? FF-Snap kterej je v Ubuntu od 2021.10 ?

@k3dAR
- 30 sekund byla trochu nadsázka, ale 10-15 sekund mi snapy na moji i3 7. generace se ssd běžně startovaly, což je oproti .deb verzim který naskočí okamžitě dost otravný

- začalo to už třeba chromiem tuším v 19.10 kdy apt začal tiše místo deb balíčku instalovat snap verzi

11. 7. 2022, 13:47 editováno autorem komentáře

no 2% prehliadac tlaceny do snapu.
nic moc.
radsej Brave / Chromium na ktorom je nepodarena liska postavena.
Popripade ked uz tak Libre Wolf

radsej Brave / Chromium na ktorom je nepodarena liska postavena.
1) Firefox není postavený na Chromiu
2) Není to liška (ohnivá ani jiná), ale panda červená.

Dík za odkaz na LibreWolf. Už to mám na PC a ty PC šašky z Mozilly přestanu podporovat.

Proč ne. Akorát to nemá DRM.

Spoustu lidí nějaké DRM fakt nezajímá.

Zajímá, akorát tomu neříkají "DRM" ale "na tomhle prohlížeči nejde Netflix".

Podporovat?:-)

Dá se v tom nastavit minimální šířka tabů? Třeba když mám otevřených desítky tabů, abych se v tom vyznal. A věci typu kup si širší monitor nebo tři neberu. Neber to jako trloling. Fakt mě to zajímá. Před delším časem jsem nenašel řešení.

Snap nemusim a i kdyz Firefox (az na vyjimky) nepouzivam po prechodu z 20.04 na 22.04 odstranim ff-snap a dam ff-deb... nicmene:

Ta hromada "hejtru" co tu v diskuzi fnuka a nadava... zkusila to aspon??? ja ted ano,
ve virtualu (qemu) na 10let stare i7-3520M (pouze 2jadra/4vlakna), SSD na SATA
prirazene 2x vCore, 4GB RAM, Ubuntu 22.04 cista instalace

firefox99-snap (vychozi verze po instlaci)
- 20s prvni start
- 8s druhej start po reboot
- 7s treti start bez reboot

firefox102-snap (verze o ktere je zpravicka)
- obnoveni stavu virtualu pred pustenim ff99
- aktualizace ff99 na ff102 a reboot (ff nepousten)
- 13s = prvni start
- 8s druhej start po reboot
- 5s treti start bez reboot

takze kde je tech 30s dlouhej start Firefoxu? na 15let starem HW?
a proc se pod zpravickou o 50% zrychleni ignoruje ten fakt 50% zrychleni a resi se pomalost pred 50% zrychlenim?

Ci je to 30s alebo 20s je prast jak uhod, radovo je to stale v kategorii "totalne neakceptovatelne". Za mna je neakceptovatelnych aj tych 5 sekund, hlavne ak existuju konkurencne riesenia Flatpak a AppImage (predpokladam, ze toto je primarne zlyhanie Snapu samotneho, kedze v Snape je pomale uplne vsetko). Ja osobne som si napr. myslel, ze instalacia zlyhala alebo mi zamrzol system, pretoze som neveril, ze sa moze cerstvo instalovany prehliadac spustat viac ako 2 sekundy.

> a proc se pod zpravickou o 50% zrychleni ignoruje ten fakt 50% zrychleni a resi se pomalost pred 50% zrychlenim?

Ak ti ukradnem stovku a potom ti 50 korun vratim, pochvalis ma? (za tymto nehladaj dokonalu analogiu, len ilustrujem, preco diskuteri netlapkaju developerov po pleci za dobru pracu)

11. 7. 2022, 11:31 editováno autorem komentáře

Protože 50% zrychlení po 1500% zpomalení je pořád horší než na začátku, ne? Proč do toho benchmarku nedáš i Firefox bez snapu? Protože startuje pod 1 sekundu a nesedělo by to do narativu?

to neni ani odpoved na otazku... ani logicke... neptal sem se "proc se resi pomalost ff-snap Vs ff-deb", ale ~"proc se resi pomalost ff-99-snap, kdyz zpravicka je o ff-102-snap"

nicmene zkusil (v totoznem virtualu@hw);

firefox 102 deb z mozilla ppa
- 5s = prvni start
- 4s druhej start po reboot
- 3s treti start bez reboot

Takze srovnani ff 102-snap Vs 102-deb
prvni start 13s Vs 5s
druhej start 8s Vs 4s
treti start 5s Vs 3s

je tedy ff-snap 750% rychlosti ff-deb? nemyslim si ;-)
navic pokud tobe se ff-deb startuje pod 1s, tak ff-snap se by se startoval pod 2s...

Nevím jak tobě, ale mně teda i tohle 100% zpomalení oproti deb verzi přijde jako dost špatný. A to je to snap balíček, u kterýho už se věnovalo dost úsilí na jeho zrychlení, což taky není úplně běžná situace.

v pripade mejch testu pripominam ze slo o virtual na 10let starem 2c/4h CPU a prirazene virtulau jen 2 vCore a qcow2 storage na sata disku...

pokud se chces bavit o 10/11gen Intelu / AMD Ryzenu, s NVMe... jestli FF startuje 1s nebo 2s, tak to asi leda nadhod jako "vdecne" tema nekde v hospode ;-) nic to ale nemeni na tom ze mistni fnukari to opravdu asi nevyzkouseli a nadavaji na neco pro ne teoretickeho, nebo maji nejakou poruchu osobnosti ci vnimani realnejch problemu ;-)

btw: take pripominam ze sem prvni test zacal slovy ze s 22.04 take zmenim ff-snap na ff-deb, ale spis jen z principu nez z duvodu pomalosti ff->=102-snap

jinak tech "100%" "zpomaleni" je start FF cisteho profilu, pokud ma nekdo hromady oken/tabu co se pri spustnei oteviraji, tak ten cas k tomu potrebny (i kdyz se otevrou taby uspane) uz je stejny pro ff-snap i ff-deb, takze napr.:
ff-deb start 1s + profile_load 5s
ff-snap start 2s + profile_load 5s
mas 6s Vs 7s ;-)

a to sem vubec (radeji) neresil tu vec, ze povazuju za beznejsi zpusob pouzivani prohlizece ze se spusti a celej den proste bezi (v "horsim" pripade se vecer stroj vypne, v lepsim hibernuje, takze rano uz ff stejne bezi po resume z hibernace/sleepu) , nez ze by se pustil, podivalo na 1 stranku a vypnul, za 10minut opet pustil kvuli 1 strance a opet vypnul...

Zvlastni, ja mam C2D T7300 a FF snap se poustel 5min a pak zral 80% CPU na volnobeh i po 1h casu (daval jsem mu cas, kdyby neco robil na pozadi).. okamzite to slo pryc, FF se pousti instantne a zere 3% CPU na volnobeh v podstate okamzite. Takze jak vidno to na 15 let starem HW beha kazdemu jinak.

tak po povyseni Xubuntu 20.04 na 22.04.1, na 10let starem zeleze X230 s CPU i5-3320M a jen SATA SSD, startuje firefox103-snap 2s... nicmene na T430s s tou i7-3520M mi misto spusteni zarve:
cannot change profile for the next exec call: No such file or directory
snap-update-ns failed with code 1

zkusil sem to hodit do google, nic k veci mi to nenaslo, takze "snap remove firefox atd" vcetne "apt purge snapd"...
pro pripomenuti jak dal:
https://www.root.cz/clanky/jak-do-ubuntu-vratit-klasicky-firefox-z-balicku-deb-a-odstranit-snap/