Az általam leggyakrabban használt Firefox verziója:

 ( Botond | 2012. február 6., hétfő - 13:14 )
10.x
68% (366 szavazat)
9.x
11% (61 szavazat)
8.x
1% (6 szavazat)
7.x
1% (5 szavazat)
6.x
0% (0 szavazat)
5.x
0% (1 szavazat)
4.x
0% (2 szavazat)
3.x
8% (44 szavazat)
egyéb
10% (56 szavazat)
Összes szavazat: 541

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Seamonkey 2.7 játszik (motor: Gecko/20120129 Firefox/10.0) ?

Szintén, bár én már 2.8 beta1-et használok.

--
A főnököm mindig megtartja amit ígér, ha pénzt ígér azt is!

+1

A másik amit használok az a nagy betűs BÖNGÉSZŐ: Opera 11.61.

Az a háromkarakteres :-D

Gecko/20120201 Iceweasel/3.5.16... :)

Mától pedig ezt használom: Firefox/Aurora 12.0a2(2012-02-08), motor:Gecko/20120208 Firefox/12.0a.

Sokkal gyorsabb, mint eddig bármelyik browser és a memóriafelhasználása is optimalizált(értd. sok megnyitott lappal tart most 230 Mb-nál, ugyenezekkel a lapokkal a régebbi geckos böngészők 380-690 Mb-ot is elfüstöltek, egyedül a webkites Midori volt alatta, de az meg fapados).

Egyéb: nem gyakran használok Firefoxot.
(De amikor igen, akkor most épp valami 5-öst. Ahogy nézem, eléggé le vagyok maradva).

[irónia]Egyéb: passz, nem tudom követni, hogy éppen melyik verziónál a Firefoxom :)[/irónia]

:)
Súgó > Firefox névjegye

_________
warp

hehe, +1

--
NetBSD - Simplicity is prerequisite for reliability

+0.5

nem irónia, most egyedül azért tudom, hogy 6, mert kivételesen stable debian alól írok.

SZERK: nem vettem észre, hogy ez chromium :D

És őszintén szólva nem is érdekel, amióta "marketing" okok miatt feláldozták az egyik nagy marketing fegyverüket (termékciklusokban és termékben gondolkodtak és nem egy folyamatosan változó izében).

----------------
Lvl86 Troll

Pluszsok, en sem tudom kovetni, bar altalaban mindig a legujabb van fent, ha van idom frissiteni.

Amióta ilyen erőszakos a ff update eljárása, szerencsére mindenki frisset használ.

Sajnos nem.

http://flic.kr/p/bpuno2

(ebben benne van mindenki, a szavazásban csak a regisztráltak)

--
trey @ gépház

- az "Adblock"-osok. De egyébként tényleg "hasznos felmérés".

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

Mi a tipped, mennyi Adblockos van? Csak hogy mennyit adjak hosszá a HUP napi ~ 15-20K uniq látogatójához amit ez mér.

--
trey @ gépház

Nem tudom. Az igazság az, hogy nekem is van adblock, de a hup-on ki van kapcsolva. Akiket ismerek, és firefoxot (és chrome/chromium-ot) használ mindenkinek javasolom, (és ha kéri fel is rakom) az adblock-ot.

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

13.0a1 (Arch), semmi gond vele.

Ha minden férfi egyforma, akkor miért válogatnak annyit a nők???

Ez azt jelenti, hogy ha valaki 2-3 napja frissitett, akkor a letolteseinek nagyobb resze 9-nek, kisebb resze 10-nek latszik. (pl. en is 10-re nyomtam, de par napja meg 9.x volt)

--
In 2000 years time, historians studying the national census will think we murdered all the Jedi.

Valóba', ördög bújt a trójai falóba. Elfelejtettem, hogy most jött ki a 10 a napokban. Akko' itt a csak tegnapi:

http://flic.kr/p/bpv2ct

--
trey @ gépház

Igy rogton veri a 10.x a 9.x-et.. koszi a patch-et.

--
In 2000 years time, historians studying the national census will think we murdered all the Jedi.

Ha tudtam volna, hogy neked ilyened van, akkor el sem indítom a szavazást.
Talán annyi értelme mégis volt, hogy megtudtuk, hogy a régebbi tűzrókát használók "szégyenlősebbek".

Amit a gentoo hoz a stabil ágon. Momentán 9.0 de egyébként itt van.:
http://packages.gentoo.org/package/www-client/firefox

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

10.x már vagy 3 napja. XD

Ezek szerint nem a legfrissebb az oldal? :) Vagy toljak egy emerge --sync majd -uND world-ot. MIndegy. Az oldal szerint még 9 :)

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

11.0

(pontosabban: 11.0~b1+build1-0ubuntu1 az Ubuntu precise-ben)

12a már elég régen, és nincs bajom vele. (ez engem is meglepett :D )

Szintén 11.0, de oneiricon, a launchpadról.

deb http://ppa.launchpad.net/mozillateam/firefox-next/ubuntu oneiric main

Valóban, az erőszakos update miatt én is mindig a legfrissebbet használom, de tervben van az ESR, erre közel 200 gépet kell majd átállítanunk

Egyéb: éppen aktuális béta

Fogalmam nincs, ami éppen a disztribúcióban frissnek számít. :)

Ellenben kíváncsi vagyok, hogy mikor jön valami értelmesebb verziószámozás, mivel a konkurenciát beérte a Firefox, ha most továbbra is így tolják, akkor követhetetlen szám lesz a verizó, a plugin-kompatibilitás kiderítése pedig agyrém.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

ha most továbbra is így tolják, akkor követhetetlen szám lesz a verizó, a plugin-kompatibilitás kiderítése pedig agyrém.

Mit akarsz azon kideriteni?

http://www.mozilla.org/en-US/firefox/10.0/releasenotes/#whatsnew
--
HUP Firefox extension

Az, hogy ha tolnak valamit az API-n, ami visszafelé nem kompatibilis, akkor az nem jelenik meg a verziózásban, mint major változás.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Ezekrol a valtozasokrol honapokkal a release elott tudnak a fejlesztok, amelett gyakran hasznalt API-kat nem valtoztatnak.
--
HUP Firefox extension

Ahja... én már csak ilyen ókonzervatív verzióbuzi vagyok, szeretem a verzióból kikövetkeztetni azt, hogy az adott szoftverben volt-e major vagy minor változás... ugyanis a verziószám alapvetően erre való, nem marketing okokból találták ki. Illetve ha marketing okokból bevezetnek egy könnyebben érthető és megjegyezhető verziószámozást, attól még megtartják belül a technikai verziózást, hogy a jövő ismerete nélkül tervezhető és implementálható legyen egy stabil működési tartomány...

Igazán kíváncsi vagyok, hogy a moduloddal hogyan tudsz előre egy stabil működési tartományt definiálni a jelenlegi verziózás mellett... mert az, hogy hónapokkal előre szólnak a _fejlesztők_ (sic!), az nem egy előre implementálható stabil működési tartomány...
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Ezek közül egyik se magyarázat arra, hogy miért nincs belső technikai verziózás, és továbbra se lehet előre megmondani, hogy melyik verziótól nem lesz kompatibilis egy API.

Tudod-e _most_ implementálni egy modulban azt a forráskódrészletet verziószám tartománnyal, amelyik jelezni tudja a verziószámból _előre_ az inkompatibilitást, azzal együtt, hogy előre nem ismert időpontban valamelyik _elkövetkező_ Firefox-ban változtatnak az API-n?
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Erről már volt szó, úgy tudom, hogy igyekeznek megtartani a kompatibilitást, ráadásul monitorozhatod fejlesztőként az api változásokat jóval azelőtt, hogy kijöjjön egy új verzió, és megteheted a szükséges változtatásokat

Én ezt mond értem, de ezek mind-mind manuális és időrabló tevékenységek, az okosan használt verziószám viszont automatikus eszköz, pláne egy böngészőben lehet több alrendszer is külön-külön verziózva, a bundle verzió pedig megmaradhatna marketingeszköznek. Például van egy JBoss alkalmazásszerver, nevezzük JBoss7 néven, benne a moduloknak (Web, WebService, EJB, JPA, Messaging, stb.) külön verziói vannak, egészen változatos tartományban, így el lehet dönteni akár automatikusan is, hogy egy alkalmazás képes-e futni az adott szerveren vagy sem.

A Mozilla teljesen alárendelte a marketing szempontjainak a verziózását, amiből probléma volt a 3.x - 4.x váltásnál és probléma lesz a legközelebbi nem kompatibilis API változtatásnál.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Nem onnan allapitjuk meg, hogy tamogatva van-e valami vagy nem, hogy megnezzuk a bongeszo verzioszamat, hanem ranezunk, hogy letezik-e a feature.
Ha esetlegesen valaminek megvaltozna az API-ja, az uj namespace ala kerul emlekeim szerint - de lehet, hogy tevedek.
--
HUP Firefox extension

Hm... én továbbra is azt látom, hogy a Mozilla management sikeresen eliminálta a technikai verziószámok adta előnyöket, majd a keletkező problémákra mindenféle workaround megoldásokat és humán workflow lépéseket vezettek be, amelyekre nem lett volna szükség, ha bevezettek volna a technikai verziózás mellé egy marketing célú verziójelölést, mint ahogy azt IT világ okosabbik részén tették. Ennek a technikai verziózásnak egyébként semmi köze a fix release ciklushoz...
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

nem tagadom, hogy marketing okai (is) voltak a váltásnak, de talán jobban járunk vele mi webfejlesztők.

Ha fejlődnek a böngészők, és frissülnek folyamatosan talán nem fognak a felhasználók a verzióval foglalkozni. A chrome-nak pl egyáltalán nincs verizója. Legalábbis senkinek nem köti a chrome az orrára, hogy ő most a 14, vagy melyik. Persze az about-ban ott van, de pont az lenne ennek a rendszernek a lényege, hogy ne legyen verzió, ne lehessen ragaszkodni egy adott kiadáshoz, alap legyen a legújabb, és működjön minden ami eddig ment amellett, hogy működjön minden, ami később fog elkészülni. Lehet, hogy az FF nem jól csinálja, mert megmondja, hogy hányas verziónál tart, és nem csendben frissít, de az, hogy nincs kis és nagy kiadás az jó. Régen amikor volt, az emberek nem frissítettek IE6-ról 7-re, mert zavarta őket a lapsáv, ami új volt és szokatlan nekik. Amikor kijött a Firefox 3, nem frissítettek emberek, mert zavarta őket az előzmények lista megváltozása a címsávban. Arra kell törekedni, hogy a változások folyamatosak, egyenletesek, és apránként jöjjenek.

És hogy ez miért jó? Mert - bár a firefox már gyors kiadásokban tolja, sokan megakadtak a 3-as verziónál, ezért webfejlesztőként foglalkoznom kell külön velük.

És ha már az apit nézzük: a html, és a js a legjobb bizonyíték arra, hogy létezik olyan api, amit ha jól használnak, akkor azért fog működni jó sok kiadással később is. Talán nem a legjobb példa figyelembe véve a sok IE-re optimalizált, nem szabványkövető weblapot, és azt, hogy egy romhalmaz, amit próbálnak foltozni, de lehet jól csinálni.

Idézet:
Ha fejlődnek a böngészők, és frissülnek folyamatosan talán nem fognak a felhasználók a verzióval foglalkozni. A chrome-nak pl egyáltalán nincs verizója. Legalábbis senkinek nem köti a chrome az orrára, hogy ő most a 14, vagy melyik. Persze az about-ban ott van, de pont az lenne ennek a rendszernek a lényege, hogy ne legyen verzió, ne lehessen ragaszkodni egy adott kiadáshoz, alap legyen a legújabb, és működjön minden ami eddig ment amellett, hogy működjön minden, ami később fog elkészülni.

Úgy látom nem ment át a jónéhány hozzászólásom lényege: ha alapjaiban változik egy API -- például már támogatja az SPDY protokoll használatát, akkor ez nem derül ki jelenleg a verziószámból. A verziózásnak kialakult egy kultúrája, egy jó implementáció az OSGi, erről egy jó leírás a http://www.osgi.org/blog/2009/12/versions.html oldalon olvasható, egy bővebb leírás a http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf letöltésével olvasható.

Ettől teljesen független a vizuális verziózás, adhatnak az egyes verzióknak bármilyen kódnevet, szöveget, képet, ikont, videót, szagot vagy zenét... de ettől még egy viszonylag rövid és egyszerű verziózás szükséges dolog, különben káosz lesz a kapcsolódó rendszereknél.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

"A verziózásnak kialakult egy kultúrája"

Ez csak egy formája a verziózásnak. És el lett itt milliószor magyarázva, hogy ez miért rossz egy böngészőnél.

"ha alapjaiban változik egy API -- például már támogatja az SPDY protokoll használatát"

Oké, hogy változik alapjaiban egy API egy új funkció bevezetésétől? Mert ezt leírtad, de írhatnál konkrét példát is ami tud változni, mert nem tudom elképzelni, hogy az SPDY támogatás hogy jön ide. Nyilván lesznek plusz függvények, metódusok, annyakinnya, de attól még nem szükségszerűen fog megváltozni az, ami már létezik. Szóval tényleg mondj olyan konkrét példát, mert lehet félni attól, hogy lesz ilyen, de a gyakorlatban meg az látszik, hogy a chrome-nál minimum verzió van csak, és nem okoz problémát az extensionok fejlesztése pedig ők is gyorsan verzióznak.

Idézet:
Ez csak egy formája a verziózásnak. És el lett itt milliószor magyarázva, hogy ez miért rossz egy böngészőnél.

Bocsánat, de miért is _rossz_ egy böngészőnél, ha egy plugin azt látja, hogy 3.9.7, a felhasználó meg azt látja, hogy "Firefox Szagosmüge edition 2014"?

Az SPDY egy példa volt. Mondhatok olyan példát is, hogy jogi viták miatt ki kell venni az XYZ szabvány támogatását. Hogy magyarázod el a plugin felhőnek, hogy ma még jó a Firefox 43, holnap már nem jó az új Firefox 44? Mert leghamarabb a telepítésnél, legkésőbb a futásnál egy szép kövér hanyatt esést produkál majd a böngésző vagy a plugin... persze lehet sok megoldást alkalmazni, a kényelmes és kitaposott út a belső technikai verziószámozás...
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Mint plugin fejlesztő (extension, nevezzük nevén, feltéve ha azokról beszélünk) te érdekelt vagy abban, hogy a munkád a későbbiekben működjön, ezért figyeled a megfelelő csatornákat. Ez a verziózási rendszertől független.

A firefoxnak van 3 kiadása. Egy kísérleti, egy béta, és egy éles. Az élest használják a felhasználók, a kísérletibe kerülnek be az új dolgok, a bétába meg lehet tesztelni. Tehát neked, mint fejlesztőnek két kiadás előnyöd van letesztelni a programodat, és felkészülni a változtatásokra. Már ha aktívan fejleszted az extensiont. Ha nem, akkor egyébként is le fog állni a működése, miután elérte a max verziót, amit belőttél neki.

A jogi kérdés rossz példa. Azt nem időzítheted a következő nagy kiadásra. Ha egy szabvány támogatását meg kell szüntetned, akkor gondolom kénytelen vagy kivenni függetlenül attól, hogy hol jársz a kiadási ciklusban, a következő verziótól. Akkor se tudsz semmit se tenni. Ráadásul a böngésző készítője sem. Ha kiadja következő egész számú verziót akkor az extension nem fog elindulni, mert beállítottad, hogy ott már ne menjen, vagy hibázik, de előfordulhat, hogy egyébként közel funkcionálisan működik.

De amúgy ez is egy erőltetett példa, ugye hogy nehéz egy életszerű példát hozni? Bármi ami eszembe jut az inkább hozzáad, vagy ne adj isten módosít a mostanin, de módosítani lehet úgy, hogy ne sértse a régit.

Régen egyébiránt mi volt? Extensionök tömegei nem működtek új ff kiadás után közvetlenül amíg az author nem frissítette az extensiont. Olyanok is, amik egyébként működtek volna, csak a max verziót kellett átírni.

Az, hogy miért rossz, ha a felhasználó más verziót lát mint a belső verziózás. Ilyet nem mondtam. Az a rossz, ha az emberek fő és al verziókban gondolkodnak, mert amíg így teszik, addig mindig lesz az az egy verzió, ami nagy változásokat hoz, félve lépik meg, lemaradnak a felhasználók annál a verzióvonalnál, és nekik külön supportot kell nyújtani.

Fel kellene oldalon az ellentmondásokat a hozzászólásodban. Van három nagy ellentmondás:
"érdekelt vagy abban, hogy a munkád a későbbiekben működjön, ezért figyeled a megfelelő csatornákat"
vs
"Extensionök tömegei nem működtek új ff kiadás után közvetlenül amíg az author nem frissítette az extensiont"

"Tehát neked, mint fejlesztőnek két kiadás előnyöd van letesztelni a programodat, és felkészülni a változtatásokra"
vs
"Ha egy szabvány támogatását meg kell szüntetned, akkor gondolom kénytelen vagy kivenni függetlenül attól, hogy hol jársz a kiadási ciklusban, a következő verziótól."

"Bármi ami eszembe jut az inkább hozzáad, vagy ne adj isten módosít a mostanin, de módosítani lehet úgy, hogy ne sértse a régit."
vs
"addig mindig lesz az az egy verzió, ami nagy változásokat hoz, félve lépik meg"

Nekem ebből ez jön le: tudod, hogy nem jó, de valamilyen rejtélyes okból próbálod védeni a rossz megoldást.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Idézet:
"érdekelt vagy abban, hogy a munkád a későbbiekben működjön, ezért figyeled a megfelelő csatornákat"
vs
"Extensionök tömegei nem működtek új ff kiadás után közvetlenül amíg az author nem frissítette az extensiont"

Ez nem ellentmondás, az egyik arról szól, hogy mit kéne tenni, a másik az, hogy milyen (volt) a gyakorlat. A komolyabb fejlesztők akkor is igyekeztek kiadásra készre tesztelni a plugint bizonyára.

Idézet:
"Tehát neked, mint fejlesztőnek két kiadás előnyöd van letesztelni a programodat, és felkészülni a változtatásokra"
vs
"Ha egy szabvány támogatását meg kell szüntetned, akkor gondolom kénytelen vagy kivenni függetlenül attól, hogy hol jársz a kiadási ciklusban, a következő verziótól."

Ez csak akkor ellentmondás, ha annak akarod érteni. Írtál egy rendkívüli helyzetet. Az esetek nagyrészében viszont egy változtatást nem kell hirtelen elintézni, végig tud futni a kiadási cikluson, és akkor van idő reagálni rá.

Idézet:
"Bármi ami eszembe jut az inkább hozzáad, vagy ne adj isten módosít a mostanin, de módosítani lehet úgy, hogy ne sértse a régit."
vs
"addig mindig lesz az az egy verzió, ami nagy változásokat hoz, félve lépik meg"

Ebben hol az ellentmondás? Én a felhasználókról beszéltem az utóbbi mondatban. Amikor nagy kiadások vannak, a felhasználók félve lépnek a következőre. Például amikor az FF3 kijött, sokan nem váltottak a kettesről.

Idézet:
Nekem ebből ez jön le: tudod, hogy nem jó, de valamilyen rejtélyes okból próbálod védeni a rossz megoldást.

Rosszul jött le :) Én nem gondolom, hogy rossz a mostani megoldás. Sőt, jobb mint a régebbi. Webfejlesztőként így értékelem. Felhasználók szempontjából is jobbnak tartom. Lehet, hogy a kiterjesztések fejlesztői részéről kicsit több odafigyelést igényel.

"A Mozilla teljesen alárendelte a marketing szempontjainak a verziózását"

És szerintem egy oriási nagy marketing fegyvert kiütöttek a kezükből egyúttal, ld. release party, mindenféle csudamarketing event ("tölsük le minél többen 24 óra alatt", stb.), ami véleményem szerint kicsit nagyobb hírverést csinált neki, mint egy "megjelent a firefox n+1. verziója" című rövid hír.

----------------
Lvl86 Troll

Egyéb: Mozilla Firefox-Trunk 13.0a1


=Λ=

/o\

egyéb
beta channel

Egyéb: FF csak tesztelési célra van fent, mindig a legfrissebb stabil verzió. Böngészésre nem használom.

+1

Inkabb Seamonkey-t hasznalok es akkor van a bongeszomben IRC es email kliensem is, ugy cakkunpack.

"cakkunpack"

atyauristen...

Ez mar majdnem olyan, mint az emblokk/unblock/amblok :)

--
In 2000 years time, historians studying the national census will think we murdered all the Jedi.

a vegen megjelenik erre is Gabunal egy sack und pack compilation az en bloc-os melle :D

Esetleg lehetett volna egy olyan, hogy "mindig az aktuálisan friss verzió"

50.2.
Meguntam, hogy állandóan frissítgetni kell, letöltöttem a forrást, átírtam kézzel, így most pár évig nyugi van.

:D :D

Pár év? Én legfeljebb néhány hónapot tippelnék. :D
----------
rohamkocka

A jelenlegi kiadási ütemtervvel 2016 szeptemberében az 50.0 meg is jelenhet.

Nem mintha bárki is nézné a verziószámokat vagy tudna ezekről, a böngésző automatikusan fog a háttérben frissülni.

Nightly

Szintén.

Csak akkor használom a nehézkes ff-ot, ha muszáj, inkább a chrome-ot használom.

Sokat javult az elmút 2-3 kiadás során

KAMI | 神
--
Támogatás | OxygenOffice | Fordításaim és SeaMonkey

Valóban, a 10 már nagyon jó.

Rohadjak meg, ha észreveszek bármilyen különbséget is a 8, a 9 vagy a 10 közt. Nekem egyikkel sincs bajom.

--
trey @ gépház

Biztos el vagy havazva, azért nem veszed észre :-D

LOL:D

+1
mivel soha nem futtattam a 3dmark browser-es megfelelőjét (így azt se tudom van-e ilyen valójában), fogalmam sincs mikor/hol/miben gyorsul (ha egyáltalán). Azért az elmondható h. valamivel mintha jobb lenne a sebessége mint a korábbiak, mondjuk 1 évvel ezelőtti. Persze ha sok a kép/flash akkor core2 duo ide vagy oda, megröccen... vagy a szkrollozáskor is. Úgy rémlik valamikor 1999 környékén még nem volt gond a smooth szkrollozással egy 1/10 teljesítményű CPU-val, és 1/10 teljesítményű VGA-val. A flash videók talán 2007/8 környékén kezdtek el akadni, azelőtt windóz XP-vel szintén core2 gép integrált intel VGA sosem szaggatott. Pedig ma már elvileg VGA-ból megy a desktop kompozisön! Így múlik el a világ dicsősége.

Nálam a 8-as elég jó volt, a 9.0.1, 10.0-ás viszont mintha falná a memóriát. Tudom, lehet valamelyik kiterjesztés. Úgy értem, azonos körülmények között az utóbbiak kehesebbek.


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

címsorba:

about:memory

lassuk az ördögöt

KAMI | 神
--
Támogatás | OxygenOffice | Fordításaim és SeaMonkey

Ami nem tetszik...

Resident set size-nál:

711.82 MB (93.05%) -- anonymous, outside brk() [rw-p]

Virtual size-nál:

5,517.34 MB (89.42%) -- anonymous, outside brk() [rw-p]

Az összes virtuális memóriafoglalás 6.17 GB, miközben a fizikai RAM 2 GB. Azt hogyan lehet kideríteni, hogy melyik extension-ben van memleak? Mondanom sem kell, a böngésző már kezd lassan reagálni. Az egyik gyanusítottam simán a Hupper.


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

Amikor már 8 GB fölött volt a virtuális memóriahasználat, valamennyit swap-elt is, akkor letiltottam a Hupper extension-t. Egy tábla csokiban mernék fogadni, hogy a Hupper extension a bűnös, abban van a memory leak.


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

A 10 nagyon-nagyon jó lett. Hihetetlenül stabil, egyszer nem fagyott, omlott és villámgyorsan rendereli az oldalakat.

Troll:
Ha csak egyszer nem fagyott, akkor hogy lehet stabil? :-)
Troll vége

Ritkán használom mostanában, mivel W8 IE-t használok, de ha kell akkor a legfrissebbet töltöm le...
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -> Kérjük a humoros aláírást itt elhelyezni. <- - -

Kimaradt a "Mindig a legfrissebbet" opció.