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)
Een slechte zaak dit, ooit komt er een tijd dat de 32 bit niet meer werkt en lopen ze achter ...
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.
Ik weet me nog een artikel te herinneren over microsoft en dat windows 8 misschien al 128 bits ondersteuning zou hebben.
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.
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.
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
- 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 Deurdouwer op 22 november 2012 16:31]
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
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 
)
)
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.- 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.
Het is dus helemaal niet noodzakelijk om 128-bit geheugen adressering te hebben om intern wel op 128-bit te werken.
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.- 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.
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.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.
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 november 2012 00:17]
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).
De x64 heeft meer registers waardoor je snellere code verwacht (minder cache of geheugen benaderingen).
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.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.
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????
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????
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.
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! 
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.
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.
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....
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.
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.
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!)
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 november 2012 01:22]
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.
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.
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
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
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.
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.
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.
2^64 is 16 exabyte. Dat gaat nog wel ff mee kunnen inderdaad.
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.
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.
32 bits apps kunnen 2 gb adresseren, en dat is krap voor een webbrowser die alles in 1 proces gooit.
32 bits apps op Windows 64 kunnen 4GB adresseren als ze willen.
bron.
bron.
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.
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.
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.
Groter aantal rijen beschikbaar etc.
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.
PS. Meer dan 4gb adresseren zou ook nog wel gaan met 32 bit, maar dat is wel vrij veel werk... excercise left to reader.
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.
Een applicatie wel, maar dan moet je inderdaad wel met meerdere processen (en niet threads) werken.
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.
Deze 3 extra bits zijn dan beschikbaar voor een 8x zo grote adresruimte.
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.
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.
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.
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.
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'.
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'.
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...
Dat heeft ook gewoon met support te maken: een versie is goedkoper te onderhouden dan 2.
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..
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.
Wat niet betekend dat er geen 32-bits applicaties mee gedraaid kunnen worden.
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.
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.
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.
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.
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.
Maar dat is ook enkel en alleen maar vanwege de plugins. Niet omdat Microsoft dat zelf graag zo ziet.
Mozilla heeft exact dezelfde reden:
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.
Door het ontbreken van deze plugins is waarschijnlijk ook de interesse vanuit de community laag.Als redenen noemt hij dat veel plug-ins voor de 64bit-versie niet beschikbaar zijn of niet goed werken.
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.
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.
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.
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.
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.
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 22 november 2012 16:54]
De redenering van Mozilla zelf:
Bron: http://thenextweb.com/app...d-50-of-testers-using-it/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).
[Reactie gewijzigd door OkkE op 22 november 2012 16:31]
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.
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.
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.
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.
Uit het artikel:Ik denk dat het probleem eerder in de 64 bit Windows versie zit
Het is inderdaad Windows.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.
Uit het artikel:Dat soort zaken wil men vaak niet toegeven
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.Submits van gebruikers over crashes zouden te laat opgepikt worden, omdat de ontwikkelaars andere prioriteiten zouden hebben en gebruikers zouden daarom een 'tweederangsgevoel' krijgen.
Volgens mij werkten 16-bit applicaties ook al niet meer op de (veelgebruikte) 64-bit versie van Windows 7.
64bit windows versies bevatten geen NTVDM meer. het is deze virtuele dos machine die de mogelijkheid gaf om 16 bit applicaties te draaien.
Jawel, en op Windows 8 64bit ook nog.
Hoeveel applicaties zijn er nog 16 bit dan?
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.
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.
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.
Voor x64 liefhebbers is er Pale Moon.
Werkt prima. Meeste add-ons doen het ook gewoon.
Werkt prima. Meeste add-ons doen het ook gewoon.
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.
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.
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...
Er is toch ook een 64bit versie genaamd Waterfox? Waarom gaan ze niet met hun verder werken om dit gedaan te krijgen.
klopt:
http://www.waterfoxproject.org/
ander 64bit alternatief is PaleMoon:
http://www.palemoon.org/
http://www.waterfoxproject.org/
ander 64bit alternatief is PaleMoon:
http://www.palemoon.org/
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.
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.
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.
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 22 november 2012 15:44]
Ubuntu raadt de 64-bit versie toch juist ook af?
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.
Ze bevelen 32 bits aan
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.
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
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.
hele slechte zaak dit. Zo stoppen ze met de vooruitgang wat nooit goed kan zijn!
konden ze niet de 32 bit versie staken? alle pc's hebben tegenwoordig tot 64 bit?
Probleem is dat de plugins nagenoeg allemaal 32 bit zijn. Je moet dus van gigantisch veel andere stukjes software ook 64bit versies hebben. Denk aan Flash en aanverwanten, viewers zoals PDF viewers etc etc.
zouden die niet 32bit blijven juist omdat firefox nog geen 64bit pushed... het is dus gewoon een lul-smoes...
Zo belangrijk is FF nou ook weer niet. Bovendien, er is geen gebrek aan 64 bits browsers.zouden die niet 32bit blijven juist omdat firefox nog geen 64bit pushed...
http://webwereld.nl/analy...it-firefox-varianten.html
Zoek iets uit zou ik maar zeggen. Ik vind FF echt niet zo belangrijk. Ik gebruik het wel maar Chrome ook, IE ook en Pale Moon, werkt allemaal goed hoor. De keuzes zijn zo heerlijk groot tegenwoordig.
Zoek iets uit zou ik maar zeggen. Ik vind FF echt niet zo belangrijk. Ik gebruik het wel maar Chrome ook, IE ook en Pale Moon, werkt allemaal goed hoor. De keuzes zijn zo heerlijk groot tegenwoordig.
Mijn plugins:
- Flash
- MozPlugger (om Evince te embedden in Firefox)
That's it. Oh ja, en alles is 64 bits (in Linux).
Ik heb nog een flinke hoop extensions, maar die doen niet aan native code (op misschien een enkeling na), dus die werken hetzelfde op 32 en 64 bit. Alles werkt netjes, en doet dat al sinds de installatie (versie 4 of zo).
Maar dat is Linux.
Het gaat hier om de WIN64 builds. Wat nog niet eens betekent dat je het zelf niet even kunt bouwen (mits je genoeg geheugen hebt).
Ik vind de reacties hier wat overdreven. Ik verwacht dat ze het wel oplossen wanneer het nodig is. Het enige dat ik erg apart vind is dat het niet gewoon werkt. In principe rijgen ze een hele lading cross platform libraries aan elkaar, dus dat zou moeten werken. Er zijn geen echte architecturele compatibiliteitsproblemen, want dan zou ik ze in Linux ook hebben. Ik vind het maar raar.
- Flash
- MozPlugger (om Evince te embedden in Firefox)
That's it. Oh ja, en alles is 64 bits (in Linux).
Ik heb nog een flinke hoop extensions, maar die doen niet aan native code (op misschien een enkeling na), dus die werken hetzelfde op 32 en 64 bit. Alles werkt netjes, en doet dat al sinds de installatie (versie 4 of zo).
Maar dat is Linux.
Het gaat hier om de WIN64 builds. Wat nog niet eens betekent dat je het zelf niet even kunt bouwen (mits je genoeg geheugen hebt).
Ik vind de reacties hier wat overdreven. Ik verwacht dat ze het wel oplossen wanneer het nodig is. Het enige dat ik erg apart vind is dat het niet gewoon werkt. In principe rijgen ze een hele lading cross platform libraries aan elkaar, dus dat zou moeten werken. Er zijn geen echte architecturele compatibiliteitsproblemen, want dan zou ik ze in Linux ook hebben. Ik vind het maar raar.
Waarom zou je een PDF viewer in je browser willen hebben? Wat is er mis mee als dat gewoon opent in een externe applicatie, net als alle andere bestanden? Waarom is PDF zo speciaal dat je er een browserplugin voor nodig hebt? Windows gebruikers zijn veel te lang gehersenspoelt door Adobe met hun Acrotroep.Denk aan Flash en aanverwanten, viewers zoals PDF viewers etc etc.
Naast Flash is er eigenlijk niks wat de moeite waard is om te installeren. Java en Silverlight gebruikt toch niemand meer op websites, naast een paar techdemos en microsoft sites. En zelfs Flash is al aan het verdwijnen. Wie maakt er nou nog moderne sites in Flash als je weet dat je site nooit zal gaan werken op iPads en andere apparaten zonder Flash ondersteuning?
Nieuwe wel, maar vergeet niet dat er nog ontzettend veel oudere PCs gebruikt worden. Kijk maar eens naar het nog steeds hoge marktaandeel van WinXP, dat zijn bijna allemaal 32 bits PCs.konden ze niet de 32 bit versie staken? alle pc's hebben tegenwoordig tot 64 bit?
Bij de meeste tweakers is er ondertussen wel een 64bit os ja.
Helaas zijn er mensen die nooit upgraden naar een 64bit os.
En ook Oem's leveren 32 bit versies aan klanten gewoon omdat het geldwolven zijn.
Helaas zijn er mensen die nooit upgraden naar een 64bit os.
En ook Oem's leveren 32 bit versies aan klanten gewoon omdat het geldwolven zijn.
Dat is klinkklare onzin. Veruit de meeste computers zijn 32-bit, ook hedendaags. Je bent als developer wel dom als je de 32-bit versie staakt. Dan raak je 80% van je gebruikers kwijt.
Zelfs de nieuwste programma's en spellen zijn 32-bit. In de winkel worden er ook veel 32-bit computers verkocht, en dan heb ik het niet over de tweedehands winkel.
Zelfs de nieuwste programma's en spellen zijn 32-bit. In de winkel worden er ook veel 32-bit computers verkocht, en dan heb ik het niet over de tweedehands winkel.
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?
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.
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 22 november 2012 16:14]
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.
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.
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.
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.
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.
Een 64-bits webbrowser is voorlopig ook nergens voor nodig.
Het feit dat die nu niet nodig is vind ik geen reden om er niet mee verder te gaan. De toekomst is 64 bit.
want?
In principe gebruik je alleen meer geheugen met 64-bit.
En zolang webpages nog in de 32-bit addressspace passen ;-)
In principe gebruik je alleen meer geheugen met 64-bit.
En zolang webpages nog in de 32-bit addressspace passen ;-)
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.
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.
De toekomst is geen 64-bit. De toekomst is 32-bit. Let maar op.
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.
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.
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.
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).
Nee. Een 32 bits applicatie in 64 bits Windows kan 4GB gebruiken.
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??
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??
(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.
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 22 november 2012 16:05]
In toekomst zal dat ook nergens voor nodig zijn.
Waarom stoppen ze niet met development van de 32-bitter? Gaat met uw tijd mee...
Omdat je de 32 bits versie kan gebruiken op 64 bits en niet andersom
Omdat 32-bit de toekomst is.Waarom stoppen ze niet met development van de 32-bitter? Gaat met uw tijd mee...
Los van de theoretische en meetbare verschillen, heeft 64bit ook echt een merkbare performance winst?
[Reactie gewijzigd door Gamebuster op 22 november 2012 15:44]
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.
Ik weet niet in hoeverre de javascript engine van die instructiesets gebruikmaakt, maar voor <audio> en <video> tags zijn die instructiesets zeer welkom.
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.
64 bits browsers lijken gewoon weinig aandacht te hebben.
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.
Daar gaan we nu niet achter komen.
Laten we deze mythe verhelpen: 64bit impliceert geen performance winst.heeft 64bit ook echt een merkbare 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
opzich hebben ze wel een punt,de battlelog plugin voor firefox voor bf3 ondersteund geen 64bit
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.
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.
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Tablets E3 2013 Mobiele telefoons Google Sony Microsoft Apple Games Politiek en recht Consoles
© 1998 - 2013 Tweakers.net B.V. onderdeel van De Persgroep, ook uitgever van Computable.nl, Autotrack.nl en Carsom.nl • Hosting door True
