Ott hagytam abba, hogy a teszt nem fért bele egyetlen postba. Folytatván a történetet:

8. Real-life teszt

Először is, összesítem az összes memóriafogyasztást (tehát amikor mind az 5 tab nyitva volt), illetve a felszabadítást (amikor ismét a kezdőlapján állt a böngésző):

Itt is kijelöltem győzteseket és veszteseket, de: A felszabadítás nem túl egzakt mérőszám, sok mindentől függhet. Az Opera kezdőoldala egy, az Opera.com-on lévő oldal, ami elég sok képet is tartalmaz, így fordulhatott elő, hogy negatívba vitte a felszabadítást. Az Arora-nak pedig ravaszul egy saját kezdőoldala van, ami nyilván sokkal kevesebb memóriát foglal. Ettől függetlenül az átlag felhasználónak sokat jelent, hogy mennyi memóriát foglalhat el a többi alkalmazása, így hát mégiscsak zöldeztem és pirosaztam.

And... the winner is....

Összesítve a pirosakat-zöldeket, az eredmény:

1. Midori: 5 pont
2. Chromium: 4 pont
3. Arora: 3 pont
4. Firefox3.5: 0 pont
5. Firefox3.0.12: -4 pont
6. Opera: -6 pont

A Firefox3 láthatóan elfáradt, nem igazán tudja tartani a lépést a többiekkel; ellenben a 3.5 megtestesíti a nagy átlagot. Első helyre került a Midori, a Chromium hozta azt a formát ami a Google bejelentések után elvárható tőle, nagyon jól teljesített az Arora (ahhoz képest, hogy fél éve még csak a nevét sem hallottam, elképesztően jól), az Opera pedig valami okból csúnyán leszerepelt.

Ha megadom a Midorinak azt az egy pontot a Dromaeo-s tesztnél, vagy ha az Operának megszavazom a bizalmat és elhiszem, hogy jól gazdálkodik a memóriával, a végső sorrenden az sem változtat.

Real-life teszt részletesen

Mivel ezt a tesztet végeztem el először, rögtön az első indítás után, ezért ha valaki követni szeretné, hogy kedvenc böngészője abszolútértékben mennyit fogyasztott nálam, adja hozzá az előző post "Indítás" fejezet alatt lévő értéket. Én ezt levontam, csak azokat az értékeket raktam be a táblázatba, amennyit pluszban és mínuszban fogyasztott; tehát ezek az értékek relatívak az induláskori memóriafoglaláshoz.

Voilá. Ha valaki jobban szereti a grafikus ábrázolást (én ilyen vagyok), akkor lássa ezt:

Remélem, látszik valamelyest; sajnos ez a blog.hu-s téma nem támogatja a széles grafikonokat. :-) A teljes felbontású képet fel fogom tenni a képernyőmentésekhez. Mit láthatunk itt? Érdekes módon legkevésbé a memóriapazarlónak tartott FF3 fogyasztotta a legkevesebbet. Az FF3.5, Arora és Midori pont úgy kezeli a memóriát, ahogyan gondoltam; az Opera szerintem cache-sel, a Chromiumra nincs magyarázat. :-)

Lássuk összesítve és grafikus formában a tesztek eredményét is:

Tudom, jó nagy ez a kép de kisebbet értelmetlen lett volna felrakni, hiszen még így is éppen hogy látszanak a százalékos értékek.

Értékelés

Gondoltam, a teszt mellett leírom a kialakult véleményemet is a böngészőkről, hátha ez segít valakinek abban, hogy melyiket válassza.

Firefox3.0 - 3.5

A kezdetektől fogva használom, ezért nekem ez az alap - ahogyan működik, amilyen billentyűzet-kombinációkat használ stb. Megszoktam és nagyon felhasználóbarátnak tartom. Lassan indul, de nem vészesen lassú használat közben. Csak egyetlen összeomlós hibáját ismerem, amit reprodukálni tudok: Ha a blog.hu-n automatikusan menti az írást és közben gépelek, akkor egy hang nélkül omlik össze. Hogy hozott-e újdonságot nekem a 3.5-ös verzió? Abszolút nem érzem így, még nem használtam az új funkciókat és sokkal gyorsabbnak sem éreztem, bár mint a tesztből kiderül, valójában gyorsabb.

Opera 9.64

Úgy vagyok vele, mint a KDE-vel: látom, hogy sokat tud, de én nem szeretném használni. Vannak olyan hisztériás dolgai, amivel nem tudok mit kezdeni: például azt játszotta, hogy adott oldal címét beírom, enter, és várok. Üres képernyő hosszú ideig, nincs timeout sem. Nyomok egy escape-et, újra megpróbálom - és mint a villám, behozza. A gmail-nél direkt próbálkoztam, szabályosan egyszer szórakozott, egyszer meg simán működött. A másik ökörség, hogy ha meglátogattam egy oldalt és bekerült a history-ba, akkor ha ezután elkezdem begépelni a címsorba az oldal nevét, akkor google-ös találatok előbbre kerülnek, mint az a bizonyos általam áhított oldal. Miért tesz Google találatokat előbbre, mint a domain név egyezőséget? Idegesítő.

Midori

A múltkori teszten egy jó régi változatot teszteltem; azt hiszem hogy kevés lenne azt mondanom, hogy látszik a fejlődés. Megnyerte a teszteket a nagy gyártók böngészői elől, kicsi és hatékony - a mai eredmények alapján a legjobb választás. Sajnos a blog.hu szerkesztőfelülete nem megy vele.

Chromium

Ez a böngésző egyszerűen félelmetes. Az a félelmetes benne, hogy hogyan tudtak egy ennyire komoly böngészőt írni ennyire gyorsan. Első indításkor felajánlotta, hogy átveszi az adatokat a Firefoxtól; mondtam hogy csinálja csak. Még a webes formokon megjegyzett mezőket is átvette! Egyértelmű, hogy Firefox killernek készült. Elsőre kicsit furcsa, hogy fent vannak a tabok, de jól meg lehet szokni, és ez volt az egyetlen böngésző, amely az Openoffice.org-ban kimásolt táblázatokat úgy tette be a blog.hu FCKEditorába, hogy ugyanúgy nézzen ki. (Egy dolog, ami nem tetszik, szintén a táblázatokkal kapcsolatos: ha táblázat cellában fel gombot nyomok, akkor adódna, hogy egy sorral feljebb megy; de nem ezt teszi, hanem úgy csinál, mintha balra mentem volna eggyel, és csak akkor ugrik egy sort feljebb, ha elért az első celláig). A többieknek ez nem sikerült. Onnantól ezt a böngészőt használtam átlagos felhasználásra, éppen most is ebben írom a postot. Lehet, hogy nincs adblock meg sztaki szótár plugin, sőt az SSL kezelés is csak parancssorból megy, de már így is brutális.

Arora

Aranyos, kicsi, gyorsan indul. Tényleg, számomra csak az az egy baja van, hogy QT-s. :-) Az index.hu oldal renderelésében pár hibát fel lehet fedezni, és ne felejtsük el hogy az egyik tesztet nem tudta teljesíteni, de egészen elképesztő, amit máris tud. Én simán a Midori-val egy szintre tenném, QT-s megfelelőjeként. Ez persze nem véletlen, a webkitet használják mindketten...

Ha végső sorrendet kellene mondanom a tesztek és napi tapasztalatok alapján, akkor Firefox3.5 -> Chromium -> Midori -> Arora -> Firefox3 -> Opera

A Firefox extension-jeit jelenleg semmi nem múlja felül, és akkor még ott vannak azok az apróságok, mint "kijelölés forrásának megtekintése", amit fejlesztőként gyakran használok. A Chromium a nagy memóriazabálás ellenére elég gyors és nagyon barátságos. A Midori nyerne, ha lenne egy olyan extension rendszere, mint a Firefoxnak ÉS ha működött volna a blog.hu admin felülete. Az Arora gyors, kicsi és máris kezes, csak hát QT, amit én alapból nem használok. Szegény FF3-nak és a QT-s Operának maradtak az utolsó helyek.

A képernyőmentéseket itt találjátok.

Ha van véleményetek, kérem írjátok meg.

Elérkezett a nagy nap, amikor az egyesek által elavultnak, ősöregnek, cammogó dinoszaurusznak tartott :-) Firefox3.0 kihívói megmérettettek. Mivel a kedélyek az előző postom után kissé felkorbácsolódtak, sőt emailen is kaptam pár megjegyzést arra nézve, hogy mit és hogyan kéne tesztelnem, és nem éppen szaloncukor-papírba csomagolva. ;-) Különösebben nem bosszant a dolog, de éppen emiatt határoztam el, hogy ha erőmből telik, minél előbb véget vetek a panaszáradatnak. Következzen hát a Midori versus Chromium versus Arora versus Opera versus Firefox3.0 versus Firefox 3.5 teszt!

Előkészületek

Meg kell, hogy mondjam, eredetileg csak a Midorit és a Chromiumot akartam szembeállítani egymással; és hosszas hezitálás után döntöttem úgy, hogy az Arora-t is megtesztelem, mivel nem igazán fűlött a fogam a QT4 felrakásához; de aztán végülis győzött a kiváncsiságom. Azután elgondolkodtam, hogy az Arora egyedüli QT-sként furcsán mutat, nem fair, ezért ötletszerűen letöltöttem egy Operát is a honlapjukról. Tovább gondolkodva oda jutottam, hogy nehéz úgy tesztelni a kihívókat, ha nem tudjuk hozzámérni a kihívotthoz, tehát a gépen lévő Jauntys Firefox3.0.12 tesztelése elengedhetetlen. Mivel viszont én kifejezetten szeretem a Firefoxot, most már azt nem tartottam fair-nek, hogy az összes többi böngészőből a legújabbat tesztelem, a Firefoxból pedig egy két évvel ezelőtti konstrukciót. Így hát hozzácsaptam a bagázshoz a legújabb, 3.5-ös Firefoxot, ami a Jauntyhoz elérhető.

A /etc/apt/sources.list szerkesztése triviális, root felhasználóként az alábbi sorokat biggyesztettem a végére (a webkit a Midorinak kell, ugyebár):

deb http://ppa.launchpad.net/midori/ppa/ubuntu jaunty main
deb http://ppa.launchpad.net/webkit-team/ppa/ubuntu jaunty main
deb http://ppa.launchpad.net/chromium-daily/ppa/ubuntu jaunty main
deb http://ppa.launchpad.net/mapopa/arora-stable/ubuntu jaunty main


Mivel a PPA repozitóriumokban a csomagok GPG aláírással rendelkeznek, hogy le tudjuk ellenőrizni az eredetiségüket, ezért importálnunk kell a nyilvános kulcsokat:

bagoj@tarantula:~$ sudo apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 4E5E17B5
bagoj@tarantula:~$ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys A69241F1
bagoj@tarantula:~$ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 2D9A3C5B
sudo apt-key adv --recv-keys --keyserver keyserver.ubuntu.com EF648708


Az előkészítés után már csak telepítenünk kell:

apt-get update
apt-get install chromium-browser midori arora


Az Operát, ahogyan mondtam, a weblapről töltöttem le és telepítettem fel (.deb formátumban), a Firefox3.5-öt pedig a Jaunty tárolóiból.

A tesztgép

A teszteket a szokásos "nagyvasomon", egy IBM Thinpad T30-on követtem el:

• Intel Pentium 4 M CPU 2,2Ghz (BogoMIPS: 2392,3)
• ATI Radeon Mobility 7500
• 1006Mb RAM, vagyis 1Gb
• FUJITSU MHV2040A 40Gb merevlemez

A böngészők adatai összefoglalva

Az Arora nagy helyfoglalása arra vezethető vissza, hogy nekem nem voltak fent QT4 library-k, ezért elég sok mindent fel kellett pakolásznia. Ugyanígy a Chromiumnak valószínűleg. Ha mondjuk egy olyan gépről telepítek, ahol csak X.org van és semmilyen grafikus környezet, akkor a Firefox-ok is ugyanennyit tettek volna fel. Érdekes, hogy a statikusan QT3.3.5-höz fordított Opera viszonylag kevés helyet foglal. A Firefox3-at nem is tudtam eldönteni, mennyit foglal, hiszen az alaprendszer része.

A teszt előtti utolsó lépések

További előkészületként, mielőtt elkezdtem volna tesztelni, a Chromium-nak és az Operának odamásoltam a flash lejátszásához szükséges osztott programkönyvtárat:

sudo cp /usr/lib/flashplugin-installer/libflashplayer.so /usr/lib/chromium-browser/plugins/

sudo cp /usr/lib/flashplugin-installer/libflashplayer.so /usr/lib/opera/plugins/

 A Chromiumot a "chromium --enable-plugins" paranccsal indítottam minden esetben, hogy a flash támogatást betöltse. A többi böngészőt csak simán a nevével indítottam el, és a kezdőoldalt minden esetben a "gyári" értéken hagytam. Ennek a teszt módszertannál lesz jelentősége mindjárt.

Sajnos az Operának nem volt elég a libflashplayer odamásolása. Túrtam a netet és találtam leírásokat is, hogy mit kellene leellenőrizni, én mindent megtettem, és az about:plugins is azt írta ki, hogy van Flash támogatás, mégsem jelenítette meg a Flash animációkat. Ezért nem vontam le pontot, mivel elképzelhető hogy én nem értek hozzá, de kb. 20-25 perc szenvedés után feladtam.

Hogyan teszteltem?

Vegyük sorba, hogy milyen teszteket végeztettem el a böngészőkkel. Mivel ilyet még nem csináltam, ezért gondoltam, elég lesz a CSS-támogatás, a JavaScript sebesség és némi kompatibílitási tesztek mellett lesz egy real-life teszt is. Minden teszt előtt és után megnéztem a böngésző memóriafoglalását, majd ezután visszaléptem a böngésző kezdőlapjára, és harmadszor is megmértem, hogy mennyi memóriát sikerült felszabadítania. Ezeket az értékeket nagyon fontosan tartom abból a szempontból, hogy megismerhető a versenyzők memóriagazdálkodása, ami olyan gyengécske gépnél, mint az enyém, nem elhanyagolható.

Én nem írtam most JS tesztet, ehylett ezeket az ipari sztenderdnek mondható teszteket választottam ki (ezek valamilyen szinten mind elfogultak valamelyik böngészővel szemben, hiszen adott böngészők sebességtesztjére és fejlesztésére használják):

1.Celtic Kane - Ezen a teszten az Opera és a Safari szokott nyerni; elég egyszerű; van benne sztring, matematikai, tömb és DOM és Ajax művelet is. Az eredményt millisecundumban adja, a kisebb érték a jobb.

2. Google V8 teszt - Ezt a tesztet a Google fejlesztői hozták létre a V8 Javascript engine tesztelésére. Gondoltam, itt végképp kiderül, hogy a többiek hogyan muzsikálnak a Chromium ellen, míg természetesen biztos voltam benne hogy ezt a tesztet melyik böngésző nyeri. :-) Az eredmény egyetlen pontszám, ami minél nagyobb, annál jobb.

3. Sunspider - Elsősorban a Webkit motor tesztelésére szakosodott, sok és alapos JS tesztet futtató oldal. Az eredményt ez is futási időben, ms-ban adja meg, értelemszerűen a kisebb érték a jobb.

4. Dromaeo - A Mozilla Alapítvány tesztprogramja, amivel a Firefox optimalizálások eredményét tesztelik. Ez a teszt önmagában is több, mint fél óráig tart; a meghatározott időn belül elvégzett műveletek számát nézi. Ebből következően itt a nagyobb érték a jobb. Ez a teszt leginkább a DOM-műveletekre fekszik rá.

5. TriteLife.com teszt - Ez a teszt semmi mást nem mér, csak bekezdések létrehozásának puszta sebességét. A több, mint 18 000 db. paragrafus színeiből egy képet rak ki. A teszt eredménye tökéletesen használhatatlan a napi használatban, de érdekesnek tűnt. Az eredmény ismét a futási idő, tehát a kisebb érték jobb.

6. ACID2 teszt - Szerintem nem kell bemutatnom - A CSS és a sztenderdeknek megfelelést teszteltem; a referencia képhez viszonyítva a különféle böngészők által létrehozott ábrát.

7. ACID3 teszt - bár a napi használatban nem sokat jelent, de úgy gondoltam, mégiscsak letesztelem az ACID3 tesztet is, hiszen ez a legújabb sztenderdeknek való megfelelést mutatja. Ismét egy referencia képhez lehet hasonlítani a böngésző képernyőjét.

Az első öt tehát lényegében JavaScript teszt, az utolsó kettő pedig CSS + standard compliancy. De hol marad a valós felhasználás?

8. Real-Life teszt - a saját valós felhasználásomat mértem. Konkrétan, elindítottam az adott böngészőt a kezdőlapjával, majd betöltöttem egyesével tipikus, jól ismert és sokak által használt weboldalakat; miközben mértem a memóriafogyasztást. Ezek után egyesével bezártam az oldalakat (fordított sorrendben) és ismét mértem a memóriát; tesztelve a felszabadítás mennyiségét.

Az ilyen weboldalak letöltése közben nyilván értelmetlen lenne sebességet mérni, hiszen ez erősen függ a hálózattól, úgyhogy sebesség adatokat nem teszek közzé ezúttal. A méréseket az alábbi oldalakkal végeztem:

• https://www.youtube.com/watch?v=XUXh-X1iveU
• http://www.index.hu
• http://www.hup.hu
• http://gmail.com (belépve)
• http://blog.hu/admin (belépve, épp ezt a postot szerkesztve)

Ezekről készítettem képernyőmentést is; ezek alapján össze lehet hasonlítani, hogy melyik oldalt hogyan renderelik le az egyes böngészők, mekkora a beállított alap font készlet stb. A mentéseket más időpontban végeztem, mint a mérést; hogy semmi se zavarja meg a tesztet (még így sem ugyanazok a képernyők kerültek mentésre, hiszen pl. az Indexen nagyon gyorsan változik a tartalom.)

Tehát még egyszer: betöltöttem a youtube-ot, mértem. Aztán nyitottam egy új tab-ot, betöltöttem a zindexet, mértem. Újabb tab a HUP-pal stb. Aztán bezártam a bloghu-t, mértem. Bezártam a gmail-t, mértem. Végül a youtube-ot nem zártam be, hanem a kezdőoldalra ugrottam.

 A böngészőket egyesével teszteltem, és minden teszt után kiléptem és külön ellenőriztem azt, hogy nem maradt-e a memóriában. A különböző böngészők között újraindítottam a gépet, ugyanis nem akartam sújtani egy másik böngészőt amiatt, mert mondjuk az előtte lévő folyatta a memóriát (bár ez nem valószínű, természetesen).

Minden tesztet 3x végeztem el, és a középső értéket vettem alapul. NEM ÁTLAGOLTAM, nem számoltam szórást, csak egyszerűen a középső értéket kiválasztottam és a többi mérési eredményt eldobtam. Ha valaki szeret átlagolni, futtassa le a teszteket, de én nem az elvont számtani átlagra voltam kíváncsi, hanem egy tényleges futási eredményt rögzítettem.

Bár szerintem a módszertan legalább olyan fontos, mint az eredmény, most jöjjön végre az utóbbi, hiszen erre várunk. Bevallom, a kiértékeléskor én is meglepődtem párszor... :-)

Ja, még egy fontos: A végeredményeket nem számszerűen, hanem százalékosan fejeztem ki; az aktuális legjobb a 100% és a tőle elmaradók automatikusan kevesebb. Ha a kisebb érték volt a jobb, akkor reciprokot vettem, hogy mindenképp összehasonlítható legyen az eredmény. Tehát a 100% az a maximum teljesítmény, a többiek a lemaradók.

Ezek után bepirosoztam a legrosszabb eredményeket és bezöldeztem a legjobba(ka)t; volt hogy egy kategóriában több piros vagy zöld van, ha közel álltak egymáshoz az eredmények. Ezután egy csontot kapott minden zöld, és egy csont levonást minden piros. Magyarul az egésznek a legvégén kijött minden böngészőre egyetlen, végső pontszám. (Minden kategória azonos súllyal esett latba, tehát pl. a valós élet tesztet nem tartottam fontosabbnak, mint az ACID teszteket. Akinek ez nem tetszik, számolja át; elvégre a matematika azért szép mert azt hozunk ki győztesnek, akit akarunk. :-))

Eredmények

 0. Indítás

A böngészők indítási idejét, és a default oldallal a memóriafoglalást is néztem. Ez csak referenciaként van itt, a végeredménybe nem számított bele.

1. Celtic Kane

Ez egy eléggé megosztós teszt volt. Nagy meglepetésemre az Arora az első, még a Midori kapaszkodik, A Chromium pedig próbálkozik, a többiek eredménye lesújtó. A Firefox védelmére annyit tudok felhozni, hogy látszik a fejlődés.

Nekem is eszembe jutott természetesen, hogy aki a legöbb memóriát foglalja le, az fogja nagy valószínűséggel a legtöbbet felszabadítani. De ez nem probléma szerintem, egy pont plusz, egy pont mínusz, nem történt semmi. Nem szeretnék úgy értékelni, hogy a lefoglalt majd felszabadított memória arányát vagy ilyesmit nézek, mert az csak újabb vitákhoz vezetne, illetve beleszólhat a Linux memóriakezelése is a dologba (pl. a Midorinál tuti valami ilyesmiről lehetett szó, de mit csináljak, ha ez jött ki, ez jött ki. Ja a memóriát nem mértem 3x, mielőtt félreértenétek, hanem az adott teszt memória-értékeit tettem el - ez jött ki és kész).

2. Google V8 tesztje

Szinte hihetetlen, hogy a Google böngészője nyert. :-) Az Opera viszont sajnos összeszedett pár rossz pontot, úgyis mondhatnám, hogy ez teljes bukta volt.

3. Webkit fejlesztők tesztje

Természetszerűleg számítottam a Webkit motorok szárnyalására. Nyert a Midori, a középmezőnyben végzett a Chromium, Arora és FF3.5, az FF3 és az Opera a végén kullog.

4. Mozilla Alapítvány tesztje

A nyerő pozíciót nyilván a Gecko motornak adtam ezúttal - de épp az a lényeg, hogy a valóság olykor meghaladja a várakozásokat. Az egyértelmű győztes a Chromium és a Midori is igen közel jár hozzá (adhattam volna egy pontot oda is).  Az FF3 és Opera a fasorban sincs, de náluk is rosszabb eredménnyel zárt az Arora, mivel egyáltalán el sem indult a teszt.

 5. Javascript bekezdés létrehozás teljesítmény-teszt

Ha teljesítményről van szó, a Midori ott van az első sorban - nincs ez most másképp sem. A Firefoxok rondán elvéreztek ezen a teszten, memóriapazarlóan és lassan hozták létre a bekezdéseket. Hozzátenném, hogy egyben ez a két böngésző volt mindössze, amelyik rákérdezett, hogy hosszú ideje fut már a Javascript, biztosan folytatom-e? Tehát egyben a legbolondbiztosabbak is a Vörös pandák.

 6. ACID2 teszt

A memóriakezelés és a teljesítmény között olyan elenyészőek voltak a különbségek, hogy nem hirdettem sem győztest, sem vesztest. Kijelenthetjük, hogy minden böngésző csont nélkül vette ezt az akadályt.

7. ACID3 teszt

Mivel ez a teszt szintén százalékosan adja meg a teljesítményt, itt nem kellett átalakítanom a végeredményeket. Megjegyzés, hogy az Arora, bár 100%-ra teljesített, volt egy "Linktest failed" hibaüzenet; az Operánál pedig egy "FAIL". Ezekért nem vettem le külön pontszámot, megtekinthetők lesznek a képernyőmentések között. A Firefoxnál látszik a javuló tendencia, a többi egyértelmű.

 8. Real-life teszt

Hogyan viselkednek, hogy eszik a memóriát ezek a "bengészők" valódi felhasználás közben?

Ezt sajnos nem tudom most leírni, mert belefutottam a blog.hu valamilyen limitációjába - egyszerűen nem lehet ennél hosszabb egy post. Visszatérek a következőben!

Mivel nyár van, buli és csajozás, csak ritkán jutok el a bloggig, de látom hogy Ti, kedves Olvasók, aktívak vagytok, ezúton is köszönöm szépen a sok látogatást! :-)

A kis gyors post lényege a.tom kérésének teljesítése; kipróbáltam hogy mennyire muzsikál szépen a midori böngésző.

Mint az közismert, a midori egy webkit-alapú, kicsi és gyors, sokak által méltatott böngésző. Mivel a szokásosnál is gyengébb gépen dolgozom pillanatnyilag (PIII 1GHz, 256M RAM), ezért nem mindegy hogy Firefox, vagy valami kisebb. Feltettem hát a midorit a szokásos, apt-get install midori paranccsal - mindössze 10Mb pluszt jelent kicsomagolva. Gyorsan indult, szépen (bár nem tökéletesen) jelenítette meg a weboldalakat (példa: Ha egy block-szintű elem height-je kisebb, mint a line-height, akkor kitesz egy csúszkát a szélére, mintha az egy overflow:auto-s DIV lenne, amiben nem fér el a tartalom). Ettől függetlenül szép és jó volt minden, amíg észre nem vettem, hogy hoppá a flash-es oldalak nem működnek. Kis töprengés után felraktam a flashplugin-nonfree csomagot is. Sajnos ettől nem javult meg, kiderült hogy meg kell adni a flash plugin könyvtárát is (ahol a libflashplayer.so van) a MOZ_PLUGIN_PATH könyezeti változón keresztül. Praktikusan így indítottam tehát:

MOZ_PLUGIN_PATH="~/.mozilla/plugins/" midori

Ezután simán elindult a flash, nem volt probléma, mindössze annyi hogy minden második alkalommal segfaultolt a midori. :-( Akár úgy is, hogy a főoldal bejött, egy linkre kattintva pedig behalt. Ráadásul nem is működött tökéletesen, a flash-ek háttere akkor sem volt egész képernyős, ha annak kellett volna lennie.

Összességében tehát jól indult a kapcsolatunk Midorival, de egyelőre kivárok. A tesztelt verzió a 0.1.2 volt, ellenőrzés nélkül is biztos vagyok benne hogy már most is van ennél jobb és újabb változat, amit biztosan fogok is tesztelni az Ubuntu Karmic Koalában.

Bónusz: Ugyanezen a gépen az Evolution és a Thunderbird is kicsit nehézkesnek tűnt. Felraktam hát a Balsát, alap feladatokra tökéletes grafikus levelező program. (A Sylpheed és Claws nekem nem jön be, régen a Sylpheed-et egy évig használtam és nem tudtam megbarátkozni a felületével - majdnem úgy működik minden, ahogy kéne, de aztán mégsem. Például ilyen a HTML formátumú levél támogatás; furcsán oldották meg, nekem meg nem tetszik, pont.)

Zenelejátszó programnak pedig a már tesztelt moc-ot tettem fel, télleg ott van a szeren a kis aranyos, annak ellenére hogy karakteres képernyőn működik.

A fenti mondat jutott eszembe, amit lelki szemeim előtt a szarvas nyuszi mond a Koalának. Ugyanis tegnapi hekkelésem a Koala-ban lévő kernel (jelenleg: 2.6.31-rc1) felhúzása Jaunty alá, így mondhatjuk, hogy Nyuszi Koalán "lovagol". Ezen felül tettem néhány szánalmas további próbálkozást a bootolás felgyorsítására (lényegében ez lett volna a célom).

Nem állítottam át a csomagkezelőt (hogyisne, még csak az kéne), hanem szépen megkerestem, hogy a Koala repo-ban a linux-source csomag hová mutat, majd letöltöttem:

wget "http://hu.archive.ubuntu.com/ubuntu/pool/main/l/linux/linux_2.6.31-1.13.tar.gz"

Némi telepítenivaló a kernel fordításhoz (a szokásos...):

apt-get install build-essential libncurses5-dev kernel-package

A letöltött, gzipelt állományt kitömörítettem a /usr/src alá. Készített egy ubuntu-karmic (vagy valami igen hasonló) alkönyvtárat, ami nekem éppen megfelelt. Beléptem tehát a /usr/src/ubuntu-karmic könyvtárba, majd generáltam egy alapértelmezett értékekkel feltöltött kernel konfigot (ez a .config nevű fájlban keletkezett meg):

make defconfig

Kernel fordítás for dummies

Ezek után egy olyan szkriptet használtam, amit a neten találtam, és aminek a használatát röviden így foglalnám össze:

1. Bebootolunk az alapértelmezett kernellel, ahogyan szoktunk.
2. Az udev (a szokásos módon) felismeri a hardvereszközeinket, és automatikusan behúzza a szükséges modulokat
3. az lsmod-dal kilistáztatható, hogy milyen kernel modulok vannak a memóriában
4. A szkript végigmegy a létező kernel konfiguráción, és szépen "y"-re állítja azokat a modulokat, amelyek eddig modulban voltak.

Az egész hatása az, hogy pl. az eddig modulban lévő IDE (SATA, PATA...) modul a kernel része lesz, következésképp nem kell initrd ami behúzza a modult, következésképpen nem kell initrd sem. Elegánsan hangzik.

Ez most tényleg fontos! Ahhoz, hogy ez jól működjön, értelemszerűen be kell dugni minden hardvert, fel kell mountolni az összes partíciót és hálózati elérést, amit használunk, meg kell szólaltatnunk a hangkártyát, csatlakozzunk a netre stb. különben annak modulja nem lesz behúzva, ergo nem lesz beállítva sem!

Az előbbi megjegyzés akkor is igaz, ha lehet hogy szerencsénk van és az alapértelmezett kernel konfigurációban pont a mi hardverünk be van állítva modulnak, így észre sem vesszük és az új kernel behúzza modulként a hardver kezeléséhez szükséges meghajtót. Erre ne építsünk, ha lehet. :-)

Tehát, a fenti szkriptet töltsük le (később majd részletezem a működését), és másoljuk le a /usr/src/ubuntu-karmic alá. Az eredeti konfigot is elmentettem, így össze tudom hasonlítani a kettőt, ha esetleg valami rosszul sült el: 

perl buildin_used_mods.pl > configused
mv .config config_orig
mv configused .config

Ha hihetetlenül magabiztosak vagyunk, akkor léphetünk tovább a kernel lefordítására. Én inkább futtatok egy make menuconfig -ot, és leellenőrzöm hogy minden, számomra lényeges be, illetve ki van kapcsolva. Az alábbi táblázatba szedtem ezeket:

Ezt azért írtam le, hogy merrefelé érdemes körbenézni. Ettől függetlenül ha később valami nem indul el, akkor bootoljunk vissza az eredeti kernellel és az lspci (usb-s dolog esetén lsusb) paranccsal kérdezzük le a kérdéses hardvert, és amit ott kiír, az alapján a neten megtaláljuk a szükséges beállítást.

Exit, exit, "Save kernel config?" -> naná, hogy yes.

make-kpkg kernel_image kernel_headers modules

Ez ellesz egy darabig, majd a /usr/src könyvtárba szépen és flottul előállítja az új kernelünket .deb csomag formájában. Ha már futtattuk a fordítást, akkor maradhattak hátra szemetek, szóval a fenti parancs előtt ilyenkor nyomjunk egy make-kpkg clean -t is.

A kernel csomag simán telepíthető a

dpkg -i <csomagnév>paranccsal. A kernel-headerst nem kell feltennünk, csak akkor ha az új kernelhez szeretnénk olyan programot fordítani, ami használja (pl. kernel modult fordít, ilyen lehet a vmware).

Most ismét egy nagyon fontos lépés

Mielőtt rebootolnánk...! Mivel kihagyjuk az initrd-t úgy ahogyan van, ezért nem tud lefutni az udev a legelején, csak később. Következésképpen nem jönnek létre a disk-by-uuid bejegyzések, így a grub-ban hiába hivatkozunk a root partíciónkra az uuid-vel. Ezt le kell cserélni a konkrét /dev/sdx névre. Nekem például a /boot/grub/menu.lst megfelelő részét így kellett átírnom: #title Ubuntu 9.04, kernel 2.6.31-rc1
#uuid 3b745ea2-f32d-4635-9a97-23884a4bcdc9
#kernel /boot/vmlinuz-2.6.31-rc1 root=UUID=3b745ea2-f32d-4635-9a97-23884a4bcdc9 ro quiet splash.
#quiet

title Ubuntu 9.04, kernel 2.6.31-rc1
kernel /boot/vmlinuz-2.6.31-rc1 root=/dev/sda5 ro quiet
quiet


Ezek után kutyakötelessége a kernelnek, hogy bebootoljon. Ha mégsem, nézd meg a tipikus hibákat, hátha segít.

Bút Túning

Gondoltam, mérjük le, mennyire gyors ez az új kernel; és rendezzük kicsit át a boot szkriptek sorrendjét is, hátha okosabb vagyok, mint egy ötödikesUbuntu mérnök.

A végén fogom egy kis táblázatban összefoglalni az eredményeket.

rc szkriptek rendezgetése

Tehát elsőként bebootoltam az új kernellel. Aztán a /etc/rc2.d alatt vágtam egy kis rendet:

• S10apmd -> kuka, acpit használok
• S10sysklogd, S11klogd -> S40sysklogd, S41klogd. Átrendeztem a sorrendet, desktopon nem baj, ha kicsit később indul el a rendszernapló, kibírom
• S20apport -> töröltem (automatikusan elemzi az összeomlott programokat és hibajelentést ad fel, vagy mifene)
• S50cups -> S99cups (nem gond, ha a nyomtató támogatás csak a legvégén indul el)
• S50pulseaudio -> S35pulseaudio (az audio támogatás viszont induljon el jó hamar)
• S89atd -> kuka (nem használom, csak a crond-t)
• S98usplash -> kuka (mivel nincs splash az új kernellel, semmi értelme)

Ezek után ismét megmértem a boot időt; majd jött a /etc/rcS.d alatti "rombolás":

• S40networking, S45mountnfs.sh, S46mountnfs-bootclean.sh, S49console-setup, S55urandom -> bemásoltam a /etc/rc2.d alá; így később indulnak el és megvolt az az elképzelésem, hogy így az X talán hamarabb feltápászkodik
• S70x11-common -> S38x11-common (szintén a gyorsabb X indulás miatt mozgattam korábbra az rcS.d könyvtáron belül)

Profiling

Negyedik lépésként, olvastam valahol hogy a profiling nagyban meg tudja növelni a bootolás sebességét. Ehhez nem kell mást tennünk, csak a kernel boot paraméterei közé betenni a "profile" kulcsszót, és egy szkript automatikusan optimalizálja a boot szkripteket. Legalábbis ez az elmélet. Megtudjuk, hogy mi a valóság, mert az utolsó két mérést a profiling után végeztem.

A boot paraméter beállítása úgy zajlik, hogy amikor indul a grub, és választhatunk, hogy melyik kernelt vagy oprendszert töltjük be (akinek csak linux van, annak elképzelhető, hogy nyomni kell egy Escape-et), szóval a boot menünél ráállunk a "fénygerendával" a kívánt kernelre, majd nyomunk egy 'e'-t, és a bejövő almenüben a 'kernel' sorra ismét egy 'e'-t (az 'e' jelentése: edit). A sor végére biggyesszük oda, hogy " profile" (azaz szóközt hagyjunk előtte), majd enter és a 'b' betűvel bebootolhatjuk az új paraméterrel az adott kernelt.

Eredmények

Úgyis mindenki erre kíváncsi, lássuk:

Mértem a grub menütől a gdm képernyőig, majd a jelszó beütés enter-étől egészen odáig, hogy megjelent a gnome-panel (ekkor azonnal rákattintottam a gnome menüre), és akkor állt le a stopper amikor végre le tudott gördülni a főmenü.

Látható, hogy a Koala kernel épp annyival gyorsabb az én gépemen, amennyit az initrd elvisz a boot időből. Következésképpen az én hardveremmel vagy nem lehet párhuzamosítani, vagy valamit én nem csináltam jól (esetleg a kernelfejlesztők :-)). Az rc2 alatti rendrakás ismét hozott egy másodpercet, de az rcS alatt hiába tettem át későbbre a hálózat inicializálást, valószínűleg az nem vesz el jelentős időt (vagy már ki van optimalizálva). A profiling pedig egyenesen visszarontotta a boot időt az eredeti hosszára.

Így hát nem vagyok okosabb, mint egy Ubuntus mérnök, és pár óra után ugyanott tartok, ahol voltam - csak a kernelem lett újabb. :-) Úgy érzem, még mindig csak kesztyűs kézzel paskolom a bootolás részt, ha amúgy igazán odacsapnék egy teljesen saját megoldással, egyedül az javítana látványosan az eredményeken.

Nem vagyok az a folyton panaszkodó alkat, egyszerűen most így jönnek ki a dolgok. Amint sokszor leírtam már, én jobban szeretem a könnyű, gyors kis programokat amelyek nem baj ha nem tudnak mindent, ha a fontosabb funkciók megvannak és azt tényleg gyorsan végzik, elégedettségem teljes. Emiatt is követem figyelemmel már több, mint egy éve az LXDE projekt fejlődését - hogy még könnyebben követhessem a történéseket, az lxde-users levlista adminja is vagyok. :-)

Sajnos a projekt egy ideje stagnál, mivel nem találnak elég fejlesztőt a feladatokra, minden erejüket a hibajavítások kötik le és abból van éppen elég, hiszen az LXDE eredetileg egy eléggé nagy hack-projekt: a PCManFM fájlkezelőn kívül minden kódot úgy vettek át valahonnan és átírták egy kicsit. Aztán most beütött a nagy hal - kis hal probléma, amely azt jelenti hogy egyszerűen nincs elég erőforrás arra, hogy saját függvénykönyvtárakat fejlesszenek és párhuzamosan tartsák a lépést a Gnome (és a KDE, de inkább az előbbi, lévén mindkettő GTK+) fejlesztéseivel.

A felhasználók transzparens hálózati meghajtó csatolást szeretnének. Meg automatikus hordozható meghajtó felcsatolást. Meg integrációt. Ez természetes. Ahhoz, hogy mindez valamennyire egységesen zajlódjon, létrejött a Freedesktop.org közösség, amely szabványokat ad ki ennek érdekében, és ez alapvetően jó. Ez a közösség fejlesztőkből verbuválódott, és az általuk meghatározottak ugyan nem hivatalos sztenderdek, de a Gnome, KDE és XFCE ezeket használja, ami azt jelenti, hogy ha egy alkalmazás-fejlesztő azt szeretné, hogy az alkalmazása működjön a nagy desktop environmentek alatt, akkor neki is illeszkednie kell ezekhez. Ebből következik, hogy a nem annyira nagy desktop environmenteknek is automatikusan illeszkedniük kell, különben megfelelően működő alkalmazások nélkül maradnak, és egy DE alkalmazások nélkül üres héj. Magyarul mégis mindenki úgy táncol, ahogyan a Freedesktop.org fütyül.

A Freedesktop.org szabályozza, hogy hogyan működjön az ablakkezelő, hogyan kell meghatározni egy fájl típusát, mi legyen az ikonok szabványos neve, hogyan épüljön fel a "start menü", az egyes alkalmazások hogyan cseréljenek adatot stb.

A probléma leginkább a szabályozás módjával van: mindez a munka egyetlen levelezési listán zajlik. Ha van valakinek egy ötlete, ír belőle egy specifikációt és bedobja a közösbe. Ha elég jónevű az illető, akkor fel is figyelnek rá a többiek és megvitatják. Ha nincs túl sok ellenvetés, akkor előbb-utóbb bekerül a freedesktop.org wikijébe; és lényegében ezzel már sztenderddé is vált. Ha később valakinek még jobb ötlete támad és módosítaná a specifikációt, bedobhat egy patchet a levelezőlistára, azonban ha az eredeti létrehozónak nem tetszik az ötlet, akkor semmi sem lesz belőle - magyarul azon az egy emberen múlik egy sztenderd sorsa! Abba nem is megyek bele, hogy mi van, ha a spec gazda eltűnik... Természetesen az is probléma, ha az adott sztenderdet senki sem implementálja, mert akkor nem sok értelme van az egésznek.

Talán nem meglepő, hogy a Freedesktop.org tagjai elsősorban Gnome és KDE fejlesztők, akik kitalálják hogy ezt vagy azt hogyan tudnák ők jól lekódolni, és ebből szabvány lesz. Más DE-kre általában fütyülnek; emiatt aztán a két nagy (szintén nem meglepő módon) jól követi a szabványokat, az XFCE kétségbeesetten fejleszt hogy nagyon le ne maradjon, a többiek meg...leves. A specifikációk jó része olyan, hogy nem lehet gyorsra és egyszerűre megvalósítani, tehát aki követi ezeket, az általa fejlesztett desktop lassú és bonyolult lesz.

Az utóbbi időben a Gnome kezd leginkább uralkodni a Freedesktop közösségben: Rádumálták a KDE fejlesztőket a Policykit és Consolekit használatára, kidobatták a DCOP-t a dbus kedvéért és most dolgozzák őket, hogy a GIO/GVFS használata mennyivel jobb lenne a KDE-ben. A farok kezdi csóválni a kutyát: amit kifejlesztenek a Gnome fejlesztők, abból igyekeznek gyorsan szabványt faragni.

Egy könnyedebb grafikus környezetnek nincs szüksége ennyiféle szabványra, elég lenne megvalósítani a legfontosabbakat, és inkább meghagyni gyorsnak és egyszerűnek. Ez lehetetlen, ha a legújabb Gnome/GTK+ vagy KDE programokkal szeretnének egyáltalán együttműködni. Amelyek az előző verzióikkal sem kompatíbilisek többé... :-(

Félreértés ne essék: a nagy DE-k általában jó dolgokat csinálnak, és haladni kell a korral, de igazán figyelembe vehetnék azokat a fejlesztőket és felhasználókat, akik nem csúcshardverrel nyomják. De a Freedesktop.org eddigi tevékenysége odáig vezetett, hogy az LXDE-sek a pagert és a tasklistet épp írják át libwnck alá, és a pcmanfm-et teljesen újraírják GIO/GVFS támogatással, a saját network managerüket kidobják és az nm-appletet használják stb. A végén egy jól használható, kicsi DE-ből lesz egy nagy és lassú, ami sokkal kevesebbet tud a Gnome-nál. Ezzel elvesztik a felhasználói bázisukat...

Az LXDE fő fejlesztője a megoldást abban látja, hogy minél több fejlesztő iratkozzon fel az xdg levlistára, és próbálja saját véleményével befolyásolni a döntéseket.

Én szkeptikus vagyok. Szerintetek?