Kinyírja a Mozilla a 64 bites windowsos Firefox buildeket?

Mozilla

A Mozilla részéről Benjamin Smedberg múlt pénteken egy üzenetet küldött a mozilla.dev.planning csoportba, amelyben arról írt, hogy a 64 bites windowsos Firefox buildek sorozatos félreértések és frusztrációk forrásai. Ennek az okai - egyebek mellett - a következők:

  • számos plugin nem érhető el a 64 bites verziókban
  • a pluginek, amelyek elérhetők, nem működnek megfelelően a Firefoxban, mert a fejlesztők nem implementáltak néhány dolgot (pl. windowproc hooking), így a "fagyások" sokkal gyakoriabbak
  • a 64 bites felhasználók által beküldött crash report-ok nem kapnak a fejlesztőknél magas prioritást
    • ez frusztrálja a felhasználókat
    • és frusztrálja a stabilitásért felelős fejlesztői csapatot is

A felsoroltak miatt Smedberg azt javasolta, hogy egyelőre(?) állítsák le a 64 bites, windowsos Firefox nightly build-ek készítését és a win64 nightly felhasználókat tereljék vissza a win32 vonalra.

Szerdán Smedberg közölte, hogy úgy döntött, leállítja a win64 hourly és nightly buildjeit.

További részletek itt.

( Troppauer | 2012. 11. 22., cs – 21:29 )

A Google-tol jott 300 milla $ csak a faszbukos fejlesztesre eleg...... gratula.
Talan kellene dobni a plugin-fejlesztoknek is.

( uid_4263 v | 2012. 11. 22., cs – 22:45 )

Nagyobb a füst, mint a láng.

1) gyakorlati haszna nincs a 64 bites buildnek (aki nem ért egyet, mondja nyugodtan az érveit, de ne azt hogy gyorsabb, meg hogy az a jövő (jelen), igazi infókat várok, például számokkal illusztrálva).
2) ha csak nyűg karbantartani, akkor értelmesebbre lehet fordítani a felszabadult energiát
3) majd ha eljutunk szépen lassan oda, hogy minden 64 bites lesz (például a következő Windows csak 64 biten lesz elérhető, a számítógépek nagy részén pedig ez a Windows vagy valamely utána következő fut majd) akkor megkapjuk a 64 bites buildet, és a 32 bites lesz a nyűg

--
http://neurogadget.com/

szálanként. Mint tudjuk egy böngésző sok tab és sok program - ha valamelyik tab több memóriát igényel 4 GB-nál, ( pölö valaki véletlenül egy nagy de legalább dinamikusan generálódó képet akar letöltetni, vagy ajaxon keresztül, vagy skydrive-val küldik neki a sok nul-t ), akkor legyen neki, igen.

Igen. Nekem például most eszik 800 MB-ot 220 tabbal. Néha felmegy 4-5 GB-ra is. És nem, nem vagyok őrült. Így sokkal egyszerűbb a weboldalakat böngésznem, nem kell állandóan keresgélnem, hogy a címeket, nem vesződök a kedvencekkel, a folyamatban lévő munkák weboldalainak címeit nem kell egy külön fájlba felírnom és minden bekapcsoláskor egyesével behívnom. Ha valakinek nem világos, akkor írok konkrétabb példát is.

Na szóval, ez a tab-os téma egy lehetöség, amit lehet használni, nyilván, azért van. Sosem értettem, hogy miért különc az, aki használja. Hol van az definiálva pl. hogy x számú megnyitott tabnál nem lehet több?
A felhasználói szokások eltéröek nýilván, parallel a különbözö felhasználókkal. Nincs ebben semmi különös. Aki nem így gondolja, az "rasszista" :)

--
robyboy

"Gondolkozni nehéz, ezért legtöbben ítélnek." - Márai Sándor

Én nagyon örülök, hogy a firefox egy ideje nem tölti be az összes tabot, csak azokat, amiket éppen olvasok.

Egyébként jelenleg kb. 1200 tab van nyitva, tab groupokba rendezve téma szerint.

Nekem kényelmesebb ez, mint könyvjelzőkkel szórakozni.

Ha viszont elkezdem csak úgy nézegetni a tabokat, mert mondjuk valami érdekes olvasnivalót keresek a félretettek között, vagy ilyesmi, akkor a memóriafoglalás megy felfelé. Sokat.

Örülnék, ha a gépben levő összes memóriát tudná használni (ha más nem használja már, ugye), illetve ha az összes processzort is tudná, mert pl. a tab groupok megnyitásakor az egyik core pörög 100%-on, a másik három meg alszik.

Nezzuk inkabb ugy, hogy miert ne?
En nyitogatom a tabokat amikor ugy van kedvem, s amikor ugy 500-600 kozott van akkor amint van idom/kedvem lecsukok vagy 100-200-at. Ami meg mindig erdekel azt bookmarkolom, a tobbit meg nem. Egy halom erdekes oldalt latok, de a tobbsege par napra ra mar annyira nem erdekes, ugyhogy kar lenne egybol bookmarkolni.

Van ugy, hogy keresek valamit google-ben, s felnyitok akar 50-60 tabot is, mire megvilagosulok nagyjabol. :)
Par masodperc alatt elindul a Firefox-om (csak akkor tolti be a tab-okat ha aktivalom oket), amig ez igy marad addig nem latom miert kellene 10-15-re korlatoznom magam...

Nem egészen vili
Amikor elindul, hogyhogy nem egy tabbal indul? El lehet valahol menteni, hogy honnan legyenek a tabok?
Amikor bezárom, be szokott zárni mindent, és nulláról indul.
Amikor megnyílik a sok tab, akkor nem tölti be mindet, de ha valamit egyszer megnyitsz, akkor a memóriában marad újraindításig?
Hogy megy ez?

---
Ubuntu one tárhely: https://one.ubuntu.com/referrals/referee/1503/
Dropbox: http://db.tt/XMk0ssk

"Amikor bezárom, be szokott zárni mindent, és nulláról indul."

Igen, de ha nem rendesen lépsz ki, hanem valahogy eléred hogy a böngésző valami hibán elszálljon, akkor a következő indításnál megnyitja újra az előzőleg nyitva lévő tabokat "Munkamenet helyreállítása" címen. =)

:-)

Egyebkent nem, itt a Firefox vs Seamonkey kulonbsegrol van szo, eros tippem van, hogy hnsz2002 -nel default nincs engedelyezve a menu bar, igy neki nincs Ugras menuje. A Firefox gomb alatt meg kicsit maskepp neznek ki a dolgok.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Én viszont attól vagyok kiakadva, hogy régen volt egy kezdőképernyő, hogy mit akarok helyreállítani. Most, ha akármi miatt leölöm a Firefoxot (pl. megbuggyant Flash plugin), akkor kérdezés nélkül elkezdi megnyitogatni újra a lapokat.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Használatban levő régi gépek.

- régi gép, nincs benne 64 bites CPU -> nem fut a 64 bites alkalmazás
- régi gép, kevés benne a memória -> a 32 bites alkalmazásoknak kisebb a memória footprint-je
- régi gép, nincs benne nagy tárterület -> a 32 bites rendszerek kevesebb merevlemezterületet igényelnek

Windows buildekről van szó. OS X és Linux buildeket ez a táma nem érinti.

2012 októberében a Windows XP (amiből csak az elvetemültek használtak 64 bitest) piaci részesedése még mindig több mint 20%.

--
trey @ gépház

Igen, vannak régi gépek. De szerintem nem az a helyzet a helyes kezelése, hogy az újabb technológiát teljesen dobjuk a lassan kiöregedő régi hw-sw kedvéért.
Például lehetne megcélozni egy valamikori következő verziót, amire adnának 2-3 év longterm supportot, és az lenne az utolsó hivatalos 32 bites főverzió. De nem ezt választották, inkább dobják a 64 bitest. Érthetetlen.

mi szükség van 32 bites buildre akármiböl is?

Kevesebb RAM-ot eszik, és gyorsabban fut a 32-bitesre fordított kód. Ha a programnak soha nincs szüksége 4GB-nál több memóriára, akkor ez fölösleges pazarlás - pl. egy /bin/cat-nak ugyan mi a véres reteknek kellene 64-bitesnek lennie?

Ha egy CPU natív módja a long mode, akkor miért is felesleges? Ugyanis az x64 architektúrában bizony a long mode a normális üzemmódja a CPU-nak.
Persze, emuláljuk csak a 32 bitet a sok gagyi alkalmazás miatt, akik nem tudják, hogy int helyett léteznek jó régóta uint32_t és hasonló adattípusok. Programozói hanyagság, hogy akkor is 64 bitet használjon memóriafoglalásnak, ha tudja, hogy neki az uint32_t is elég. Az int mérete szabvány szerint gépfüggő, de ezt a sok programozó számára nehéz megértenie, nekik int = 32 bit volt és marad is mindörökre. Az egy dolog, hogy Java platformon ez valóban így van minden esetben, de C-ben nem.
Persze így aztán ne csodálkozzunk, hogy egyes alkalmazások nem fordulnak le 64 biten, vagy ha igen, nem működnek, mert aktívan kihasználják a beépített, architektúra-függő adattípus-méreteket.

A 32-bitet nem a "gagyi" alkalmazások miatt emuláljuk, hanem azért, mert az alkalmazások egy számottevő része binárisban terjed, és vagy lehetőség vagy igény nincs az újrafordításukra (jellemzően az igény a felhasználónál keletkezik, de neki nincs forrása hozzá). Innentől kezdve nem opció az, hogy a régi alkalmazásokat dobjuk ki, ill. lehet ilyen opcióval indítani, de a felhasználók jó része akkor inkább megy máshova.
Ráadásul olyannyi erős ez az igény a meglevő alkalmazások futtatására, hogy az sem opció, hogy majd jól lerontjuk a 32-bites teljesítményét az új cpu-knak, és akkor majd a saját kárukon tanulják meg a köcsög felhasználók, hogy a tudomány haladásának szelével szemben nem pisálhatnak. Mert sajnos piaci verseny van, és a köcsög felhasználó akkor megveszi azt a cpu-t, azt a platformot, ahol nem szopatják.
Ennek eredménye az, hogy hiába natív 64-bites a cpu, mégis jó teljesítménnyel hajtja végre a 32-bites kódot is. Így viszont a 64-bites kód hátrányai sajnos nem mindig törpülnek el, és emiatt előfordulhat, hogy az adott program gyorsabban fut, és nem utolsó sorban kisebb helyet foglal a diszken, ha 32-bites. Egyetlen hátrány van: nem tud 4GB-nál több memóriát megcímezni. De ez a programok döntő többségét eddig se zavarta.

Na várjunk csak. Eredetileg azzal jöttél, hogy a 64 bit nem kell, sőt, sok alkalmazás feleslegesen 64 bites. Erre írtam, hogy ezek az alkalmazások akkor is tudnának 32 bites változókat használni, csak jól kell megírni őket.
Most azt mondod, csak a legacy alkalmazások miatt van szükség a 32-bitre, olyan alkalmazásoknál, amiket nem is lehet újrafordítani.
Ez így két teljesen külön téma, ne terelj.

El sem olvasod, amit írok? Akkor minek írsz?

Eredetileg azzal jöttél, hogy a 64 bit nem kell, sőt, sok alkalmazás feleslegesen 64 bites. Erre írtam, hogy ezek az alkalmazások akkor is tudnának 32 bites változókat használni, csak jól kell megírni őket.

Nem tudnának 32-bites pointer változókat használni, bármennyire is "jól" akarják őket megírni.

Most azt mondod, csak a legacy alkalmazások miatt van szükség a 32-bitre, olyan alkalmazásoknál, amiket nem is lehet újrafordítani.

Olvasd el mégegyszer, mert nem ezt írtam. Szóljál, ha megértetted.

A kérdés úgy hangzott, hogy "mi szükség van a 32-bites buildre". Az indokaid akkor lennének indokok, ha _minden_ elképzelhető programra igaz lenne, hogy nem lassabb 64-biten. Ezt gondolom nem szükséges tovább ragozni, hiszen Te magad is tudnál ellenpéldát gyártani a saját indoklásod ellenében.

Valójában egy kirakó sok darabja közül az egyik, amely jelenleg nagyonis fontos.

10+ év ASLR után az open source zászlóshajójának számító Firefox még mindig nem képes rendesen kihasználni (se más proaktív biztonsági megoldást alkalmazni) és egyedül a Microsoftnak van production verziója 64 bites böngészőből, úgyhogy a következő IE fikkantásnál figyelembe lehetne majd ezt is venni...

Ebben így igazad is van. De vajon miért van az, hogy OSX-en és linuxon a legtöbb böngésző (és amúgy minden program ) 64 bites. És ha ránézek a tasklistre OSX alatt, akkor a Skype-ot leszámítva full 64 bit minden, van full 64 bites ubuntu is, csak a Windows esetében mondja mindenki azt, hogy jó a 32 bit. Az az 1 process: 4 (valójában 2) GB-os korlát nincs már olyan távol, jelenleg egy grafikai program simán belefut, egy-két év, és a böngésző is ehet annyit.

Ha minden más platformon olyan sürgős a full 64 bit környezet, akkor miért pont Windows alatt nem fontos... Nem értem.

--
"Never trust a computer you can't lift."

( tr3w v | 2012. 11. 23., p – 00:32 )

Logikus lépés, mert ha leállítják a hourly és nightly buildeket, akkor ugye senki nem fogja tesztelni a 64 bites verziót, ami nyilván azt vonja maga után, hogy a büdös életben nem is lesz 64 bites kiadás...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

( M0Rph3U5 | 2012. 11. 23., p – 01:06 )

4 GB RAM felett lenne igazán értelme a firefoxnak, mivel van elég RAM, hogy ne lassítson... pedig még terveztem, hogy chrome-ról visszatérek rá... ezek után felejtős. (több, mint 100 gépes környezetben). amúgy is bejelentették hivatalosan, hogy csak otthoni felhasználásra javasolják, nem pedig munkahelyre. Egyre szánalmasabb amit csinálnak ezzel az amúgy ígéretes böngészővel. :(

Tudod van olyan, akinek a munkájához kell az internet, kell a böngésző (és nem arckönyvmarketingesekre gondolok).
Be is szopnám rendesen, ha nem tudnám böngészni mondjuk a sciencedirectet...

----------------------------------------------------------
"One should strive to achieve; not sit in bitter regret."
www.xonotic.org

Ja bocs, nem fejtettem ki. Nem tudom konkrétan, hogy mi lehet a pontos oka, hogy Firefox-ék nem javasolják a terméküket munkahelyi környezetbe (már ha ez tényleg így van). Tudtommal semmilyen szoftver sem tartalmaz gyártói garanciát semmire, ergo, a felhasználóé a felelösség még akkor is, ha adott szoftver hibája teszem fel leformázza a merevlemezt.

Na szóval, azt nem értem, hogy mi a különbség ezen a ponton IE, Firefox, és pl. Chrome között. Mindegyik lehet (és az is) problémás.

Szóval egyszerüen nem értem, hogy ez számít-e egyáltalán (mármint az ajánlás munkahelyi környezetbe)?

--
robyboy

"Gondolkozni nehéz, ezért legtöbben ítélnek." - Márai Sándor

( budee | 2012. 11. 23., p – 10:28 )

Umm, lehet en nem ertek valamit, de gentoo-m van, forrasbol forditott firefoxxal, es sose volt vele semilyen gondom: 


bud@delta ~ $ file --dereference `which firefox`
/usr/bin/firefox: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped

Minden plugin mukodik, es nincsenek fagyasok, nem vagyok frusztralt, teljesen elegedett vagyok. Velem van baj?

( manfreed (nem ellenőrzött) | 2012. 11. 23., p – 22:26 )

"számos plugin nem érhető el a 64 bites verziókban"

Azért szeretném tudni, hogy itt mire gondolnak. Flash oké, Java muszájból oké, és...
Szóval mi az a számos plugin? Valahogy a fenti kettőn túl nem érzem a szükségét másnak...

Silverlight, oké, ez egy kosárba a flash-sel.
PDF reader: FF és Chrome is tud pdf-et nézni (ha jól tudom), miért is kellenek akkor?

A media player beépülőkkel ugyanez a helyzet, a böngészők valamilyen szinten tudnak maguktól lejátszani videókat, emellett - bár lehet hogy csak én használom rosszul a netet - nem igazán láttam olyan weboldalt, ahol szükség lenne rájuk. Flash, vagy natív html5 megy mindenhol. Egy dologra jó: Ha le akarok tölteni egy filmet (nem kérem külön save as) akkor nem tudom, mert inkább megnyílik a böngészőben.

Szóval oké, vannak, ezeket nagyjából tudtam is, de a létezésük lényege nem jön át. (Ebank az érdekelne, vajon mit kell tudnia amihez egy tényleges plugin kell (nem elég mondjuk egy extension)

( Hunger | 2012. 11. 25., v – 10:24 )

Szerdán Smedberg közölte, hogy úgy döntött, leállítja a win64 hourly és nightly buildjeit.

Ekkora nyomorék döntést. Úgy tűnik Mozilla már teljesen az idióták gyülekezetévé vált...

( uid_16313 | 2012. 11. 25., v – 10:35 )

Érdekes, mert a jövő egyértelműen a 64 bites világról szól.
Hosszú távon könnyen megbosszúlhatja magát ez a stratégia.

--
robyboy

"Gondolkozni nehéz, ezért legtöbben ítélnek." - Márai Sándor

( hrgy84 | 2012. 11. 27., k – 03:58 )

a 64 bites felhasználók által beküldött crash report-ok nem kapnak a fejlesztőknél magas prioritást

Es ez kinek a sara, keziccsokolom? Talan csak nem a project managereke? Kisse vedhetetlen ez az erveles.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal