Mozilla staakt ontwikkeling 64bit-versie van Firefox

Mozilla heeft ontwikkelaars gevraagd om te stoppen met de ontwikkeling van de nightly builds van de 64bit-versie van Firefox. De browserversie zou tot te veel onduidelijkheid leiden, er zouden niet genoeg plug-ins voor zijn en bugs die crashes veroorzaken, zouden te lang blijven liggen.

Mozilla werkt al tijden aan een 64bit-versie van Firefox en het bedrijf beloofde dat de versie voor de 64bit-variant van Windows 'een andere snelheid en andere prestaties, maar dezelfde stabiliteit' moet bieden. De 64bit-browser kan meer geheugen adresseren op het besturingssysteem dan de 32bit-variant. Op Google Group mozilla.dev.planning heeft Mozilla's engineering manager Benjamin Smedberg echter in een thread genaamd 'Turning off win64 builds' het staken van de ontwikkeling aangekondigd.

Als redenen noemt hij dat veel plug-ins voor de 64bit-versie niet beschikbaar zijn of niet goed werken. Submits van gebruikers over crashes zouden te laat opgepikt worden, omdat de ontwikkelaars andere prioriteiten zouden hebben en gebruikers zouden daarom een 'tweederangsgevoel' krijgen. "Ik heb besloten om de 64bit-nightly en -hourly builds uit te schakelen", zegt de manager, ondanks vele verzoeken om de ontwikkeling door te laten gaan. "Laten we deze discussie als gesloten beschouwen." Ook op Bugzilla roept hij op de ontwikkeling te staken, constateerde The Next Web.

Mozilla heeft ondanks de lange ontwikkeltijd en diverse testversies nooit een officiële 64bit-versie van Firefox uitgebracht. Gebruikers van de 64bit-versie van Windows zullen zich nu tot Internet Explorer of Opera moeten wenden als ze een 64bit-browser willen gebruiken.

Reacties (195)

[TimeVortex]

Voor de goede orde, aangezien het artikel dat wat in het midden laat: het gaat hier dus alleen om de 64-bits-versie voor Windows! Voor OS X en Linux blijven de 64-bits-versies gewoon bestaan.

[Maurits van Baerle]

Inderdaad, ik verwacht zelfs dat Mozilla binnenkort zal melden dat ze de 32bits versie voor OS X staken.

Op een kleine groep gebruikers na draaien de meeste OS X gebruikers by default 64bits applicaties en zijn het OS en alle plugins gewoon 64bits. Aangezien de executables voor 32bit en 64bit in één bestand zitten (Fat binary) maakt het de binary onnodig groot.

Ze hebben net de ondersteuning voor OS X Leopard laten vallen in de laatste Firefox. Zodra het minimum OS de opvolger Snow Leopard wordt zal Firefox sowieso niet meer draaien op 32bits Macs en kunnen ze dus zonder problemen alleen nog maar een 64bits Firefox compileren.

Bovendien zijn de voordelen van de 64bit Firefox op OS X zo groot dat niemand vrijwillig de 32bit versie zal draaien. Dit is de reden waarom ze twee jaar geleden overgestapt zijn op 64bits:

Cold startup: x86_64 is ~26% faster
Warm startup: x86_64 is ~5% faster
MS Psychadelic Browsing Demo: x86_64 is ~540% faster
MS Speed Reading Demo: x86_64 is ~35% faster

Firefox 4 for Mac OS X: Under the Hood

[Reactie gewijzigd door Maurits van Baerle op 23 juli 2024 13:35]

[jGS]

Een slechte zaak dit, ooit komt er een tijd dat de 32 bit niet meer werkt en lopen ze achter ...

[CodeCaster]

Windows-applicaties gebouwd voor 16-bit zullen pas vanaf Windows 8 niet meer werken, 27 jaar na het uitbrengen van de 386, die 32-bit naar de consumentendesktop bracht. Edit: sterker nog, het werkt nog steeds.

64-bit is pas zo'n acht jaar aan z'n opmars bezig, terwijl 32-bits-CPU's en -Windowsversies nog steeds verkocht worden. Omdat het heel lastig is om twee versies naast elkaar te ontwikkelen en onderhouden, wordt er nu besloten om voorlopig alleen nog maar de 32-bits-versie te onderhouden. Dit zorgt voor meer inzetbare mankracht op één product.

Puur 64-bit ontwikkelen voor clientapplicaties zal over een jaar of vijf misschien gemeengoed zijn; voor nu is 32-bit nog afdoende. Het is niet echt een kwestie van voor- of achterlopen, maar meer van de compatibiliteit met de rest van de wereld. Als iedereen over is op 64-bit, kan alle beschikbare energie worden gestoken in het ontwikkelen van een versie specifiek voor dat platform.

Als afgezien daarvan de plugin-engine het enige probleem is, zouden ze het beste een 64-bit plugincontainer schrijven die met los draaiende 32-bits-plugins kan communiceren voor de compatibiliteit en de 64-bits-versie van de browser doorontwikkelen, maar de waarheid is waarschijnlijk iets gecompliceerder dan dat.

[Reactie gewijzigd door CodeCaster op 23 juli 2024 13:35]

[OkkE]

De redenering van Mozilla zelf:

Mozilla’s manager listed the following reasons as to why the nightly builds should get the axe:

• Many plugins are not available in 64-bit versions.
• The plugins that are available don’t work correctly in Firefox because we haven’t implemented things like windowproc hooking, which means that hangs are more common.
• Crashes submitted by 64-bit users are currently not high priority because we are working on other things.
• This is frustrating for users because they feel (and are!) second-class.
• t is also frustrating for stability team triage because crash-stats does not easily distinguish between 32-bit and 64-bit builds in the topcrash lists and other reports. We basically ignore a set of nightly “topcrashes” because they are 64-bit only. (See bug 811051).

Bron: http://thenextweb.com/app...d-50-of-testers-using-it/

[Reactie gewijzigd door OkkE op 23 juli 2024 13:35]

[CodeCaster]

Mjah, ik vind die argumenten wel zwak.

Plugins zijn niet beschikbaar als 64-bit, dus dan stoppen ze maar met de ontwikkeling van de versie die er hoe dan ook moet komen? Bouw dan een tussenoplossing of begin met een nieuwe pluginarchitectuur op basis van wat je de afgelopen jaren geleerd hebt: plugins out-of-process draaien, met inter-process communication (want, zoals Sander hieronder al zegt, kan een applicatie die op 64-bit draait geen 32-bit code uitvoeren, maar er wel mee communiceren).

De windowproc hooking-opmerking snap ik niet. Ik weet wat het is, maar weet niet wat er mis gaat. Maar alweer, aangezien 64-bit toch echt de toekomst is, lijkt het me handig dat ze de problemen die ze ermee hebben toch gaan oplossen.

Op de crashreportmelding heb ik geen commentaar behalve een facepalm; hoe moeilijk kan het zijn om een ander ID mee te geven aan de crashreports van 64-bits-versies?

Dat gezegd hebbende: ik lijk hiermee mijn bovenstaande post tegen te spreken, maar doe dat niet. Ik ben het eens met de beslissing ("We gaan nu al onze aandacht op één versie vestigen"), niet met de argumentatie.

[ppl]

Het plugins argument is een complete fabel. Voor Linux en OS X wordt er al tijden een 64 bit versie gebruikt, voor OS X is er zelfs geen 32 bit versie meer. De meeste plugins werken prima in de OS X versie, zonder gedoe, zonder crashes.

Ik denk dat het probleem eerder in de 64 bit Windows versie zit en de code gewoon van slechte kwaliteit is. Dat soort zaken wil men vaak niet toegeven omdat ze het als zwakte zien en bang zijn voor imagoverlies (uiteindelijk is juist die houding hetgeen je imago flink schaadt). Als je goed leest zie je ook dat ze gewoon toegeven dat de prioriteiten elders liggen. Dat kan zijn omdat ze niet genoeg resources hebben en dan maar prioriteiten moeten gaan stellen. Dat zit wel in de lijn die is ingezet met Thunderbird; daar is namelijk ook heel wat aan resources weggehaald en naar Firefox overgeplaatst. Het klinkt mij teveel als verdoezeling van organisatorische problemen.

[Verwijderd]

Ik denk dat het probleem eerder in de 64 bit Windows versie zit

Uit het artikel:

Op Google Group mozilla.dev.planning heeft Mozilla's engineering manager Benjamin Smedberg echter in een thread genaamd 'Turning off win64 builds' het staken van de ontwikkeling aangekondigd.

Het is inderdaad Windows.

Dat soort zaken wil men vaak niet toegeven

Uit het artikel:

Submits van gebruikers over crashes zouden te laat opgepikt worden, omdat de ontwikkelaars andere prioriteiten zouden hebben en gebruikers zouden daarom een 'tweederangsgevoel' krijgen.

Ze erkennen dat bugs niet de aandacht krijgen die ze nodig hebben. Dat de code niet op orde is, is juist een van de argumenten om ermee te stoppen.

[hostname]

Volgens mij werkten 16-bit applicaties ook al niet meer op de (veelgebruikte) 64-bit versie van Windows 7.

[Blokker_1999]

64bit windows versies bevatten geen NTVDM meer. het is deze virtuele dos machine die de mogelijkheid gaf om 16 bit applicaties te draaien.

[Loller1]

Jawel, en op Windows 8 64bit ook nog.

[kozue]

Hoeveel applicaties zijn er nog 16 bit dan?

[Dutch2007]

16 bits apps werken al niet meer vanaf Windows XP x64 (min of meer gewoon Windows Server 2003 x64), ook in Vista en Windows 7 x64 werkend 16 bits apps niet... (zoals van die oude .bat naar .exe geconverteerde programma's.

[Blazing-Studios]

inderdaad, het lijkt mij dat we over een tijdje alleen nog maar native 64bit apps gaan zien en over een paar jaar zullen de eerste 128bit apps ook wel gaan verschijnen (3D programma's en dergelijke zullen wel de eerste "consumenten" programmas worden die dit gebruiken).

Ik weet me nog een artikel te herinneren over microsoft en dat windows 8 misschien al 128 bits ondersteuning zou hebben.

[Mavamaarten]

Bronnen checken
http://msftkitchen.com/20...dows-9-a-big-fat-lie.html

[Nas T]

64 bit betekent dat je theoretisch ongeveer 18.500 TB aangeheugen kunt adresseren. 192GB is het maximaal praktisch (16x 16GB modules). Kortom, we kunnen nog niet eens 2% van het maximum aan. Waarom dan al naar 128 bit gaan?

Vind het jammer dat 64 bit ondersteuning (voorlopig) gestaakt wordt. Er zou een beperkte groep gebruikers zijn die er echt gebruik van zouden maken en bij Chrome (concurrent) zie ik het ook nog niet. Maar goed, ik kan me voorstellen dat de vraag in praktische zin heel erg klein is.

[Verwijderd]

Omdat er meer voordelen zijn dan het adresseren van meer geheugen. Dit is iets wat heel veel mensen blijkbaar niet weten.

- Met de overgang naar 64-bits ondersteuning zijn er meer general purpose registers beschikbaar in de CPU. Dit betekent dat er minder naar het geheugen gelezen/geschreven moet worden tijdens complexe berekeningen en de applicatie dus sneller zal werken.

- De instructie set heeft ook een upgrade gekregen, waardoor 64-bits berekeningen in veel minder CPU-cycles uitgevoerd kan worden, met als gevolg weer snelheids winst.

En zo zijn er nog een aantal voordelen. Het grote nadeel is dat elke instructie ook 64-bits is wat dus voor extra geheugen traffic zorgt.

Edit: Hier een Wikipedia artikel met voor en nadelen
http://en.wikipedia.org/w...omputing#32-bit_vs_64-bit

[Reactie gewijzigd door Verwijderd op 23 juli 2024 13:35]

[player-x]

- Met de overgang naar 64-bits ondersteuning zijn er meer general purpose registers beschikbaar in de CPU. Dit betekent dat er minder naar het geheugen gelezen/geschreven moet worden tijdens complexe berekeningen en de applicatie dus sneller zal werken.

- De instructie set heeft ook een upgrade gekregen, waardoor 64-bits berekeningen in veel minder CPU-cycles uitgevoerd kan worden, met als gevolg weer snelheids winst.

Je vergeet even gemakshalve te vermelden dat een 64-bits CPU intern nog steeds op 128-bits berekeningen kan doen, de oude 32-bits P4 had ook al interne 64-bits berekeningen.

Het is dus helemaal niet noodzakelijk om 128-bit geheugen adressering te hebben om intern wel op 128-bit te werken.

[.oisyn]

- De instructie set heeft ook een upgrade gekregen, waardoor 64-bits berekeningen in veel minder CPU-cycles uitgevoerd kan worden, met als gevolg weer snelheids winst.

Dat heeft niets met de betreffende architectuur te maken. Een x86-64 CPU in 32-bits modus zal net zo goed van die optimalisatie gebruik kunnen maken. Daarnaast was het punt van de discussie of de overstap naar 128 bits een zinnige was. Jouw argument heeft daar in z'n geheel niets mee te maken - voor een nieuwe instructieset kun je ook gewoon meerdere registers introduceren, terwijl het nog steeds een 64-bits of zelfs 32-bits architectuur blijft.

En zo zijn er nog een aantal voordelen. Het grote nadeel is dat elke instructie ook 64-bits is wat dus voor extra geheugen traffic zorgt.

Instructies hebben geen vaste lengte op x86. Het nadeel is vooral dat de 2x zo grote pointers ervoor zorgen dat je meer padding krijgt in datastructuren (een int gevolgd door een pointer was op 32 bits 8 bytes, maar op 64 bits ineens 16 terwijl de int zelf niet groter is geworden - er wordt 4 bytes padding geïntroduceert om de pointer op 8 bytes te alignen). Er wordt dus meer geheugen aangesproken, en derhalve heb je sneller last van cache misses.

Als die complexe berekeningen waar je het over had veel verschillende delen van het geheugen aanspreken dan kan het weleens zo zijn dat de totale performance juist slechter wordt in 64-bits mode (heb ik zelf al verscheidene keren aan den lijve ondervonden).

Ik ben zelf werkzaam in de gamesindustrie, en performance is daarbij vaak van groot belang. Maar echt, de énige reden waarom wij de overstap naar 64 bits overwegen voor zowel de runtime (de game zelf) als voor tools, is gewoon de grotere virtual address space. Voor tools omdat sommige processen gemakkelijk meer dan 4GB gebruiken, en voor de runtime voornamelijk omdat een 64 bits address space betekent dat memory fragmentation zo goed als verleden tijd is. Performance increase is absoluut niet vanzelfsprekend en derhalve totaal geen argument.

Wat betreft 128 bits architecturen, die gaan we in de komende 30 jaar echt niet zien. Wel grotere register files en bredere vector-registers. En natuurlijk quadruple precision (128 bits) floating point registers / vector components.

[Reactie gewijzigd door .oisyn op 23 juli 2024 13:35]

[CyBeR]

Omdat er meer voordelen zijn dan het adresseren van meer geheugen. Dit is iets wat heel veel mensen blijkbaar niet weten.

- Met de overgang naar 64-bits ondersteuning zijn er meer general purpose registers beschikbaar in de CPU. Dit betekent dat er minder naar het geheugen gelezen/geschreven moet worden tijdens complexe berekeningen en de applicatie dus sneller zal werken.

- De instructie set heeft ook een upgrade gekregen, waardoor 64-bits berekeningen in veel minder CPU-cycles uitgevoerd kan worden, met als gevolg weer snelheids winst.

Dit heeft echter niks te maken met 64-bit zelf te maken, alleen met dat ze tegelijk met de verlenging van de words de rest van de architectuur ook een kleine update hebben gegeven. Dit hadden ze prima met 32-bit kunnen implementeren en 't heeft al helemaal niks met een eventuele 128-bits proc te maken.

[Ayporos]

Ongeacht alles wat hierboven wordt aangehaalt:

Ik wil meer dan 4GB aan internetpaginas tegelijkertijd open kunnen hebben.

Op het moment als ik druk online bezig ben dan moet ik naar mijn taskmanager blijven kijken dat ik niet in de buurt van de limiet kom want dan crasht firefox gewoon doodleuk (wat naar mijn ervaring meestal gebeurt dicht bij de 3GB opgenomen werkgeheugen).

Ik heb toch gvd niet voor niks 12GB ram in mijn systeem zitten????

[Adion]

Je kan ook een browser gebruiken die voor elke tab een nieuw proces start (zoals Chrome), dan heb je voor elke tab 4GB ter beschikking, ipv 4GB in totaal voor alle tabs.

[Ayporos]

Ja en dan 500 browser processen tegelijkertijd runnen op mijn pc zeker?.. dunno of dat zo'n goed idee is maar toch bedankt voor de input!

[qlum]

Zover ik weet is in praktijk de prestatie winst voor 64bit te laag om het echt iets te maken waar naar over gegaan moet worden. dit is tenminste hoe het zit op webbrowsers

[Verwijderd]

Inderdaad, un-/zippen bijvoorbeeld vind ik op 64bit (gek genoeg) trager op werken. Maar misschien zit dat 'm in hoe de toepassing omgaat met 64bit? Geen idee hoe dat precies werkt. ("Even de wiki lezen" dan maar )

[gast128]

Er zitten ook nadelen aan, zoals dat pointer 64 bits worden waardoor er meer geheugen nodig is om geheugen te adresseren (zie http://blogs.msdn.com/b/r...re-no-64-bit-version.aspx).

De x64 heeft meer registers waardoor je snellere code verwacht (minder cache of geheugen benaderingen).

[ctrl-tab]

Het gaat natuurlijk niet alleen om hoeveel reepjes geheugen je in je pc kan proppen maar ook mogelijkheden binnen je code (integers etc.).

Ik denk dat dit laatste de reden zal zijn om op termijn over te gaan naar 128bit en niet zozeer hoeveel geheugen je op je MOBO kwijt kan.

[latka]

Ook op een 32 bit CPU kun je met 64 of zelfs 128 bit integers rekenen. Het allergrootste voordeel van 64 bit CPU ligt echt in meer geheugen adresseren. Vooen webbrowser nauwelijks interessant, zeker als je nagaat dat er meer en meer gewerkt wordt met een proces per tab. Dus 2gb per tabblad....

[Keneo]

Hoezo 192GB is maximaal praktisch?

De sun-fire-x4800 wordt verkocht met 4TB ram (128x32G latjes)

Verder verkoopt intel courant mobo's met plaats voor 48 ramlatjes, en zijn er al een tijdje 64GB latjes te koop.

Bovendien kan de 64bit versie beter gebruik maken van de extra registers (de 32 bit zal dit niet volledig doen) en de nieuwe instructiesets.

Daarentegen worden wel alle pointers opeens 64 bit, en kan een programma soms toch sneller draaien in 32 bit mode.
Daarom heeft de linux kernel vb support voor x32 abi. Hierbij kunnen alle features van 64 bit processoren gebruikt worden, maar worden er toch maar 32 bit pointers gebruikt (handig voor applicaties die nooit meer dan 4G Ram nodig zullen hebben, Firefox alloceert echter al 4G bij het opstarten, en kan soms meer gebruiken, dus niet duidleijk of dit hier ook geld. benchmarks zijn nodig!)

[Reactie gewijzigd door Keneo op 23 juli 2024 13:35]

[alfredkayser]

Enkele feitelijke onwaarheden in jouw stukje:
1. Firefox pakt niet direct 4GB, Firefox start met zo'n 110-150Mb.
2.. Er zijn al veel benchmarks waaruit blijkt dat applicaties (niet alleen Firefox) niet sneller zijn in 64bit mode, vaak juist wat langzamer.

[PuzzleSolver]

2^64 = 18.446.744.073.709.551.616 bytes

met de 1024 factor kom je dan toch op 16.777.216 Terra byte. oftewel 16 exabyte. 128bit voor geheugen adressering lijkt me voorlopig dan ook niet nodig.

Je zult met een browser niet snel meer dan 2GB gebruiken, dit is de reden dat browsers nog lang 32 bits zullen blijven. Zodra er meer en grotere content zou draaien in browsers zoals games dan zou de markt voor 64bit browsers interessanter worden,

Maar momenteel kun je met een 32bit browser prima uit de voeten en voegt een 64bit browser daar maar weinig aan toe.

[Blazing-Studios]

ik had al het vermoeden dat er in W8 geen 128bits kernel zat
Ik verwacht ook niet dat er uberhaupt noodzaak zal zijn voor een 128bits kernel voor 2020.

Overigens was mijn bron redelijk betrouwbaar over het algemeen

[mad_max234]

We gingen van 2^32 naar 2^64

Zolang er geen pc zijn met meer dan 4TB ram hebt zit je met 64bit goed. FPU in moderne x86 van intel en amd kunnen al hardware versneld 256bit fp berekeningen uitvoeren.

128bit is niet voor consumenten, win7 ultemate mag je maximaal 128GB gebruiken, zie dus niet in waarom MS naar 128bit zou overgaan voor consumenten als ze niet eens 1/10 van 64bit mogen gebruiken.

[Jasper Janssen]

2^64 is 16 exabyte. Dat gaat nog wel ff mee kunnen inderdaad.

[Phoib]

Gezien het gebrek aan 128 bits consumenten-CPU's, verwacht ik niet dat we binnen, pak-em-beet, 5 jaar veel 128 bits apps zullen hebben.

[mkools24]

Ik vind een 64-bit versie van Firefox anders onnodig, zeker nu. Hetzelfde geldt voor een 64-bit versie van Office 2010 en IE9. In bedrijfsomgevingen gebruik je altijd de 32-bit versies i.v.m. compatibiliteitsproblemen, plugins, of andere software die gebruik maakt van deze applicaties.

Zo wordt bijv. Flash op IE9 x64 nog niet eens zo heel lang ondersteund. Bovendien kun je met 32-bit iets van 3.4 GB geheugen addresseren dat lijkt mij ruim voldoende voor een webbrowser zeker wanneer iedere tab nog eens een apart proces is net als bij Chrome.

64-bit is voor het OS zeker nuttig maar voor de meeste applicaties heeft het nog weinig meerwaarde.

[Gé Brander]

64bit Excel van Office 2010 en hoger heeft zeker baat bij de 64bit versie. Je wil niet weten wat voor een Excel gedrochten niet performen op 32bit maar wel op 64bit...
Groter aantal rijen beschikbaar etc.

[latka]

Staat allemaal los van 64 bit: dit kan allemaal met 32 bits maar Microsoft was te lui/ranzig/cheap om het te fixen. Alles wat met 64 bit kan, kan met 32 bit behalve meer dan 4 GB adresseren. Ik geen sheets die zoveel nodig hebben.
PS. Meer dan 4gb adresseren zou ook nog wel gaan met 32 bit, maar dat is wel vrij veel werk... excercise left to reader.

[Keneo]

Een single process kan niet meer dan 4G alloceren met een 32 bit address space.

Een applicatie wel, maar dan moet je inderdaad wel met meerdere processen (en niet threads) werken.

[RoyD]

Dat kan wel. Dit wordt gedaan door aligning. Je gaat er vanuit dat de laatste 3 bits altijd nul zijn (bij een 64 bits databus kun je acht bytes tegelijk inlezen).
Deze 3 extra bits zijn dan beschikbaar voor een 8x zo grote adresruimte.

[Jasper Janssen]

32 bits apps kunnen 2 gb adresseren, en dat is krap voor een webbrowser die alles in 1 proces gooit.

[Mijzelf]

32 bits apps op Windows 64 kunnen 4GB adresseren als ze willen.
bron.

[Verwijderd]

die 4GB is inclusief de hardware adressen voor Videokaart e.d.

In de praktijk kan een 32bit applicatie daardoor veel minder geheugen alloceren. In Windows is het standaard beperkt tot 2GB, hoewel er een switch is om 3GB te forceren. Maar dat werkt dus alleen wanneer de overige hardware verschrikkelijk weinig geheugen inneemt.... Dat kan bij servers, maar niet bij consumenten pc's.

[Deveon]

Er komt een tijd? Windows 2008 R2 is al niet meer te krijgen als 32 bit en ik dacht dat Windows 8 ook puur 64 bit (+ARM) was..

[Zer0]

Wat niet betekend dat er geen 32-bits applicaties mee gedraaid kunnen worden.

[kozue]

Ik weet niet hoe dat onder windows gaat, maar onder linux heb je voor het draaien van 32bits programma's een aparte versie van systeemlibraries nodig. Alle libraries die een applicatie gebruikt moeten dan 2x op je disk en 2x in het geheugen aanwezig zijn. Een library als GTK heeft nogal wat dependencies en volgens mij raak je daar honderden megabytes aan kwijt.

Overigens denk ik dat het hier alleen over windows gaat, want ik heb geen 32bit browsers op mijn systeem staan. Zowel firefox als chrome zijn gewoon 64bit.

Plugins vind ik een non-argument, want tegenwoordig zijn die toch niet relevant meer. Flash is langzaam aan het verdwijnen en java is al een paar jaar dood.

[roy-t]

In Windows is dit deels ook zo maar het wordt daar opgelost door WinSxS waardoor verschillende versies van systeem libraries naast elkaar kunnen bestaan maar ook hier geldt dat het meer geheugen kost.

[ReneX]

Er is een verschil tussen een 64-bit OS en een 64-bit applicatie.

Het is prima mogelijk een 32-bit applicatie te draaien op een 64-bit OS.

Microsoft raad zelfs aan de 32-bit versie van Office te gebruiken op een 64-bit systeem.

[killugh]

Maar dat is ook enkel en alleen maar vanwege de plugins. Niet omdat Microsoft dat zelf graag zo ziet.

[Verwijderd]

Mozilla heeft exact dezelfde reden:

Als redenen noemt hij dat veel plug-ins voor de 64bit-versie niet beschikbaar zijn of niet goed werken.

Door het ontbreken van deze plugins is waarschijnlijk ook de interesse vanuit de community laag.

Jammer is het wel, maar ik neem aan dat Mozilla geen ongelimiteerde fondsen heeft om dit project te blijven trekken.

Het project kan snel genoeg weer gestart worden als de plugin ondersteuning op 64 bit beter wordt. En anders neemt een fork misschien het stokje over. Palemoon is wellicht een goede kandidaat.

[SunnieNL]

Verschil is echter dat Microsoft wel oproept aan developers om de plugins 64bit ready te maken, zodat bij de volgende office versie eind 2014 toch echt wel de 64bit variant gebruikt kan gaan worden.

[Verwijderd]

Verschil daarbij is weer dat een roepende Microsoft iets beter gehoord wordt dan een roepende Mozilla. Die twee bedrijven zijn qua invloed volstrekt onvergelijkbaar natuurlijk.

[kozue]

Het niet ondersteunen van plugins vind ik juist een voordeel. Het gebruik van plugins staat recht tegenover een vrij toegankelijk web dat op ieder apparaat en lokatie werkt. Ik ben geen Apple fanboy maar ik heb wel altijd achter hun beslissing gestaan om geen flash mee te leveren op de iphone. Het web wordt er een betere plek van als flash, silverlight en alle andere proprietaire rommel gewoon verdwijnt.

[Flowmo]

En die draait gewoon nog 32 bits applicaties. No problem. Het gaat hier om de compatibiliteit voor 32 bit en die zal de komende 10 jaar nog wel blijven.

[Soldaatje]

Dat zal nog wel een heule lange tijd duren voordat OS-en stoppen met het ondersteunen van 32 bits software.
Maar een beetje raar is het wel.
Een nadeel is dat als je driehonderd tabs of meer open hebt je inderdaad tegen geheugenproblemen kan aanlopen.
Met Chrome heb je dat niet omdat elke tab een nieuw proces opent, als FF dat ook krijgt zou wel super zijn.

[svenk91]

Het moment dat 32 bit browsers meer dan 3GB (of wat het maximum met LAA flag ook is) bereiken zal eerder zijn dan dat 32 bit ondersteuning gedropt word op x86 OS'en vermoed ik. Neemt niet weg dat een 32 bit browser dan dus niet werkt (want knalt tegen ram grens aan). Nou hoop ik dat het nog vele jaren duurt voordat browsers zoveel ram nodig hebben (then again, als zware html 5 games toch plots populair worden...) en dat ze dan tijdig de x64 ontwikkeling weer kunnen booten.

Weet iemand trouwens hoe het zit met de portability naar 64 bits ARM? Als leek lijkt het me dat bepaalde codeer manieren geöptimaliseerd voor AMD64 ook handig zijn als je een ARM 64 app maakt. Maakt trouwens ook niet zo heel veel uit omdat ARM64 ook 32 bit ARM code kan draaien.

[TerraGuy]

Je hebt dan ook nog tussenoplossingen, door tabbladen in aparte processen te stoppen, kan elke tab het maximum van 3 a 4GB kan aanspreken. En voordat een game of applicatie dan 4GB nodig heeft, dat zal niet binnenkort zijn. Zelfs losstaande games hebben dat nog niet als minimumeis liggen (uitzonderingetje hier of daar misschien), aangezien de meeste mensen nog met 2 tot 4GB zitten.

Dus het kan inderdaad nog jaren duren voordat er een noodzaak komt. Maar het moet dan wel góed gebeuren, als er teveel problemen ontstaan krijg je een Vista-verhaal: een heleboel programma's en drivers werken slecht en daardoor krijgt Vista een slechte naam, terwijl het voor een groot deel niet te wijten was aan Vista; zo wil Mozilla zijn naam niet bezoedelen door een stapel flinke 'randproblemen'.

[Loller1]

Voor Linux zal dat misschien noch lang duren, maar ik denk toch dat Microsoft nu gaat afzien van een 32bit versie van de volgende Windows. Windows 8 zou normaal gezien niet zijn uitgekomen in een 2 bit versie, en sinds Windows 7 wordt 64bit vaker verkocht dan 32bit doordat die eerste nu gewoon standaard werd meegeleverd...

[latka]

Dat heeft ook gewoon met support te maken: een versie is goedkoper te onderhouden dan 2.

[The Jester]

Voor x64 liefhebbers is er Pale Moon.
Werkt prima. Meeste add-ons doen het ook gewoon.

[Verwijderd]

Het is erg jammer dat ze stoppen met de 64-bit support. Ik gebruik deze versie al geruime tijd en heb eigenlijk zelden problemen ondervonden.

Ook in combinatie met plugins (Flash, Silverlight, etc..) en extensies als Ghostery en NoScript werkte alles perfect. Het enige minpuntje is het vaak absurde geheugengebruik. Met de huidige prijzen voor ddr3 reepjes kan ik hier eigenlijk ook niet zo mee zitten.

Ik hoop dat het 64-bit project door een andere (dan maar onofficiële) groep opgepikt wordt.

[Titan_Fox]

Of mensen downloaden Pale Moon; een 64-bits kloon van Firefox. Er is er nog eentje waar ik even niet van op de naam kom... Waterfox geloof ik...

[Verwijderd]

Van de site van MS:

Kan ik 32-bits programma's uitvoeren op een 64-bits computer?
Veel programma's die zijn ontworpen voor een computer met een 32-bits versie van Windows, kunnen ongewijzigd worden uitgevoerd op een computer met een 64-bits versie van Windows. Er kunnen echter prestatieverschillen optreden. Als een 32-bits programma gebruikt maakt van eigen stuurprogramma's, werken die wellicht niet naar behoren in een 64-bits omgeving. Als u een 64-bits computer hebt, kunt u het beste programma's uitvoeren die zijn ontworpen voor een 64-bits computer.

Je kan FF gewoon draaien, net geprobeert. Windows 7 64 bits.

[Gamebuster]

Los van de theoretische en meetbare verschillen, heeft 64bit ook echt een merkbare performance winst?

[Reactie gewijzigd door Gamebuster op 23 juli 2024 13:35]

[_JGC_]

Het grootste voordeel van 64bit tov 32bit is dat je ervan uit kunt gaan dat MMX, SSE en SSE2 altijd aanwezig zijn. Je kunt ondersteuning daarvan gewoon onconditioneel in je code zetten, meestal doet je compiler dat zelfs al voor je.
Ik weet niet in hoeverre de javascript engine van die instructiesets gebruikmaakt, maar voor <audio> en <video> tags zijn die instructiesets zeer welkom.

[Gert]

De 64 bits IE 8/9 had juist al die optimalisaties niet i.t.t. de 32-bits IE (weet niet hoe het met 10 zit) dus 64-bit was juist trager...

64 bits browsers lijken gewoon weinig aandacht te hebben.

[markusclaas]

Niet alleen dat, maar ook extra registers enzo en wat efficientere ABI en meer. Snap inderdaad ook niet dat ze niet gewoon focussen op de 64bit versie.

[Greyh0und]

heeft 64bit ook echt een merkbare performance winst?

Laten we deze mythe verhelpen: 64bit impliceert geen performance winst.

Het kan inderdaad dat de programmeur gebruik kan maken van de extra ruimte op de processor registers om een stuk van een programma sneller te maken, maar dit ligt aan de programmeur en niet zozeer aan of het programma 32 of 64 bit is.

Het verschil tussen een 32 bit en 64 bit processor is dat een 32 bit processor in 1 keer een waarde van maximaal 32 bits groot kan verwerken en een 64 bit processor een waarde van maximaal 64 bits groot kan verwerken. Dat is technisch het enigste verschil

Een 32 bit integer kan maximaal een decimale waarde hebben van 4,294,967,295
Een 64 bit integer kan maximaal een decimale waarde hebben van 18,446,744,073,709,551,615

[Verwijderd]

Daar gaan we nu niet achter komen.

[i-chat]

dit laat toch wel zien hoe achterhaald firefox is. waar je ten teiden van ie6 / 7 mijlen ver voor liepen is dat nu wel anders ie9 en chrome presteren nu zoveel beter dat elke vergelijking mank gaat.

hoever dit gebrek aan visie gaat, is de duidelijk als je vraagt waarom bijv palemoon geen google -voice/video plugin heeft in de 64bit versie,

om over de prestatie verschillen tussen palemoon en firefox maar te zwijgen.

[harrald]

Lekker aan het overdrijven? Firefox is verre van achterhaald! Firefox loopt met genoeg dingen voor op andere browsers. En Firefox of een andere moderne browser vergelijken met ie9 en dan beweren dat ie9 beter presteert zorgt er voor dat ik je niet meer serieus kan nemen.

Overigens is Firefox wel 64bit op andere besturingssystemen dan Windows.

[Loller1]

U zegt wat?

http://www.neowin.net/new...pular-browser-for-windows

Firefox is de op 2 na snelste browser die er nu is, enkel IE9 en 10 doen beter.

[Palomar]

Een 64-bits webbrowser is voorlopig ook nergens voor nodig.

[Gropah]

Niet mee eens. Als je kijkt hoeveel een browser tegenwoordig voor van alles wordt gebruikt is het juist nodig om bijvoorbeeld meer dan 2GB aan te spreken. Een beetje veel tabs open, een paar youtube videos, sharelatex, paar documenten, gmail, twitch stream open, en voila je zit bijna aan de 2GB.

[naarden 4ever]

2GB. Dan heb je nog een keer dat nodig om tot de limiet te komen.

Ik ben het met Palomar eens, een 64-bits browser is absoluut nog niet nodig, en ik kan me ook niet voorstellen dat het dat wel wordt binnen de komende drie jaar.

[roy-t]

Niet waar, de theoretische limiet van wat je kan aanspreken met 32bits is 4GB geheugen, maar in oa Windows kun je per 32bits applicatie slechts 2GB geheugen aanspreken (1 bit wordt ergens anders voor gebruikt).

[Mijzelf]

Nee. Een 32 bits applicatie in 64 bits Windows kan 4GB gebruiken.

[Jester-NL]

Ik moet er eerlijk gezegd niet aan denken dat mijn browser gaat mekkeren omdat er 'maar' 3.8 gieg aan geheugen te adresseren is.
Serieus... ik zie regelmatig dat mijn vrouw (ruim) over de gieg heen gaat met haar Opera. En dat is het moment dat ze tegen mij begint te bitchen over downloads en achtergrond-processen

Doe dat gezever maal een factor drie... neuh, liever niet. Ga maar gewoon zorgen dat die browsers normaler met hun opdrachten om kunnen gaan. (Op dit moment: FF 17, op een 64-bits machine, nauwelijks plugins en alleen Tweakers maar open, en toch 252.000k geheugen gebruik??

[Menesis]

(In reactie op Gropah)
Hmm, maar dat is volgens mij ook op andere manieren op te lossen: Chrome start een aparte thread voor elk geopend venster/tab.
Voor zover mijn kennis dan gaat, kan elk venster/tab dan max 3 GB benutten.

[Reactie gewijzigd door Menesis op 23 juli 2024 13:35]

[Deem]

Het feit dat die nu niet nodig is vind ik geen reden om er niet mee verder te gaan. De toekomst is 64 bit.

[ReneX]

want?

In principe gebruik je alleen meer geheugen met 64-bit.
En zolang webpages nog in de 32-bit addressspace passen ;-)

[Deem]

Om dezelfde reden waarom jij nu niet meer inbelt met een 56k6 modem. Websites worden alleen maar groter en complexer. Zeg nooit dat het niet nodig is want er komt een tijd dat dat wel het geval zal zijn.

[markwiering]

De toekomst is geen 64-bit. De toekomst is 32-bit. Let maar op.

[markwiering]

In toekomst zal dat ook nergens voor nodig zijn.

[Yagermeister]

Er is toch ook een 64bit versie genaamd Waterfox? Waarom gaan ze niet met hun verder werken om dit gedaan te krijgen.

[ronski]

klopt:

http://www.waterfoxproject.org/

ander 64bit alternatief is PaleMoon:

http://www.palemoon.org/

[Verwijderd]

Pale Moon heeft ook een 64-bits versie, ge-ent op de Mozilla 64-bitter.
Maar als ik in de praktijk kijk is de 32-bits versie een stuk sneller. Rond de 10~15 procent geloof ik, althans op mijn machine.
Ik heb slechts 4 GB intern, dus heb geen enkel probleem met het gebruiken van een 32-bits browser, de geheugenlimiet raak ik nooit.

[Kosh66]

Maf, want de Linux en andere nix 64-bit builds werken al heel lang zonder grote problemen.

Lijkt erop dat het correct laten werken/maken van 64-bit applets onder windows dus ook nogal te wensen overlaat en mozilla daar een beetje de dupe van is.

[Reactie gewijzigd door Kosh66 op 23 juli 2024 13:35]

[Verwijderd]

In Windows: een 64 bits proces mag geen gebruik maken van 32 bits code (libraries). Opera lost dit "probleem" op door out of process plugins te gebruiken.

[Verwijderd]

Ubuntu raadt de 64-bit versie toch juist ook af?

[Pineka]

Er staat nergens dat ze 64bit afraden maar dat ze 32bit aanbevelen, zonder opgaaf van redenen. Ik draai Ubuntu 12.10 64bit zonder problemen. Misschien dat ze doelen op oudere systemen, opknappertjes, waar vaak Ubuntu op wordt gezet.

[Verwijderd]

Ze bevelen 32 bits aan

[roy-t]

Zowel, IE als Opera zijn browsers die het gewoon prima doen in 64 bits en er zijn tig andere 64 bits programma's voor Windows, dus ik neem aan het meer te maken heeft met de prioriteiten van Mozilla dan dat MS hier nu weer de schuld heeft

[Verwijderd]

Ik denk toch een beetje dubbel, zal denk ik wel een klap zijn voor het marktaandeel van FF. Ik Voorzie groeikansen voor Chrome e.d.

[mrc4nl]

opzich hebben ze wel een punt,de battlelog plugin voor firefox voor bf3 ondersteund geen 64bit

[ronaldmathies]

Tja, als er geen 64bits platform is om het op te draaien dan blijven de plugins natuurlijk 32 Bits. Vind het zelf een zwak argument, Windows en OSX zijn ook naar 64 Bits gegaan terwijl alle applicaties 32 Bits waren.

Op die manier verander je nooit wat. Je moet juist het voortouw nemen om je gebruikers ( de plugin bouwers ) mee te krijgen. Want met hun instelling zou Windows en OSX ook nooit naar 64 bits gegaan.

[marrs]

Het gekke is, plugins zijn langzaam aan het verdwijnen. Applets zie je al lang niet meer, en Flash en Silverlight worden nu ook meestal al vermeden omdat je er een steeds groter wordende groep mensen die via tablets en telefoons naar je site gaan niet mee kunt bedienen. In die context zou je bijna zeggen: haal plugin support lekker helemaal uit de browser en focus je op de browser zelf en hoe je met een 64 bits versie het maximale eruit kunt halen.

[Gropah]

Dus jij wilt noscript en/of adblock eruit halen? De mogelijkheid om snel nzb's naar mijn sabNZBD te sturen? De mogelijkheid om tweakers nog donderder te maken en praktischer in te delen zonder karma te gebruiken? Nee danku

[Niemand_Anders]

Je haalt nu addins/extensions en plugins door elkaar. NoScript en AdBlock zijn extensions. Flash, ShockWave, Silverlight en Java zijn plugins..

[marrs]

Zoals Niemand_Anders hieronder al terecht opmerkt, ik wil niet de configureerbaarheid van de browser eruit halen. Als jij je extensies netjes in bijvoorbeeld javascript schrijft (al dan niet in combinatie met CSS en HTML) dan is dat prima natuurlijk. Dat is web technologie, dat moet kunnen. Ik heb het specifiek over plugins die een deel van de HTML pagina renderen op een "eigen" manier. Dat is niet meer van deze tijd, dat kan JS met Canvas of WebGL prima tegenwoordig.

[Durandal]

Maar FF is nu juist de plugin browser. Je gooit niet z'n grootste kracht weg.

[HarryL]

Jammer... Erg jammer. ze gaan zo wel achter lopen. En dat terwijl FireFox een heel fijne browser is om te gebruiken. Als ze eenmaal achterlopen, kunnen ze dat nog weer inhalen?

[Jazco2nd]

wat een onzin. Ze hebben groot gelijk om hier geen tijd meer in te stoppen. Liever lekker die 32bits versie verder optimaliseren.

Onder Windows in elk geval boeit het geen drol.. pas als jij een app hebt die ENORM veel geheugen nodig heeft wordt het interessant. Kan ik me bij een browser niet voorstellen. Zelfs Google, gek op data, biedt geen 64bits Chrome aan. Gelijk hebben ze.
En zelfs Microsoft raadt 32bits apps aan ook op Windows x64. Dus lekker boeiend mensen. Mozilla neemt een slimme keuze ipv blind op alles te focussen wat een hype is of was.

[Reactie gewijzigd door Jazco2nd op 23 juli 2024 13:35]

[roy-t]

Ik weet het niet hoor, op Windows mag een 32 bits process maximaal 2GB geheugen aanspreken. Met Opera kom ik gemakkelijk op 1GB geheugen bij druk werk. Is het dan gek om te denken dat er over een jaar of 3 geen use-cases zijn waarbij een browser in typische scenario's wel eens over de 2GB geheugen komt? Helemaal nu alles naar de browser verhuisd.

Nu niet anticiperen/investeren betekend dat het probleem van geen 64 bits plug-ins over een paar jaar nog steeds bestaat en dat zou Firefox wel eens flink klanten kunnen kosten. Immers heb je op dat moment 3 keuzes:

-Firefox 32b blijven gebruiken en af en toe een waarschuwing of zelfs crash krijgen die je werk belemmert

-Overstappen op Firefox 64b maar al je plugins missen, een van de grootste redenen om Firefox te gebruiken (is mijn verteld)

-Eens even spieken bij andere browsers die al langer 64bits zijn om te zien of die wel al die fijne plugins (of alternatieven) hebben.

[kozue]

Je verward plugins met extensies. Extensies draaien overal op want die zijn geschreven in browser-code. Deze zijn niet afhankelijk van het OS of aantal bits. Plugins zijn native code, en zijn wel afhankelijk van het OS, maar plugins zijn er niet zo veel van (bv flash en java), en zijn bovendien op iedere browser beschikbaar.

[markwiering]

Gast, ik gebruik Opera op mijn Windows 2000, en Opera heeft nog nooit een hele GB aan RAM-geheugen in beslag genomen. Het RAM-geheugen gebruik van Opera op een 32-bit computer komt niet eens in de buurt van een hele GB. Opera gebruikt op mijn computer ongeveer 256 MB RAM-geheugen. Intotaal heeft mijn computer 1 GB RAM-geheugen, dus het valt mee. Vanaf Windows 95 kan Windows namelijk virtueel geheugen aanmaken als het RAM-geheugen tekort schiet.

Maar goed, als je echt dol bent op 64-bit, en je hebt een 64-bit computer, dan kun je de 64-bit versie van Opera downloaden. De plug-ins, extensies en add-ons kun je dan blijven gebruiken. In tegenstelling tot Mozilla Firefox hoef je je die in Opera niet te missen.