De enige reden waarom ik 32-bits heb is vooral omdat de prestaties helemaal niet beter zijn... sterker nog, vergelijkingstesten laten duidelijk zien dat de 64-bits een stuk minder presteert.

tijd om updates uit te zetten dan maar..

[rant]
Ik hoop niet dat Mozilla dit net zo voortvarend gaat aanpakken als met de SSE2 instructieset: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1698501. Er zijn ook mensen met een 32 bits OS/CPU en wel 4 GB RAM (effectief 3-3,5 GB). Ook is RAM makkelijker uit te breiden als een nieuwe processor in je moederbord steken.

Volgens mij draait Xubuntu nog steeds soepel met 1 GB RAM. Ik snap die browsermakers van tegenwoordig niet zo. Alles wat oud is moet weg! Ik kan het niet testen van Xubuntu, want de machine waar ik het over heb heeft nog een AMD Athlon XP processor zonder SSE2 en kennelijk kan dat toch echt niet meer tegenwoordig.
[/rant]

hmmm, Ik had juist een enorme verbetering van de prestaties toen ik van 32 naar 64 bit ging. Dit was op zowel windows 7 (pc) windows 8.1 (laptop) als windows 10 (gaming pc).

Ik behoor blijkbaar tot de 3%! :D

Tijd om was exploits op te zetten dan maar. XD

Waarom? de hele wereld zit al jaren op 64 bits....
Waarom toch altijd de drang op oude rommel te werken.....

Waarom?
Als gebruiker wil ik zelf bepalen wat goed voor mij is.

Ik gebruik al bijna 3/4 jaar geen Firefox meer, maar mijn ervaring met de 64 bits versie was goed.

Ik herinner mij perfect dat de 64 bits versie een stuk vlotter werkte dan de 32 bits Firefox.
Het initiële laden (eerste keer starten) van 32bit Firefox na opstarten van W8.1 duurde altijd wel zo'n 14 à 18 seconden.

Na de installatie van de 64 bit versie was het starten telkens een aangename verrassing. Na uiterlijk 8 à 9 seconden was mijn homepage duckduckgo.com geladen.
Als ik gedurende een computersessie Firefox een keer afsloot en na verloop van tijd weer startte ging het laden veel sneller, hoog op 4 à 5 seconden, terwijl de 32 bit versie hier altijd wel zo'n 11 seconden mee bezig was.

(Ik weet dat allemaal nog zo precies omdat ik in de eerste instantie, de 32bit versie, door mijn ergernis vaak de seconden zat te tellen, en later alleen vanuit tevredenheid met de hogere snelheid van de 64bit versie)

Dat de algemene snelheid tijdens een Firefox sessie toenam heb ik nooit kunnen constateren.

Maar het belangrijkste verschil was wel: De stabiliteit ging er verbazingwekkend op vooruit!
Dat viel mij op doordat ik de voorheen uiterst vervelende melding "Firefox reageert niet" nooit meer heb gezien tot het einde van de aanwezigheid van Firefox op mijn computer.

(Toegevoegd, 11:19 uur)

Dat laatste bedenk ik nu, moet ik toch corrigeren.
Na verloop van tijd/gebruik van de 64 bit versie kwam deze tijdelijke freezes weer terug, maar niet meer zo frequent als voorheen.

Dat iets meer als 10 jaar oud is, wil niet zeggen dat het rommel is. Daarbij moet ik zeggen dat hardware DEP en ASLR wel goede toevoegingen zijn die niet in 32 bits processoren zitten. Maar een browser op linux hoeft van mij niet zo nodig 4GB te gebruiken. Linux is al redelijk veilig zonder DEP en ASLR, alleen al omdat het marktaandeel veel kleiner is en het daardoor minder interessant is voor aanvallers.

Het zijn leuke systeempjes voor mensen en kinderen die niet zoveel eisend zijn. Of voor oudere mensen die ook alleen maar hun facebook willen checken.

Om 'tegenwoordig' hier in context te plaatsen: de laatste AMD Athlon XP generatie is in 2004 geïntroduceerd.

Dat is niet waar.

Het is wel waar dat binnen het developerwereldje de drang bestaat altijd het nieuwste van het nieuwste te hebben en daar "natuurlijk" uit voortvloeit dat de rest van de wereld dat ook wel zal willen (wat niet waar is). Oh en natuurlijk je kan nieuw nauwlijks meer wat anders kopen voor de desktop (mobiel en embedded en al die andere dingen is een heel ander, en chronisch vergeten, verhaal), en met een economische levensduur van drie jaar is binnen commerciële kantoren de desktop wel 64bit ja... maar elders nog lang niet. En dat "elders" dat zijn nog best veel computertjes.

Dus jouw aanname hier is meer een indicator van wijdverspreide tunnelvisie dan een eerlijke blik op de werkelijkheid.

Waarom toch die dwang om altijd maar vooruit te rennen? Ik kan geen computer aanzetten of'ie is tijden bezig om "verbeteringen" te "updaten" of wat dan ook. Met een goede kans dat het resultaat langzamer is, of ineens meer geheugen nodig heeft, of plotsklaps er anders uitziet of anders werkt, of helemaal niet meer werkt, of wat dan ook.

Dat mag dan wel de goudstandaard onder browsermakers zijn, gebruiksvriendelijk is het geenszins.

Dus waarom heb ik geen zin in gedwongen te worden achter updates aan te hollen? Omdat het gedonder geeft, vaak veel meer dan het aan "verbeteringen" oplevert. En de oplossing? Meer dwang. Dat werkt altijd goed, flink dwingen en keuze afnemen. Maak je vrienden mee enzo.

Buiten dat het een zwaktebod is ("we zijn te stom om behoorlijk te programmeren", "we kunnen onze gebruikers niet overtuigen dus dwingen we ze maar", en zo verder) is het ook nog eens een stukje van het grotere probleem dat het huidige 'web nauwlijks nog staying power heeft. Het is niet stabiel en het wordt het steeds minder, en daardoor ook minder betrouwbaar.

En dat terwijl we er langzaamaan steeds meer afhankelijk van worden. Zoals de overheid die de burgers dwingt om "digitaal", d.w.z. per brakke website, "met de overheid te communiceren". Wat dan betekent dat als je je desktopje maar af en toe gebruikt het maar helemaal de vraag is of je dat "met de overheid communiceren" nog wel kan, de eerstvolgende keer dat je je verstofte computertje aanzwengelt, en al dan niet eerst een halve dag bezig bent met "updates".

"Oh het is weer april, ik moet weer aangifte doen. [... een flink gevecht met allerhande software ...] Oh ik moet nu eerst een nieuwe computer kopen. Straks maar kijken of ik dat van de belasting af kan trekken dan." -- en dan behoor je dus al niet tot de minima die daar botweg geen geld voor hebben. Deze keer omdat "64bit", de volgende keer omdat "rust", dan weer omdat "nieuw OS nodig, en dat lust geen oude CPUs", dan weer omdat... noem maar op. Wie zal mij garanderen dat ik dat niet ieder jaar hoef te doen? Nou?

Ik moest even in mijn mail zoeken, maar tot in 2012, heb ik een Pentium III 1000 MHz gehad met 256+128 MB RAM. Die draaide Xubuntu als een tierelier, maar uiteindelijk had Xubuntu 512 MB als minimum eis en sindsdien update ik deze niet meer.

Aan de processor ligt het niet dat hij het niet meer doet. Processors zijn sowieso het laatste wat kapot kan gaan aan een computer.

Wel december 2004 hè. Dat is afgerond 2005. ;)
Ik heb hetzelfde probleem met een Intel Pentium III... Niet stuk te krijgen.
Af en toe een schoonmaakbeurt om hem weer stofvrij te maken helpt blijkbaar.
Pas nog een nieuw processor fannetje op de kop getikt. De oude was altijd al lawaaiig en werd steeds lawaaieriger.
Klein ding dat tegen de 6000 toeren aan draaide. Vervangen door eentje van net boven de 4000 toeren.
Kon ie best hebben. Zo heet wordt ie helemaal niet op vollast, als de koelvinnen maar goed stofvrij blijven.

off-topic>

Alleen Xubuntu in RAM geladen, in mijn geval v16.04.2 ondersteund door een Intel Pentium Dual-Core E2160 Processor (1.80-GHz, 1-MB L2 cache, komt met 1 GB RAM nog toe.

Maar zodra de bij standaard installatie meegekomen Firefox meerdere grote tabs open had staan heb ik verschillende keren meegemaakt dat deze spontaan stopte. Zonder waarschuwing 'floep' weg.
Na uitbreiding tot 2GB RAM was dat probleem verdwenen.

Momenteel in Xubuntu op Pale Moon zit ik op een totaal RAM gebruik van 835 GB met 1 tab. (security.nl)

<end off-topic

Zojuist de daad bij het woord gevoegd, en de 64 bits versie opgehaald en geïnstalleerd.
Mijn eerste indruk is positief, het start snel op, en zelfs met meerdere add-ons gaat het prima.
Een euvel dat zich al langere tijd manifesteert is de performance in de gebruikersaccount [Gast] waar merkwaardigerwijze van de multiprocessen er één is die extreem hoog is in het geheugenbereik (gemiddeld 500.000 kb) en een procesgebruik van 30%. Deze slechte performance blijft hetzelfde onder de 64 bits versie van Firefox.

Dit gedrag gebeurt niet in de gebruikersaccounts [Administrator en Hoofdgebruiker].
Misschien heeft iemand een verklaring voor dit vreemde gedrag

32 bits gebruikt minder geheugen, maar kan bij hoog verbruik tegen grenzen aanlopen (ca. 1,8 GB).

64 bits gebruikt meer geheugen en heeft geen last van de 2 GB geheugengrens. Het maakt programmeurs wel weer lui, waardoor het geheugenverbruik hoger is dan nodig. Regelmatig worden daarom "verbeteringen" aangebracht die voornamelijk de rotzooi van slechte programmeurs opruimt. Dat is geen structurele oplossing. Een goed programmaontwerp en implementatie is nodig.

Mee eens.

Je bedoelt het "NX bit"? Toch wel, qua hardware. Software support is een ander verhaal. ASLR is puur een software iets en kan ook op 32bit, maar is daar relatief makkelijk te omzeilen wegens kleinere addresseerruimte. Maar ASLR op 64bits blijkt ook weer verbazend makkelijk te omzeilen in gegeven gevallen, dus zo'n panacea is het ook weer niet.

Browsers die niet vreselijk veel geheugen vreten en ook nog eens allerlei hulpbronnen lekken zouden wel fijn zijn.

Overigens zijn ze tegenwoordig allemaal over meerdere processen verdeeld en hebben dus per proces, in 32bit, zo'n 2GB aan addresseerruimte te verbranden. En dan kun je nog een heel eind toe via bijvoorbeeld PAE. Een 32bit machine met 6GB geheugen? Kan prima, heb hier een dual pIII bord liggen dat het kan. (Heb er alleen niet genoeg geheugen voor. Maar dit terzijde.) Niet dat ik nou zo'n fan ben van PAE, maar ik wil maar zeggen, dat 64bit aanbidden, daar word ik een beetje moe van.

Wel is het instructief om even te kijken waarom "64bit" nou zoveel snelheidswinst oplevert op x86. Specifiek op x86 is dat omdat de registerfile de bottleneck is, en die is in aantal, alsook in bitsbreedte, verdubbeld op x86_64. Maar omdat je niet alle registers overal voor kan gebruiken, is de winst veel groter: Vier van de acht registers (stack- en frame pointer, twee string indices) zijn beperkt, tegen (dezelfde) vier van de zestien op 64bit. Dat is dus een winst van acht op vier algemene registers, oftewel een verdrievoudiging. Dat geeft de compiler nogal wat extra toewijsruimte, die veel meer impact heeft dan simpelweg meer bitjes kunnen verschuiven in een keer.

Dat is dan ook de reden dat "32bit-in-64bit processen" een goed idee is, d.w.z. 64bit OS, ondersteunt naast 64bit processen ook processen in 64bit mode die toch weer 32bit pointers enzo gebruiken, scheelt geheugen en instructielengte, maar heeft wel toegang tot de extra registers.

Maarja, dan denk je terug aan eerdere processoren als alpha, mips, pa-risc, en power, die standaard met een vrijwel compleet orthogonaal bruikbare registerfile van 32 stuks register in 32bit danwel 64bit geleverd werden. Daar kan x86_64 nog steeds niet tegenop.

Er blijken nogal wat "high value targets" in dat kleinere marktaandeel te zitten, want juist veel servers. Maar het is wel veiliger dan windows wegens minder spectaculair onveilige architectuurkeuzes. Dat maakt het nog niet "veilig". Al zou ik als ik tussen die twee moet kiezen toch blind voor linux kiezen (systemd vrij, dat dan weer wel), onderwijl balend dat dat de enige keuzes zijn.

Eigenlijk het enige wat ik doe ik schrijven, tekst voor mensen of computerprogrammas die nauwlijks wat nodig hebben, lezen van bijvoorbeeld email of PDFjes, en verder noodgedwongen een hoop "'web". Dat laatste is zo ongeveer de enige reden dat ik een grafische desktop heb. Anders zou ik met wat (geemuleerde) glass terminals prima geholpen zijn.

De mainstay voor alles behalve de GUI is nog altijd een single core low power x86 machientje, en de desktop is een core2 in 32bit mode. Echt de enige reden dat ik naar 64bit zou gaan is gedwongen worden door gedram van luie developers elders.

Een woord: Opera

Game of Thrones (van "Hodor") is geschreven met de tekstverwerker Wordstar las ik een flinke tijd geleden :-) Dat is 16 bit, toch?!

Origineel 8bit zelfs, onder CP/M op 8080 of Z80. Even rondkijken op wikipedia leert dat het onder dos wel 16bit zal zijn; de "wordstar for windows" variant wellicht ook. Maar met een emulatielaag is het ook op 32bit en zelfs 64bit windows nog te gebruiken. En het zal z'n werk prima doen, want zoveel hulpbronnen vergt lettertjes op een rijtje zetten niet. Dat latere programmas steeds meer megabytes nodig hadden voor hetzelfde werk vond ik eigenlijk altijd best wel obsceen.

(Heb er veel gebruik van gemaakt onder CP/M, maar op dos vooral qedit in wordstar configuratie, en ondertussen al jaren nvi, met troff voor de opmaak van brieven enzo.)

Sterker nog, grote kans dat je met iets als wordstar productiever zal zijn dan met "WYSIWYG" spul, want je wordt niet voortdurend afgeleid met trivialiteiten. Zeker als je iets hebt dat je toestaat abstracties aan te geven, en de bijbehorende opmaak elders kan neerzetten, bijvoorbeeld met macrodefinities. Maar zelfs alleen al het je handen aan het toetsenbord houden helpt.

Begrijp je wel het verschil tussen een 32 bits of 64 bits systeem, anders even opzoeken.

Wanneer krijgen we 128 bits systemen? Kappa

Bestel een AS/400. Of wat bedoel je precies met "128 bits systeem"?