Firefox 22

Mozilla

A Mozilla elérhetővé tette népszerű böngészője, a Firefox 22-es verzióját. A változásokról részletesen a kiadási megjegyzések weboldal számol be. A kiadásban javított bugok teljes listája itt. Elérhető Windows, Linux és OS X platformokra számtalan nyelven, köztük természetesen magyarul is.

( bviktor | 2013. 06. 25., k – 22:57 )

Van par oldal, ami teljesen erthetetlen modon nez ki az eleg regota magammal cipelt profilomban. Pl. kickass igy nez ki, az imgur pedig mindig megdoglik feltoltesnel. Szuz profillal termeszetesen tokeletesen muxik. Masnak is csinal ilyeneket?

Igen erre gondoltam. Ha a disk-en lenne a cache, akkor következőre már nem kellene letöltenie a statikus tartalmak egy részét, másrészt pedig attól még szintén a RAM-ban lenne disk cache-ként. De igaz, írná is a disk-et, de hát pont az lenne a lényege hogy megjegyezze reboot-ok közt is.

Nyilvan, mivel ilyen ujrainditasbol naponta van nagyjabol 1. Ha hibernalok (marpedig altalaban szoktam), akkor 0.

De most el fogsz szornyulkodni: a Firefox-ot be szoktam zarni, amikor huzamosabb ideig nem hasznalom. Es a kovetkezo inditasnal kepes megint letolteni a 20k-s kis kepeket. Es akkor most mi van? :)

Több értelme amúgyis inkább az ilyen szir-szarok letiltásának van, mint pl. facebook social beépülők, google analytics, google +1, meg ilyen-olyan 3rd party cuccok.

Mióta feltelepítettem a Ghostery-t Operára, végre megint hozza a web az 5 évvel ezelőtti szintet (persze azóta nagyságrendekkel gyorsult az elérés).

A ??-re. Ha kiírsz egy file-t disk-re, az előbb RAM-ba, disk cache-be kerül. Azt nem tudjuk, hogy azonnal, 2 másodperc múlva 1 perc múlva vagy fél óra múlva kerül fizikailag a disk-re. Ez a kernel dolga. Ha lecsatoljuk a filerendszert, akkor a cache tartalma kiíródik a fizikai lemezre. A sync paranccsal is lehet ezt forszírozni. Mellesleg éppen ezért tilos kihúzni pendrive-ot csak úgy a csatlakozóból. Előbb umount, aztán utána kihúzható. Windows-on is, Linuxon is.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Hja jo, nehez ugy, ha egyszerre ket dologrol beszelunk ugyanazon a neven ;)

Valoban nem feltetlen irja ki disk-re azonnal, de ez egyreszt nem jellemzo, hogy tul sokaig varna, masreszt amugy sincs az egvilagon semmi jelentosege, max letolti ujra, ha elveszik barmi oknal fogva.

A pendrive-os dologhoz meg annyit fuznek hozza, hogy ez csak akkor igaz, ha a kesleltetett iras engedelyezve van (Windows-on pl. kapasbol off by default), kulonben azonnal elkezdi kiirni. Nyilvan azt meg kell varni, amig a program jelzi, hogy kesz a masolas, vagy akarmi, vagy ha tutira akarsz menni, rendkivul szakszeruen "varj, amig villog" (mar elore latom az idezeteket). Utana viszont semmi szukseg kezi lecsatolasra. Ha meg egyaltalan nem irsz semmit a pendrive-ra, vegkepp.

Böngésző cache != disk cache, és innentől nem volt szó ugyanazzal a szóval eltérő fogalmakról. Én úgy értettem, hogy log69 arra utalt, hogy nem feltétlen lassú a file művelet diskről, hiszen sok esetben az is RAM-ból kerül elérésre. Tehát, ha létrehozol egy file-t, megírod, hamarosan olvasod, akkor az jó eséllyel még RAM-ból jön vissza.

Azt nagyon nem kellene terjeszteni, hogy lecsatolás nélkül rántjuk ki a gépből a pendrive-ot. Egyfelől, nem feltétlen tudja a felhasználó, milyen mount opciókkal van az eszköz felcsatolva. Másrészt nem tudjuk, a kernel mikor gondolja, hogy fizikailag az eszközre írja a disk cache tartalmát. Így aztán azt sem tudjuk, mikor fejezte azt be. Továbbá, ha fel van csatolva az eszköz, akkor azon bármelyik pillanatban lehet újabb file-t megnyitni. További kellemetlenség, ha a filerendszer nem naplózó, mert akkor rendesen széthullhat az egész, nem csak adatvesztés lehet. Már úgy értem, nem csak az éppen frissen kiírt adatok veszhetnek el. A pendrive-okon leggyakrabban használt FAT nem naplózó.

Ami a sync opcióval való mount-olást illeti, flash drive esetén elég rossz ötlet már azon túl, hogy lassabb lesz:

sync All I/O to the filesystem should be done synchronously. In case of media with limited number of write cycles (e.g. some flash drives) "sync" may cause life-cycle shortening.

Amúgy nem értem, miért okoz fájdalmat a filerendszer lecsatolása, amikor ez a grafikus felületen elérhető Windows-on is, Linuxon is, meg parancssorból szintén.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

"Böngésző cache != disk cache, és innentől nem volt szó ugyanazzal a szóval eltérő fogalmakról."

Igen, de eddig vegig bongeszo cache-rol volt szo, azon belul pedig disk es memory cache.

"Én úgy értettem, hogy log69 arra utalt, hogy nem feltétlen lassú a file művelet diskről, hiszen sok esetben az is RAM-ból kerül elérésre. Tehát, ha létrehozol egy file-t, megírod, hamarosan olvasod, akkor az jó eséllyel még RAM-ból jön vissza."

En azt meg mar leirtam lejjebb is, hogy a valosagban erre nagyjabol 0 esely van.

A pendrive-os panikra mar leirtam, hogy miert hulyeseg. Nagyon specialis korulmenyek kellenek ahhoz, hogy barmi gond legyen belole. Nekem edesmindegy, hogy ki hogyan hasznalja, ettol fuggetlenul az teny, hogy kesleltetett iras nelkul ebbol nincs baj, ha a muveletek mar befejezodtek a gepen.

A flash elhasznalodasa megint csak eroltetett, es max akkor lenne jogos, ha pl. OS-t futtatnal rola. Egy mezei masolasnal (i.e. az esetek 99.99%-aban) tokeletesen ugyanannyi irasi muvelet, mintha async lenne.

Azt pedig, hogy miert okoz fajdalmat a lecsatolas: nem okoz fajdalmat, csak egy total folosleges, rendkivul gyakori pluszmuvelet, ami az agyamra megy.

Igen, de eddig vegig bongeszo cache-rol volt szo, azon belul pedig disk es memory cache.

Jogos, viszont ha lemez művelet, akkor ott a disc cache, s így kerül a képbe a RAM.

nagyjabol 0 esely van

Szerintem meg nagy esély van. Többnyire az utoljára írt, olvasott file-ok, vagy azok részletei vannak jó eséllyel disk cache-ben. Akkor kerül ki onnan, ha a böngészés mellett intenzív disk műveletet végez valaki, például fordít valamit forrásból, szerverként működik a gép, és kiszolgál, ilyesmi.

Nagyon specialis korulmenyek kellenek ahhoz, hogy barmi gond legyen belole.

Értem, tehát amit meg tudunk csinálni műszakilag megbízhatóan, azt rontsuk el úgy, hogy néha működjön, néha meg kárt okozzon. Speciális körülmény vajon az, hogy egy memory leak-es alkalmazás miatt swap-elni kezd a gép, és nincs ideje a disk cache-t a flash-re szinkronizálni? Mert szerintem ez üzemszerű állapot, a kernel manageli, hacsak a buta user nem rántja ki a pendrive-ot a csatlakozóból.

A flash elhasznalodasa megint csak eroltetett, es max akkor lenne jogos, ha pl. OS-t futtatnal rola. Egy mezei masolasnal (i.e. az esetek 99.99%-aban) tokeletesen ugyanannyi irasi muvelet, mintha async lenne.

Ebben biztos vagy? Egy szektor 512 byte, ha FAT16-ot használunk, akkor 256 cluster bejegyzése fér el a file allokációs táblának egyetlen szektorában. Ha egyetlen bejegyzést módosítunk, úgy fel kell olvasni a szektort, 2 byte-ot módosítani, majd visszaírni az egész szektort. Ahogy a file 256 cluster-ét kiírjuk, úgy a FAT egyetlen szektorát 256-szor írtuk. Ha disk cache-t használunk, akkor pedig 1-szer kell írni ezt a szektort.

Tudom, bele lehet ebbe kötni, hogy a filerendszert csak nem implementálták ennyire bénán, s magában a filerendszer megvalósításban a FAT-et illik RAM-ban tartani. Nyilván ezt is lehet, viszont ez is implementációtól függ, azaz semmi garancia sincs rá, hogy így van.

Az egésszel csak azt akartam mondani, hogy ami ki van jól találva, azt nem kellene nagyvonalúan figyelmen kívül hagyni. Nekem ezek véres rongynak minősülnek. A másik ilyen dolog a CPU specifikáció által meghatározott órajelfrekvenciájánál gyorsabb járatása. A gyártó tud worst case méretezni, míg a tuningoló felhasználó csak azt tudja, hogy látszólag stabil a gépe, azt viszont nem, hogy mikor lesz az események olyan együttálása, amikor már szétesik a CPU állapotautomatája.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Miért?

free -h
             total       used       free     shared    buffers     cached
Mem:          3.9G       1.8G       2.0G         0B        97M       956M
-/+ buffers/cache:       825M       3.1G
Swap:         8.1G         0B       8.1G

Jelen pillanatban túl sok file műveletem nincs, talán olykor pár kB-ot logol. Ehhez képest 956 MiB a cache. Annak nem látom értelmét, hogy törölje, hiszen akkor vagy felszabadítaná a helyet, vagy azért volna hülyeség a törlés, mert disk hozzáférés alkalmával valóban lemezről kellene olvasnia. Így jó eséllyel van RAM-ban 956 MiB adat, amihez ha hozzá akar férni az alkalmazás, akkor nem kell a lemezhez nyúlni, cache-ből beszerezhető.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Meguntam, es favago modszerrel vegigjatszottam egy binaris keresest a prefs.js-en. Megoldas:

security.enable_tls := true

Nem tudom, mikor, miert lett letiltva nalam :D

Bonuszkent egy csomo ezer eves fost is kipucoltam, az osszes valaha hasznalt extension beallitasa itt rohadt, most kb. harmadakkora a fajl.

( resist v | 2013. 06. 25., k – 23:06 )

Nagyobb baj, hogy valamiért átveszi a Win7 "Képernyőtartalom olvashatóságának javítása" (Vezérlőpult/Képernyő) szerinti beállítást - pl 150%-ot, ami a Windows esetében jó egy Full HD laptopnál, viszont a Firefox nagy lesz tőle, és mindent (így a képeket, faviconokat, menüelemeket, honlapokat, betűket is) nagyít, homályosít. Nagyon csúnya.

flame

Nagyobb baj, hogy valamiért átveszi a Win7 "Képernyőtartalom olvashatóságának javítása" (Vezérlőpult/Képernyő) szerinti beállítást

Az bizony valóban nagy baj. Én erőst meglepődnék, ha effélét tapasztalnék. :DD

/flame

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Elolvastam.

Windows: Firefox now follows display scaling options to render text larger on high-res displays

Ugyanakkor írtam, hogy flame, s nyilván azért, mert valóban meglepődnék, ha Linuxon a Firefoxom átvenné valaki Win7-jének a képernyőbeállításait.

Különben meg elég vacak, ha ilyesmit meg kell magyarázni...

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( meridian v | 2013. 06. 26., sze – 09:04 )

nah, ezzel megint nem megy a khb online bankja... :)

( dejo v | 2013. 06. 26., sze – 09:22 )

Elég nagy a könyvjelző állományom. A 21-es verzió valamiért html-be nem mentette le. Illetve lementette csak elég lassan aztán még mielőtt befejezte volna törölte is. Néztem közben a fájlméret változást.
Ez a 22-es verzió végre lementi normálisan.
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

( therion | 2013. 06. 26., sze – 17:32 )

Ami engem elsődlegesen érdekelne az az, hogy a Media Foundation támogatása végre alapértelmezett lett-e. Sajnos nem találtam erre vonatkozó jelet a kiadási megjegyzésekben, szóval gyanítom, nem.

( szemet | 2013. 06. 26., sze – 18:15 )

Ez az asm.js ügyes ötlet, az emscriptenről már hallottam, de nem tudtam hogy ez (is) van mögötte.

Hogy mit értek ügyes ötleten?

A JS mint más nyelvek compilerjeinek backend-je teljesítmény szempontból nem optimális, egyszerűen mert nem arra tervezték

Alapvetően kéne egy jobb megoldás, és itt belépnek a böngészőgyártók és elkezdik ugye a saját pecsenyéjüket sütögetni (pl. ott a Dart VM), a többiek meg vagy csatlakoznak vagy nem - de inkább nem, mert megtehetik

Ez az asm.js viszont jól beletrafál a kompromisszumba: talán nem érhető el akkora fejlődés mint egy 0-ról indult tervezéssel, de mivel ez a JS részhalmaza a többi böngésző is eleve támogatja

Így a többi böngésző ezt nem zárhatja ki a képből, maximum azt vállalhatja fel hogy nem nyújt hozzá speciális támogatást: de ekkor viszont azt kockáztatja, hogy a FF marketing ez kihasználja és elárasztja a hírportálokat megalázó benchmarkokkal - ráadásul a meglévő C/C++ kódbázis és az emscripten miatt egyből elég impresszív alkalmazásokkal is demonstrálhat, nem csak sunspider szintű cuccokkal.