Google staakt ondersteuning Chrome voor 32bit-Linux

Chrome stopt per begin maart 2016 met het uitbrengen van officiële Google Chrome 32bit-Linuxversies. Dat betekent niet dat er geen ondersteuning meer is voor het opensourceproject Chromium, waardoor gebruikers van verschillende 32bit-Linuxdistributies niet hoeven te vrezen.

Dat schrijft Chromiumontwikkelaar Dirk Pranke in het Chromium-dev-kanaal op Google Groups. Dat houdt in dat gebruikers van de nog veel in gebruik zijnde Linuxdistributies Ubuntu 12.04 en Debian Wheezy geen automatische updates meer krijgen. Omdat het wel het doel is de 32bit-versie van Chromium te blijven onderhouden binnen die kanalen, wordt aangeraden te upgraden naar nieuwere versies van de beide besturingssystemen.

Aangezien er wel 32bit-versies van Chrome OS en Android op zowel ARM- als X86-processors blijven bestaan voor de komende jaren, zal de 32bit-versie van Chromium niet zo snel verdwijnen, wat ook door Pranke in het kanaal bevestigd wordt.

Reacties (98)

[CAPSLOCK2000]

Om dit nieuwtje op waarde te kunnen schatten moet je weten dat Linux de overstap naar 64-bit een stuk eerder heeft gemaakt dan Windows. Hoewel Windows NT ooit is ontwikkeld met support voor 64-bit heeft MS er jarenlang niks mee gedaan waardoor ze eigenlijk helemaal opnieuw moesten beginnen toen er 64-bit x86 processoren kwamen.

Linux is al die tijd een multi-architectuur OS geweest dat ook veel op 64-bit systemen werd gebruikt (bv de SPARC-processoren van Sun). Hierdoor was de meeste software al geschikt voor 64-bit op het moment dat eerste x86-64 processoren uit kwamen en waren de programmeurs al gewend om hier rekening mee te houden.

De overstap naar 64-bit ging voor de meesten dus heel erg snel. De belangrijkste remmende factor was Flash. Ironisch genoeg was juist deze "platform onafhankelijk oplossing" het probleem. Adobe weigerde om een 64-bit versie voor Linux te maken en de open-source implementaties van Flash waren niet goed genoeg. Daardoor bleeft het nodig om 32-bit te blijven draaien ook al was de rest van het systeem er klaar voor.

Uiteindelijk is er een oplossing bedacht waardoor het mogelijk is om 32-bit en 64-bit volwaardig naast elkaar te draaien. Dat werkt zo goed dat je een modern Linux-systeem van 32-bit naar 64-bit (en terug) kan migreren zonder herinstallatie. Gewoon beide runtimes installeren en een keertje rebooten (beetje kort door de bocht maar dit is niet de plek voor een tutorial

Voor de duidelijkheid, dit gaat verder dan de mogelijkheid om 32-bit applicaties onder een 64-bit OS te draaien zoals Windows dat ook kan. Het verschil is dat alle componenten van het OS óók in 32-bit variant kunnen worden geïnstalleerd naast de 64-bit variant én dat het niet alleen om het aantal bits gaat maar ook om de rest van de architectuur. Je kan dus ook ARM-binaries installeren op je x86-systeem. Als je wil kun je tientallen architecturen installeren op hetzelfde systeem. Draaien is een ander verhaal maar met de juiste CPU/emulator kan het in principe, de x86-64 is het bekendste voorbeeld, die kan x86-32 en x86-64. Wederom gaat het te ver om alle details hier te bespreken.

Ten tweede moet je weten dat Chrome onder Linux maar weinig wordt gebruikt. De meesten kiezen voor Chromium, dat is de open source variant van Chrome die niet zo ver met Google is geintegreerd.
Dat de 32-bit variant van Chrome niet meer wordt ontwikkeld is dus niet zo erg, die werd toch al nauwelijks gebruikt.

Om een lang verhaal kort te maken kan je dus zeggen dat Linux al veel langer ondersteuning heeft voor 64-bit waardoor de overstap veel kleiner was dan onder Windows en dit veel sneller ging. Omdat Chrome-32 een niche product is met een uitstekende vervanger (Chromium) is het niet heel verbazend dat Google de ondersteuning staakt, er is eigenlijk geen markt voor.
edit: speling & gramaatica

[Reactie gewijzigd door CAPSLOCK2000 op 22 juli 2024 13:27]

[batjes]

Om dit nieuwtje op waarde te kunnen schatten moet je weten dat Linux de overstap naar 64-bit een stuk eerder heeft gemaakt dan Windows. Hoewel Windows NT ooit is ontwikkeld met support voor 64-bit heeft MS er jarenlang niks mee gedaan waardoor ze eigenlijk helemaal opnieuw moesten beginnen toen er 64-bit x86 processoren kwamen.

Beetje jammer hoe je MS zo onderuit haalt. Want MS zijn orginele plan was Windows XP als 64 bit only OS los te laten en heel de 32bit wereld achter zich te laten. Tevens kwam AMD64 pas in 2003 uit en eerder dan Vista zou het MS nooit zijn gelukt op X86 based 64bit over te gaan.

Buiten dit staat NT, net als Linux als kernel helemaal los van de architectuur waar deze op draait. Dit is absoluut niets nieuws. En dit is echt niet iets unieks aan Linux. Beide kernels kunnen dit al sinds het begin.

ARM64, SPARC64 of de Nintendo 64 -allemaal 64bit-, dit staat geheel los van AMD64 /X86-64 welke gebruikt wordt op computers en servers, welke de doelgroep van Windows was.

Buiten dit alles is Multi-Arch op Linux een enorme puinhoop, elke Linux Guru zal je uitlachen als je i386 toevoegd aan de 64bit Linux. Zonder herinstallatie de architectures mixen is niet aan te raden (Uit eigen ervaring met Debian koste i386 er weer afgooien me wel degelijk een herinstallatie) Dat Linux je deze vrijheid geeft, wilt niet zeggen dat het aan te raden is. Microsoft forceerd het gewoon om eventueel gezeik te voorkomen bij hun consumenten. Bij Linux is alles wat je doet of besluit volledig eigen risico. Want net als Windows, draait Linux het liefst gewoon op 1 architectuur tegelijk.

Snap niet helemaal waarom dit zo geplust wordt.

[Reactie gewijzigd door batjes op 22 juli 2024 13:27]

[CAPSLOCK2000]

Beetje jammer hoe je MS zo onderuit haalt.

Jammer dat je het zo ziet want dat was niet mijn bedoeling. In die hele lap tekst staan twee zinnen over Windows, de rest gaat over Linux. Ik zit er niet mee wat MS wel of niet doet, dat is niet mijn wereld. Ze hebben vast de verstandigste beslissing genomen voor hun markt, daar zijn ze heel goed in. Ik maak een vergelijking met Windows om context te geven bij wat de meeste mensen hier kennen want de Linux wereld is nu eenmaal anders. Ik probeer uitleg te geven over Linux, het is niet mij bedoeling om een oordeel over Windows te geven.

Maar goed, ik wil het wel even toelichten:

Want MS zijn orginele plan was Windows XP als 64 bit only OS los te laten en heel de 32bit wereld achter zich te laten.

Aan plannen hebben we niks, het gaat er om wat ze in praktijk gedaan hebben. Zoals ik al aangaf zijn er ook NT versies voor 64 bit geweest maar op een gegeven moment is MS daarmee gestopt. Toen is er een hoop kennis en ervaring verloren gegaan, zowel bij MS als bij de applicatiedevelopers. Ze hebben het nooit helemaal gestopt, er zijn altijd 64 bit versies van Windows geweest, maar die waren van secundair belang. Achteraf heeft MS er vast van gebaald dat ze het toen los hebben gelaten waardoor er jarenlang sofware is ontwikkeld die niet werd getest op 64 bit.

Onder Linux was er veel meer aandacht voor 64 bit, niet alleen in de kernel maar ook in userland. Toen x86-64 uitkwam was het voor de Linux wereld de zoveelste 64-bit architectuur die aan het lijstje werd toegevoegd terwijl het voor de meeste Windows-ontwikkelaar (OS en applicaties) de eerste keer was dat ze iets met 64 bit deden.

Buiten dit staat NT, net als Linux als kernel helemaal los van de architectuur waar deze op draait. Dit is absoluut niets nieuws. En dit is echt niet iets unieks aan Linux. Beide kernels kunnen dit al sinds het begin.

Dat klopt helemaal, maar Window 64 bit is lang een eiland geweest met weinig interactie met de rest van de wereld. De gemiddelde Windows applicatieprogrammeur ontdekte pas in 2005 dat 64 bit bestaat. In de open source wereld hoef je niet te wachten tot de leverancier een port maakt, dat doen de gebruikers zelf en als er aanpassingen nodig zijn sturen ze die terug naar de auteur (of zeuren er over . Zo was de meeste software al geschikt voor 64-bit voordat die processoren algemeen beschikbaar waren voor gewone gebruikers.

ARM64, SPARC64 of de Nintendo 64 -allemaal 64bit-, dit staat geheel los van AMD64 /X86-64 welke gebruikt wordt op computers en servers, welke de doelgroep van Windows was.

Ik snap niet wat je hiermee probeert te zeggen. Dat MS jarenlang weinig aandacht heeft gegeven aan 64 bit? Dan zijn we het eens.

Overigens is de SPARC echt op servers en workstations gericht.
Er zijn wel Windows versies (geweest) voor Alpha en Itanium maar de meeste applicaties zijn nooit naar die architecturen geport.

Buiten dit alles is Multi-Arch op Linux een enorme puinhoop, elke Linux Guru zal je uitlachen als je i386 toevoegd aan de 64bit Linux.

Waarom?
Welke Linux Guru's?
Welke systemen doen het wel goed en waarom?

Zonder herinstallatie de architectures mixen is niet aan te raden (Uit eigen ervaring met Debian koste i386 er weer afgooien me wel degelijk een herinstallatie)

Mijn ervaring is anders. Ik heb een twee dozijn Debian servers gemigreerd van i386 naar amd6 en typisch is dat binnen een uur gedaan. Ik zal niet beweren dat het eenvoudig is, mijn Debian i386 -> amd64 handleiding bevat 15 stappen en iets van 50 handelingen, maar het is goed te doen. Laten we het er op houden dat ik handiger ben met Linux.

Mixen is over het algemeen inderdaad niet handig, zeker bij componenten van het OS omdat er van die componenten vaak maar eentje tegelijk actief kan zijn. Maar goed, de vraag is waarom je dat in praktijk ooit zou willen? De meeste mensen die iets met multi-arch willen die willen een bepaalde applicatie draaien en hebben daarvoor bepaalde systeemlibjes nodig van de juiste architectuur. Daarvoor werkt het systeem uitstekend.

Daarbij moet ik wel aantekenen dat de package managers nog niet helemaal zo ver zijn. Hoewel het technisch prima mogelijk is om bv de 32-bit versie van Firefox naast de 64-bit versie te installeren moet je dan wel opletten dat die twee al hun files op een eigen locatie zetten en niet bv allebij /usr/bin/firefox claimen of elkaar uit het startmenu verdringen. Dat kan maar je moet er wel rekening mee houden maar nog lang niet alle packagers doen dat. Libraries zijn meestal geen probleem maar binaries wel. Wat dat betreft moet er nog een hoop gebeuren.

[batjes]

Jammer dat je het zo ziet want dat was niet mijn bedoeling. In die hele lap tekst staan twee zinnen over Windows, de rest gaat over Linux. Ik zit er niet mee wat MS wel of niet doet, dat is niet mijn wereld. Ze hebben vast de verstandigste beslissing genomen voor hun markt, daar zijn ze heel goed in. Ik maak een vergelijking met Windows om context te geven bij wat de meeste mensen hier kennen want de Linux wereld is nu eenmaal anders. Ik probeer uitleg te geven over Linux, het is niet mij bedoeling om een oordeel over Windows te geven.

Die indruk kreeg ik een beetje in het begin, van Linux is de heilige graal. Maar dat Linux het zoveel beter aanpakt op 64bit gebied valt redelijk mee, en de doelgroepen zijn anders. Debian is overigens 1 van de weinige distros die meer architecturen support dan Windows. Windows doet er officieel 3, alhoewel ze intern ook de blobs voor meer architecturen wel hebben(maar dat zal voor Ubuntu en Red Hat ook niet anders zijn). Ubuntu doet er ook maar 3, Red Hat ook "slechts" 4(waarvan 2 keer X86-64). Maar in any case, Microsoft liep niet zo ver achter op AMD64 dan Linux, SPARC64. N64 of andere 64bit architecturen staan los van AMD64, de kernel optimaliseren voor PPC64 gaat geen enkele impact hebben op het OS zodra je AMD64 implementeert.

Aan plannen hebben we niks, het gaat er om wat ze in praktijk gedaan hebben. Zoals ik al aangaf zijn er ook NT versies voor 64 bit geweest maar op een gegeven moment is MS daarmee gestopt. Toen is er een hoop kennis en ervaring verloren gegaan, zowel bij MS als bij de applicatiedevelopers. Ze hebben het nooit helemaal gestopt, er zijn altijd 64 bit versies van Windows geweest, maar die waren van secundair belang. Achteraf heeft MS er vast van gebaald dat ze het toen los hebben gelaten waardoor er jarenlang sofware is ontwikkeld die niet werd getest op 64 bit.

Onder Linux was er veel meer aandacht voor 64 bit, niet alleen in de kernel maar ook in userland. Toen x86-64 uitkwam was het voor de Linux wereld de zoveelste 64-bit architectuur die aan het lijstje werd toegevoegd terwijl het voor de meeste Windows-ontwikkelaar (OS en applicaties) de eerste keer was dat ze iets met 64 bit deden.

Naja alleen plan, ongeveer een jaar voor de release van XP was de codebase gewoon gericht op het overgaan naar IA64 en X86 achter te laten. Intel en MS kregen wat onderlinge strijd en MS verloor de hoop van IA64 en is maar X86 blijven hangen. Deels ook omdat de OEMs geen zin hadden over te gaan naar IA64. MS hun focus is vanaf XP gewoon 64bit geweest en niet in 32bit blijven hangen, 32bit was vanaf de release van Vista gedegradeerd tot een bijzaak. En voor ~2000 was 64bit niet echt van belang, sterker nog 16bit lag pas net achter ons.

En zoals je waarschijnlijk al weet is de NT kernel nogal zwaar (of bloated/lomp) en heeft vergeleken met Linux nogal hoge minimum specs, hierdoor was het bv vrij recent dat NT over ging naar ARM en ze CE konden droppen. ARM was er voor WP7-8 gewoon te zwak voor om NT soepel te draaien.

Dat klopt helemaal, maar Window 64 bit is lang een eiland geweest met weinig interactie met de rest van de wereld. De gemiddelde Windows applicatieprogrammeur ontdekte pas in 2005 dat 64 bit bestaat. In de open source wereld hoef je niet te wachten tot de leverancier een port maakt, dat doen de gebruikers zelf en als er aanpassingen nodig zijn sturen ze die terug naar de auteur (of zeuren er over . Zo was de meeste software al geschikt voor 64-bit voordat die processoren algemeen beschikbaar waren voor gewone gebruikers.

Dat komt deels omdat de noodzaak er gewoon niet is, zelfs EMET draait vandaag de dag nog in 32bit. 32bit applicaties kunnen gewoon de voordelen gebruiken van een 64 bit architectuur/OS. Zowel Windows als Linux doen aan deze optimalisaties. Met een 64bit only OS raak je gewoon bergens aan backwards compatiblity kwijt, zelfs op Linux is dit geen onbekend probleem. Elke keer Debian omtoveren tot Multiarch -omdat 1 of ander oude game of stukje software op een moderne distro dankzij library verschillen onmogelijk is te compileren- is ook geen pretje en brengt meer gezeik met zich mee dan dat het het waard is. Leuk dat Windows 64bit een "eiland" is geweest (Server kant is al enige tijd 64bit only en zelfs ten tijde van W2003 werd 64bit al aangeraden waar mogelijk) maar het heeft ze niet geschaad en dat 64bit in de Linux wereld zo "omarmt" heeft, heeft ze niet geholpen.

Ik snap niet wat je hiermee probeert te zeggen. Dat MS jarenlang weinig aandacht heeft gegeven aan 64 bit? Dan zijn we het eens.

Overigens is de SPARC echt op servers en workstations gericht.
Er zijn wel Windows versies (geweest) voor Alpha en Itanium maar de meeste applicaties zijn nooit naar die architecturen geport.

Door samen met Intel aan IA64 te werken en tevens intern met zowel Intel als AMD samen te werken om AMD64/X86-64 zo optimaal mogelijk te implementeren? IA64 is om meerdere redenen gefaald en AMD64 kwam pas uit in 2003, toen was XP al een jaar of 2 op de markt. XP 64bit kwam in 2005 uit, en Vista kreeg de focus op 64bit en 32bit was bijzaak. Dus dat MS er geen aandacht aan gegeven heeft lijkt weinig van te kloppen.

Net zoals X86 echt op servers en workstations is gericht en vrijwel uitsluitend daar de markt van Microsoft zat(Mobiel, tablets e.d. is iets recents). ARM was tot ~2009 niet erg boeiend want NT trok het toch niet en CE was in de meeste gevallen voldoende. En de overige architecturen zijn eigenlijk nog nooit van belang geweest voor Microsoft, dus waarom je kernel daar voor optimaliseren? Over het unificeren van al Microsoft hun codebases naar NT (en dus alle architecturen/platformen) spraken ze in de (eind)jaren 90 al van, toen 9x nog meedeed.

De meeste Windows software is makkelijk te porten naar andere architecturen, op je gehackte Windows 8 RT kon je X86 applicaties zonder moeite compileren naar ARM en het draaide daar probleemloos. Hierin zit echt geen verschil met Linux behalve dat op Linux de broncode voor veel applicaties beschikbaar is. (In ruil daarvoor heeft Linux een library hell, oh om te compileren heb ik LibXYZ-2.1.5 nodig, geinstalleerde versie: LibXYZ-2.2.7, compilation failed)

Waarom?
Welke Linux Guru's?

irc.freenode.org #debian bv.

Welke systemen doen het wel goed en waarom?

Ik heb zelf maar 1 (virtueel) systeem waarbij i386 multiarch op AMD64 me nog geen enkel probleem heeft gegeven. Waarom, geen idee, misschien omdat ik daar enkel 1 stukje software nodig had wat enkel op 32bit draait. Op de andere waar ik i386 toe heb moeten voegen ging het of om games of om meerdere stukken software, en dat is tot nu toe nog niet soepel gegaan. 1tje bleef zelfs nadat ik multiarch had toegevoegd en het systeem had herstart (verder geen enkele andere wijziging) bleef het erna vast zitten in het PTS scherm, KDE stuk. Gelukkig gnome kunnen starten zonder problemen maar doe dit niet de gemiddelde gebruiker(Of gemiddelde Linux "specialist") aan.
Meeste is verder wel op te lossen en probleem vrij te maken en niet elke keer gaf me problemen, maar het is geen holy grail die multiarch en ik zou het henk en ingrid zeker afraden.

Mijn ervaring is anders. Ik heb een twee dozijn Debian servers gemigreerd van i386 naar amd6 en typisch is dat binnen een uur gedaan. Ik zal niet beweren dat het eenvoudig is, mijn Debian i386 -> amd64 handleiding bevat 15 stappen en iets van 50 handelingen, maar het is goed te doen. Laten we het er op houden dat ik handiger ben met Linux.

Ik ben inderdaad geen linux guru, meer slechts een hobbyist (jaren geleden wel serieus mee bezig geweest maar de afgelopen 5+ enkel als hobby).
Op mijn eigen systeem was dat, niet helemaal eerlijk want zo netjes zat dat niet in elkaar. i386 moeten toevoegen want X werkte niet en was op de huidige release gewoon niet compileerbaar. Uiteindelijk bleek het met i386 ook niet te werken, ik de boel weer opschonen-multiarch weg, libs eraf en X weg-. Herstart, en ja hoor. Kernel Panic ergens halverwege de boot. Dit was overigens de laatste keer dat ik op mijn eigen systemen iets met Multiarch uitgevoerd heb, sindsdien maar besloten om een 32bit VM de lucht in te gooien mocht ik 32bit nodig hebben, en voor een upgrade is een nieuwe install en de data migreren gewoon makkelijker.

Toen Debian met Multiarch aankwam werd ik door een bekende(van mij, niet algemeen oid ) Linux guru er voor uitgedaagd om het maar eens te gebruiken, want het klonk mij allemaal goed in de oren(ik zag het echt als een plus punt voor Debian over Windows... Nu vindt ik de aanpak van Windows beter). Hij lachte me uit toen ik met mijn eerste kuren bij hem aan kwam Tevens 2 keer geprobeerd wat te vragen in #debian, (en ik weet grotendeels best wel wie daar wel kennis van zaken heeft en wie niet) en dat laat ik sindsdien ook maar achterwege.

Het zal verder vast op bepaalde vlakken mooie voordelen hebben, maar dan zit je in veel gevallen al boven het niveau van de gemiddelde Linux "specialist" (indruk van jou gaat me redelijk richting het guru-gehalte). Als je de kennis hebt is het leuk, ander is naar mijn indruk een VM (Wat op Linux met 1 commandje is gedaan) aanmaken makkelijker

[Reactie gewijzigd door batjes op 22 juli 2024 13:27]

[CAPSLOCK2000]

Ik wil er geen Windows vs Linux discussies van maken. Wat de redenen ook mogen zijn, naar mijn mening is de overgang naar 64-bit onder Linux sneller gegaan. Daardoor is het uitfaseren van Chrome-32 voor maar weinig mensen een probleem.

Deels ook omdat de OEMs geen zin hadden over te gaan naar IA64.

MS hun focus is vanaf XP gewoon 64bit geweest en niet in 32bit blijven hangen, 32bit was vanaf de release van Vista gedegradeerd tot een bijzaak. En voor ~2000 was 64bit niet echt van belang, sterker nog 16bit lag pas net achter ons.

MS heeft het zeker geprobeerd maar ze hebben de markt niet kunnen overtuigen om snel en soepel over te stappen. Na een goede start hebben ze er tijd geen aandacht aan gegeven. Er is een periode van een paar jaar geweest waarin iedereen wel wist dat het er aan zat te komen maar velen de overstap toch bleven uitstellen.
Dat is niet de "schuld" van MS maar het had soepeler gekund.

Het zal er wel iets mee te maken hebben gehad dat MS de consumentenmarkt moest overtuigen om over te stappen op Windows NT/XP. Eigenlijk was het plan geweest om dat al met Windows 2000 te doen maar die stap was te groot gebleken. Waarschijnlijk vond men het belangrijker om zoveel mogelijk software zo snel mogelijk geschikt te maken voor XP en dat ze daarom maar niet te veel hebben gezeurd over 64-bit.

knip & plak:

om te compileren heb ik LibXYZ-2.1.5 nodig, geinstalleerde versie: LibXYZ-2.2.7, compilation failed)

Ik heb zelf maar 1 (virtueel) systeem waarbij i386 multiarch op AMD64 me nog geen enkel probleem heeft gegeven. Waarom, geen idee, misschien omdat ik daar enkel 1 stukje software nodig had wat enkel op 32bit draait. Op de andere waar ik i386 toe heb moeten voegen ging het of om games of om meerdere stukken software, en dat is tot nu toe nog niet soepel gegaan.

ik zou het henk en ingrid zeker afraden.

i386 moeten toevoegen want X werkte niet en was op de huidige release gewoon niet compileerbaar.

Ik ken je achtergrond niet dus misschien heb ik het helemaal verkeerd maar dit klinkt als een typische Tweakers-valkuil. Je doet geavanceerde dingen die Henk en Ingrid nooit zouden doen op een systeem dat je niet goed kent en klaagt dan dat het te moeilijk is voor Henk en Ingrid

Henk en Ingrid kopen alleen voorgeinstalleerde computers en die gaan nooit zelf een driver compileren.

Ik snap je punt wel hoor maar ik wil geen Windows vs Linux discussie voeren. De systemen zijn anders, wat beter is mag je zelf beoordelen.

De problemen die je omschrijft lijken vooral met je package manager te maken te hebben. Daarvan gaf ik al aan dat die inderdaad nog niet op het gewenste niveau zijn. Voor de eindgebruikerservaring is dat lood om oud ijzer, het werkt of het werkt niet.

Wat dat betreft heeft Linux met MultiArch hetzelde probleem als Windows met 64-bit had. Je kernel kan het wel mooi ondersteunen maar als je applicaties er geen rekening mee houden dan heeft de gebruiker er niks aan.
Zoals MS in de periode 1998-2005 meer had kunnen doen om developers voor te bereiden op 64-bit zo had Debian (en de andere distro's) eerder moeten beginnen met packages voor te bereiden op multiarch. Op een bepaalde manier is het nu te laat omdat multiarch vooral handig is een overgangsperiode.

Goed, ik denk dat we het hier bij moeten laten of op forum verder gaan.

[batjes]

Goed, ik denk dat we het hier bij moeten laten of op forum verder gaan.

Ik kom vrijwel nooit op de forums en als het nieuws bericht niet meer op de frontpage staat lijkt het mij dat je daar ook wel beetje can discussieren Alleen diehard tweakers graven nu nog diep de comments in.

Ik ken je achtergrond niet dus misschien heb ik het helemaal verkeerd maar dit klinkt als een typische Tweakers-valkuil. Je doet geavanceerde dingen die Henk en Ingrid nooit zouden doen op een systeem dat je niet goed kent en klaagt dan dat het te moeilijk is voor Henk en Ingrid

Zelf kom ik er wel uit als libs versies niet kloppen (Tenminste op Debian, hun guidelines) meestal is beetje symlinken voldoende Maar ik kom dit zelf ook wel eens tegen op meuk wat juist gebruikt wordt (of naar gegoogeld wordt) door Henk en Ingrid(alhoewel het de laatste jaren gelukkig minder wordt en meestal gelimiteerd is tot antieke games)

Maar je hebt ook wel gelijk, Linux kwam er in 2003 toen het net uit was al mee aanzetten waar MS de eerste consumenten Windows 64bit pas in 2005 mee kwam aanzetten. Maar dat MS 64bit niet serieus nam klopt alleen niet naar mijn mening.

De voorbereiding die MS nam richting developers waren zaken als de Win32API, .Net en andere pakketten waarbij architectuur niet meer van belang was. Alles wat enigszins de MS richtlijnen(die MS echt wel richting developers gebuldert heeft) sinds die periode volgde kon zijn stukje software zonder moeite hercompileren naar 64bit. Maar MS hun "drawback" hierin is ook, backwards compatibiliteit, Windows heeft zo ontzettend veel software (Alle Linux repos + sourceforge bij elkaar komen daar echt niet bij in de buurt) van bedrijven die al jaren zo niet decennium van de aardbodem verdwenen zijn, dat ga je niet naar 64bit krijgen hoe hard je het ook afdwingt. Linux is hier dankzij hun distro aanpak wat flexibeler in. En omdat Microsoft 32bit als onderdeel hield bleven veel developers daar maar op hangen. Aan de server kant heeft MS dit met 2008 R2 wel afgedwongen, en met 2003/2008 erg proactief iedereen de 64bit kant opgeduwd.

MS heeft een andere aanpak, welke zijn eigen voordelen heeft. (Welke voor jou dus niet opwegen tegen de nadelen) en Linux weer andersom.

Persoonlijk heb ik hier 2 hoofdsystemen staan, 1 Windows 10 de andere Debian 8.1. Ze hebben allebei hun voordelen en nadelen. Maar ik had het voordeel dat ik destijds een Linux god in mijn vriendenkring had en verder altijd wel guru's in buurt had. Maar gelukkig is dit vandaag de dag nauwelijks meer nodig, Henk en Ingrid kunnen gewoon Ubuntu gebruiken en ze komen een heel eind zolang ze niet iets moeilijks proberen.

Verder ging het mij ook niet om een pro windows of pro linux discussie te voeren, meer om de pro-linux kant eens wat meer inzicht van de MS kant in te geven. Je hoeft het verder niet met MS eens te zijn (Persoonlijk vind ik Linus ook een dwaas verder wel respect voor hem), maar MS doet wel wat meer hun best dan wat jij ze aan krediet geeft/gaf.

[CAPSLOCK2000]

Ik kom vrijwel nooit op de forums en als het nieuws bericht niet meer op de frontpage staat lijkt het mij dat je daar ook wel beetje can discussieren Alleen diehard tweakers graven nu nog diep de comments in.

Nou, vooruit, nog een keertje dan, maar ik heb niet zo'n beste ervaringen met dit soort 1 op 1 threads, het wordt snel persoonlijk en dat is niet mijn bedoeling.

Even vooraf, ik denk vanuit de techniek. "goed" is voor mij gelijk aan "technologische vooruitgang". Als we het over een bedrijf hebben (MS in dit geval) dan kun je ook stellen dat "goed" is wat het meeste geld oplevert. Financieel gezien is MS super succesvol geweest, wat dat betreft hebben ze de juiste keuzes gemaakt.
Wanneer ik schrijf dat MS iets "anders" of "beter" had moeten doen dan doe ik dat mijn mijn roze technologiebril op. Dat de financiele realiteit andere eisen stelt negeer ik helemaal, daar kan ik toch niks zinnigs over zeggen.

De voorbereiding die MS nam richting developers waren zaken als de Win32API, .Net en andere pakketten waarbij architectuur niet meer van belang was.

Alles wat enigszins de MS richtlijnen(die MS echt wel richting developers gebuldert heeft) sinds die periode volgde kon zijn stukje software zonder moeite hercompileren naar 64bit.

Is de Win32 API echt architectuur onafhankelijk? De naam suggereert anders.

Maar dat detail terzijde zal ik niet beweren dat MS niets heeft gedaan, ze hebben het probleem echt wel aan zien komen. In het begin waren ze er ook heel duidelijk over maar ergens rond XP is er voor mijn gevoel een gat ontstaan in de aandacht waardoor het probleem opnieuw is ontstaan.
Ze haddden het "opgelost", of in ieder geval duidelijk gemaakt dat er een probleem was, en toen zwegen ze en kwam de aandacht bij andere problemen te liggen. Veiligheid heeft een paar jaar alle aandacht opgeslokt.

Maar MS hun "drawback" hierin is ook, backwards compatibiliteit,
Windows heeft zo ontzettend veel software dat ga je niet naar 64bit krijgen hoe hard je het ook afdwingt.

Alles wat enigszins de MS richtlijnen(die MS echt wel richting developers gebuldert heeft) sinds die periode volgde kon zijn stukje software zonder moeite hercompileren naar 64bit.|

Linux is hier dankzij hun distro aanpak wat flexibeler in.

Klopt, daarom wil ik ook niet zeggen dat MS het "verkeerd" heeft gedaan, maar het had "beter" gekund.

En omdat Microsoft 32bit als onderdeel hield bleven veel developers daar maar op hangen.
[/quote]

Aan de server kant heeft MS dit met 2008 R2 wel afgedwongen, en met 2003/2008 erg proactief iedereen de 64bit kant opgeduwd.

Ik denk dat het beter was geweest als ze dat al 5 jaar eerder hadden afgedwongen, net zoals Apple z'n developers nu dwingt om software geschikt te maken voor IPv6-only hoewel die netwerken eigenlijk nog niet bestaan.

maar MS doet wel wat meer hun best dan wat jij ze aan krediet geeft/gaf.

MS doet een hoop maar het resultaat is wat telt. We zijn het eens dat MS (of beter gezegd het hele Windows ecosysteem) om verschillende redenen een stuk meer werk had en andere problemen ha dop te lossen. Ik wilde laten zien wat die verschillen zijn hoe het veel kleinere en minder georganiseerde Linux het makkelijker had dan het rijke en strak georganiseerde MS.

[batjes]

Nou, vooruit, nog een keertje dan, maar ik heb niet zo'n beste ervaringen met dit soort 1 op 1 threads, het wordt snel persoonlijk en dat is niet mijn bedoeling.

Ik kan me soms wat slecht verwoorden of wat krom uit de hoek komen maar ik probeer het nooit persoonlijk te maken, jij hebt jou keuzes en mening, ik de mijne, iemand anders de zijne Maakt naar mijn mening een beetje goede discussie voeren juist zinvol.

Even vooraf, ik denk vanuit de techniek. "goed" is voor mij gelijk aan "technologische vooruitgang". Als we het over een bedrijf hebben (MS in dit geval) dan kun je ook stellen dat "goed" is wat het meeste geld oplevert. Financieel gezien is MS super succesvol geweest, wat dat betreft hebben ze de juiste keuzes gemaakt.
Wanneer ik schrijf dat MS iets "anders" of "beter" had moeten doen dan doe ik dat mijn mijn roze technologiebril op. Dat de financiele realiteit andere eisen stelt negeer ik helemaal, daar kan ik toch niks zinnigs over zeggen.

Dat ze een financiele monster zijn interesseert mij ook weinig verder tenzij ze het positief weten te gebruiken. Wat ze gelukkig vaker doen dan het negatief te gebruiken. En ik ben het op veel vlakken vaak alles behalve eens met MS en hun keuzes, gang van zaken. Het liefst zag ik zelf ook dat Vista gewoon 64bit only zou zijn, maar gezien de uitleg achter de keuzes van MS snap ik dat 32bit vandaag nog gewoon doorleeft. Uitzonderingen daargelaten, werkt alles beter, sneller maar vooral ook veiliger op 64bit.

Is de Win32 API echt architectuur onafhankelijk? De naam suggereert anders.

Ondanks wat de naam suggereert, is de Win32API volledig architectuur onafhankelijk. Er is maar 1 onderdeel in geheel Windows en NT architectuur afhankelijk en dat is de blob assembly wat met de CPU praat. Win32API is op een geroote Windows RT volledig beschikbaar. Op 64bit Windows zijn deze 2 express "fysiek" van elkaar gescheiden. SysWoW64 en System32 zijn omgekeerd, SysWoW64 = 32bit, System32 = 64bit Om het leuker te maken, deze mappen zijn slechts virtueel en alles zit in de WinSXS map. En afhankelijk van de architectuur van de app pakt "emuleert" het de juiste architectuur omgeving(Hier zit nog heel veel magie achter hoe Windows zo intern werkt, kan eens interessant zijn). Technisch is het mogelijk om de RT ARM Win32API er naast te draaien net als Linux de MultiArch heeft (alhoewel je dan niet slechts de libs geinstalleerd hebt die je nodig heb).

Maar dat detail terzijde zal ik niet beweren dat MS niets heeft gedaan, ze hebben het probleem echt wel aan zien komen. In het begin waren ze er ook heel duidelijk over maar ergens rond XP is er voor mijn gevoel een gat ontstaan in de aandacht waardoor het probleem opnieuw is ontstaan.
Ze haddden het "opgelost", of in ieder geval duidelijk gemaakt dat er een probleem was, en toen zwegen ze en kwam de aandacht bij andere problemen te liggen. Veiligheid heeft een paar jaar alle aandacht opgeslokt.

Dit klopt ook wel, ten tijde van de 32bit->64bit overgang was MS bezig met een security overhaul van al hun software. Wat hoe dan ook vertraging opgeleverd heeft. Het had zeker beter gekund en ze hadden wat eerder met 64bit mogen komen, maar het had weinig uitgemaakt, rond Vista begon ~4gb een beetje high end te worden en op XP was veiligheid sowieso al hopeloos.

Ik denk dat het beter was geweest als ze dat al 5 jaar eerder hadden afgedwongen, net zoals Apple z'n developers nu dwingt om software geschikt te maken voor IPv6-only hoewel die netwerken eigenlijk nog niet bestaan.

Probleem is dat MS niet zo machtig is als het lijkt Dwingen kunnen ze heel moeilijk. Ze zijn al sinds Windows 8 bezig iedereen over te halen naar het RT/Universal platform over te gaan en dat gaat ondanks enorme investeringen en erg proactief bezig zijn heel erg stroef.

MS doet een hoop maar het resultaat is wat telt. We zijn het eens dat MS (of beter gezegd het hele Windows ecosysteem) om verschillende redenen een stuk meer werk had en andere problemen ha dop te lossen. Ik wilde laten zien wat die verschillen zijn hoe het veel kleinere en minder georganiseerde Linux het makkelijker had dan het rijke en strak georganiseerde MS.

Zelf van mening dat niet alleen het resultaat geld, soms word je (of als bedrijf) gewoon onnodig tegen gezeten en dan geld de intentie ook wel een beetje. Linux heeft ook veel bereikt/gemaakt maar in veel gevallen amper tot geen resultaat gehaald. En helemaal heb je een punt dat Linux het met minder resources maar vooral minder geld toch erg goed bij blijft en minstens net zo vaak voorloopt. Ondanks dat momenteel mijn voorkeur voor zowel Desktop als Server eigenlijk bij Windows ligt, zal ik Linux niet links laten liggen. Als thuis server blijft Debian wel baas, de flexibiliteit die Debian over Windows heeft torent er hoog bovenuit verder(ZFS, gameservertjes etc. Je kunt er alles mee) doet het niet onder, maar is de onderhoudsfactor hoger.(Linux moet de simpelheids factor die MS en Apple bieden echt eens wat serieuzer omarmen) MS is vooralsnog gewoon koning op gamen en cooperate omgevingen. Te veel ITers weten niet goed genoeg waar ze mee bezig zijn en een AD/Exchange werkt simpeler zo niet beter. En als ik zelf niet zou gamen was mijn desktop ook Debian geweest.

[CH4OS]

Ten tweede moet je weten dat Chrome onder Linux maar weinig wordt gebruikt. De meesten kiezen voor Chromium, dat is de open source variant van Chrome die niet zo ver met Google is geintegreerd.
Dat de 32-bit variant van Chrome niet meer wordt ontwikkeld is dus niet zo erg, die werd toch al nauwelijks gebruikt.

Zo word in de meeste gevallen ook enkel Chromium aangeboden in de standaard app repositories. Dirk Pranke geeft dat ook aan; het zal dus (sowieso) gaan verdwijnen uit Ubuntu 12.04 en Debian 7, beide zijn distributies die natuurlijk niet helemaal up-to-date meer zijn. Dat is dus nog een reden, om de support te stoppen en enkel door te gaan met Chromium.

[Reactie gewijzigd door CH4OS op 22 juli 2024 13:27]

[i-chat]

dat klopt maar chrome wat bijv wel de enige browser met degelijke flash ondersteuning, dat betekend dat veel bezitters van oudere netbooks ed. straks bijv de website van de npo niet meer kunnen gebruiken onder linux.

ik heb een paar maandjes geleden nog een 32bit netbookje voor mijn moeder uitgerust met chrome, heel - lees heeeeel misschien kun je straks nog hopen op een oudere versie va peppermint in een nieuwere versie van chromium, want als dat niet zo is... dan wordt je langzaam dus verplicht om oudere netbookjes zoals de eee-pc's ed gewoon maar weg te flikkeren...

[Dreamvoid]

Dat kan je wel zeggen, maar er zijn nog altijd nieuwe Android telefoons met 32-bit Linux.

[Cornelisjuh]

Juist, omdat een 32bits OS maar tot 4GB RAM ondersteunt snap ik wel waarom Google dit laat vallen, aan die 4GB heeft Chrome nooit genoeg!

[Johannes77]

Serieus? 64 bit architectuur is in 1999 aangekondigd, en in 2000 geïntroduceerd. 32 bits pc-architectuur is daarmee echt zwaar verouderd. Ik ben gezien wet van Moore zwaar verbaasd dat we geen 128 architectuur in onze pc's hebben vandaag de dag.

Aan de andere kant, als je iets van Linux weet, zou je deze opmerking nooit gemaakt hebben. Linux en Chrome samen? Er van uit gaan dat je een film via YouTube wil kijken, kom je met moeite boven de 700 MB uit, als ik een dual core (C2D) met behulp van Handbrake op twee keer 100% liet lopen, kwam ik op 800 tot 850 MB uit, en echt 4 GB geïnstalleerd.

[MadEgg]

Wat zou je dan precies voor voordelen hebben aan 128 bits architectuur de komende tijd? Als je iets vergelijkbaars wilt toepassen wordt het alsnog iets heel anders. Moore's Law zegt dat de hoeveelheid transistors elke 18 maanden verdubbeld. Als je een 64 bits architectuur hebt en je voegt één bit doe dan verdubbelt de adresseerbare ruimte al, dus dan kunnen we met 128 bits wel een tijdje vooruit.

Berekeningen waarbij je meer precisie dan 64 bits nodig hebt zijn ook zeer schaars en kunnen prima berekend worden, alleen duurt het dan iets langer.

Het verdubbelen zou dus klinkkare onzin zijn; met een verdubbeling van het aantal bits verdubbeld ook de opslag en het geheugengebruik van allerlei programma's en het komt de snelheid ook nog eens niet ten goede: er moeten immers langere instructies verwerkt worden en grotere adressen. Zo lang er geen praktische reden is om over te stappen naar 128 bits zal dat ook niet gebeuren. Puur omdat het kan is leuk voor wetenschap maar niet voor de praktijk.

Neemt niet weg dat 32-bits ondersteuning wat mij betreft 10 jaar geleden al geschrapt had mogen worden. Dat is wel zwaar achterhaald inmiddels.

[Reactie gewijzigd door MadEgg op 22 juli 2024 13:27]

[CAPSLOCK2000]

Wat zou je dan precies voor voordelen hebben aan 128 bits architectuur de komende tijd?

Zo gek vind ik de gedachte toch niet, de ontwikkelingen in de IT gaan met horten en stoten. Wat het ene moment nog ondenkbaar is kan een jaar later de standaard zijn.

Hoewel ik ook geen idee heb wat me met 128-bit moeten en het me vooral heel erg duur lijkt zegt mijn onderbuik ook dat het langzaam aan weer eens tijd begint te worden. Als je naar de historische ontwikkelingen van Intel processoren* kijkt zou het in de buurt kunnen komen:
4-bit: 1971 -> 8-bit: 1972 -> 16-bit: 1978 -> 32-bit: 1985 -> 64-bit: 2000
1 jaar -> 6 jaar -> 7 jaar -> 15 jaar -> ?
Als het weer 15 jaar is dan komen we op 2015...

Ik geef direct toe dat het waardeloze indicator is maar het verklaart mijn onderbuikgevoel. Ik weet genoeg van CPU-architectuur om te beseffen dat we de grens nog lang niet bereikt hebben.

Helemaal ondenkbaar is het echter ook weer niet. In de TCP/IP wereld is men direct overgestapt van 32-bit adressen naar 128-bit. Daarnaast gebruiken we al databussen van 128-bit of meer. Dat is niet ongebruikelijk, [cg]pu's hebben wel vaker een bredere bus dan hun woordlengte, maar niet iedereen weet dat. Sommige GPU-fabrikanten zetten nu al trots "256 bit!" op hun verpakking.

Ik snap dus wel waar het idee vandaan komt dat 64-bit "oud" begint te worden.

Neemt niet weg dat 32-bits ondersteuning wat mij betreft 10 jaar geleden al geschrapt had mogen worden. Dat is wel zwaar achterhaald inmiddels.

Alle argumenten over lange pointers die je over 128-bit kan maken zijn ook van toepassing op 64-bit. 99% van de embedded apparatuur heeft eigenlijk nog geen behoefte aan 64-bit, een wasmachine aansturen gaat ook prima met 8 of 16 bit. Er is nog een hoop oude software die prima werkt en niemand wil herschrijven die niet werkt op 64-bit processoren.


* pas op: dit lijstje met alleen Intel procs geeft een misleidend beeld van de geschiedenis. Ik heb voor Intel microprocessoren gekozen omdat die het beeld van de meeste consumenten bepalen. Gespecialiseerde computers hebben echter een heel andere ontwikkeling gevolgd, de ABC uit 1942 was een 50-bit architectuur.

edit: spelling, grammatica, kleine verduidelijkingen

[Reactie gewijzigd door CAPSLOCK2000 op 22 juli 2024 13:27]

[MadEgg]

Ok, je hebt gelijk, ik stelde het te ongenuanceerd. Ik doelde hiermee met name op de 32-bits x86 architectuur. Embedded hardware draait vaak op ARM-systemen. Ik bedoel niet dat 32-bits architecturen achterhaald zijn, alleen dat x86-32 achterhaald is. Álle desktop-PC's en laptops zijn al jarenlang uitsluitend 64-bit. Als je je best doet kun je wel wat krijgen natuurlijk, maar er zijn nagenoeg geen consumenten of bedrijven die nog 32-bits hardware in hun desktops, laptops of servers hebben zitten. Uitzonderingen daargelaten in bedrijfskritische toepassingen in de vorm van oude software, maar om daarvoor nou al die tijd maar 32-bits te blijven ondersteunen is niet nodig. Die oude bedrijfskritische toepassingen draaien waarschijnlijk toch nog op MS-DOS of Windows NT 3.5, dus wat heb je dan aan een Windows 7 die op 32-bit kan draaien?

[catjam]

Door ProxMox (hypervisor) wordt voor KVM clients een 32-bit OS geadviseerd. Ik meen omdat deze iets efficienter met geheugen omgaan.

[Verwijderd]

Ik draai bij proxmox alles in 64-bit en moet zeggen dat ik dat advies nooit was tegengekomen... 32 gaat efficiënter om met geheugen, maar ondersteund maar max 4gb. Alle kvms die wij draaien zitten eerder in de 12gb range dan 4gb ;-)

[catjam]

In mijn geval draai ik alleen hele kleine servers allemaal minder dan 4GB. Toch draai ik ze in 64 bit omdat dat ik anders wéér een repo moet mirrorren ;-).

[CAPSLOCK2000]

Daar heb je gelijk in, 32-bit desktops hebben niet echt een speciale positie. De echte oude meuk is inderdaad 16 bits of minder en niet gericht op desktops.

De echte reden zal wel iets te maken hebben met dat mensen liever niet veranderen. We hebben allemaal wel een oom die nog Windows XP draait want zijn computer doet het nog prima, vindt hij zelf. Ik ken iemand die per se MS Office 97(!) wil installeren als hij een nieuwe computer koopt want hij heeft ooit 15 euro voor betaald voor een educatieve licentie. Een andere kennis kocht liever een losse WIFI-dongle met XP-drivers bij z'n nieuwe laptop dan over te stappen op W7.

Wij kunnen dat belachelijk vinden maar zolang er maar genoeg van dat soort mensen zijn is er een markt...

[H!GHGuY]

Hoewel ik ook geen idee heb wat me met 128-bit moeten en het me vooral heel erg duur lijkt zegt mijn onderbuik ook dat het langzaam aan weer eens tijd begint te worden. Als je naar de historische ontwikkelingen van Intel processoren* kijkt zou het in de buurt kunnen komen:
4-bit: 1971 -> 8-bit: 1972 -> 16-bit: 1978 -> 32-bit: 1985 -> 64-bit: 2000
1 jaar -> 6 jaar -> 7 jaar -> 15 jaar -> ?
Als het weer 15 jaar is dan komen we op 2015...

Dit is jezelf rijk rekenen. De overstappen van 8 (0-255) -> 16 (0-65535) -> 32 (0-4miljard+) -> 64 (0-heel veel) waren er ook omdat de data dit vereiste. Was het nu voor berekeningen of voor addressering, maakt niet uit.

Er zijn voorlopig nog steeds weinig toepassingen waar >64bit echt een must is, zowel voor addressering of voor data.

Helemaal ondenkbaar is het echter ook weer niet. In de TCP/IP wereld is men direct overgestapt van 32-bit adressen naar 128-bit.

Ja, IPv6 addressen zijn 128bit. Maar de address-space is zo ingedeeld dat routers de eerste 64bit bekijken en hosts vooral de laatste 64bit (hoewel ze natuurlijk het volledig adres moeten controleren). Zo kun je stellen dat IPv6 eigenlijk een 2x64bit adres-structuur heeft, eerder dan een 128bit adres-structuur. 128bits zullen voor IPv6 dus weinig uitmaken.

Daarnaast gebruiken we al databussen van 128-bit of meer

Die hebben absoluut niets te maken met de registerbreedte van de CPU (zoals je aangeeft). Busbreedte gaat enkel over het aantal bits/transfer en dus de snelheid. Niet over het aantal bits van de CPU. Als argument een lege doos, dus.

Dat is niet ongebruikelijk, [cg]pu's hebben wel vaker een bredere bus dan hun woordlengte, maar niet iedereen weet dat. Sommige GPU-fabrikanten zetten nu al trots "256 bit!" op hun verpakking.

Dit is voor mij nu wat buiten de comfort zone, maar die slaat ook weer meestel op de busbreedte. In het beste geval gaat het over de SIMD woordlengte, aangezien daar meerdere woorden tegelijk verwerkt worden. Zo is AVX-512 ook geen 512bits extensie, maar zijn het 8*64, 16*32, 32*16 of 64*8 operaties.
BTW: marketing, wie gelooft die mensen nog?

Necessity is the mother of all inventions. Zolang er geen nood is, ...

[CAPSLOCK2000]

Voor de duidelijkheid: ik ben het helemaal met je eens dat er op dit moment geen enkele logische reden is om de hele architectuur 128-bit te maken. Ik probeer vooral te verklaren waar het gevoel vandaan komt.

Toch zijn er wel stukjes die "iets" met 128-bit doen. We hebben registers en bussen die met 128-bits tegelijk werken. Dat is niet genoeg om het een 128-bit architectuur te noemen maar er worden al kleine voorschotjes genomen.

Ik kan me niet voorstellen dat we ooit behoefte krijgen aan 128-bits instructies maar een adresruimte van 128-bit zie ik nog wel gebeuren. 64-bit hoeft niet "op" te zijn voordat 128-bit nuttig is (zie hoe IPv4 op is ruim voordat alle adressen gebruikt zijn). Sterker nog, ik verwacht ooit een 256-bit adresruimte. De eerste 128 bits voor het IPv6-adres van de computer en de laatste 128 bits om een plek op het balkje ram te duiden. Ooit

[xcode35]

Je verwacht wel heel veel.

let op dat elke bit hoger al een verdubbeling is. 33bit is het dubbelen van 32 bit. en 65bit is het dubbelen van 64bit. 66bit is weer het dubbelen van 65 bit enzovoort.

Met ipv6 kan elk huishouden op deze planeet een biljard unieke ip adressen hebben. (50 quadriljard in totaal) En met een 64bit processor kun je een ramkaart van 16 miljoen Terrabyte in je PC stoppen. En jij hebt het over 256-bit dat nog eens exponentieel zo hoog is. Je onderbuik gevoel is nergens voor nodig hoor. We hebben de komende 100 jaar wel genoeg daar aan.

[CAPSLOCK2000]

let op dat elke bit hoger al een verdubbeling is. 33bit is het dubbelen van 32 bit. en 65bit is het dubbelen van 64bit. 66bit is weer het dubbelen van 65 bit enzovoort.

<knip>

We hebben de komende 100 jaar wel genoeg daar aan.

Er is een verschil tussen "genoeg" en "handig". Je kan alle mensen en straten in Nederland een (uniek) nummer geven en dan is 32 bits meer dan genoeg. Maar we geven onszelf toch noch steeds lange menselijke namen omdat we dat handig vinden.

256 bit adresruimte is inderdaad gigantisch veel, maar we hoeven niet alle ruimte ook te gebruiken.

Nu overstappen van 64 bit naar iets anders is veel te duur voor wat het oplevert. Wellicht wordt het in de toekomst zo goedkoop dat de kosten eigenlijk geen bezwaar meer zijn.
Meer dan 64 bit voor adressering lijkt voorlopig overbodig maar een databus van 128 bits is dat zeker niet. Als je een hele processor geschikt maakt om data met 128 bits tegelijk te verwerken is het misschien handiger om ook maar integers en pointers 128 bit lang te maken (of nog langer).

[mkools24]

Wat is er mis met 32-bit? Vrijwel alle software is nog 32-bit. Chrome bijv. kan voor iedere tab een nieuw proces openen dus de geheugenbeperking van 32-bit software is dan helemaal niet meer relevant.

In de zakelijke wereld is alle software nog 32-bits. Microsoft adviseert bijv. zelfs Office ook nog in 32-bit te installeren en ook IE wordt gewoon nog in 32-bit gebruikt overal. Nu is dat vooral ook vanwege de vele plugins die niet werken op 64-bit.

Maar buiten het OS of hele zware applicaties zoals SQL servers zou ik niet weten wat voor voordelen het zou moeten hebben om 64-bit voor standaard software zoals een web browser te gebruiken.

[Verwijderd]

64 bit instructies brengen vaak betere performance met zich mee. Met de steeds zwaardere web apps is dat niet verkeerd. Overigens is de Edge browser in Windows 10 standaard 64 bit dus Microsoft erkent dat ook. Een nieuwe browser ontwikkelen voor beide bitlengtes heeft geen zin meer.

Er wordt allang nagedacht over 128 bit cpu's, juist vanwege de betere prestatie. Geheugengebruik is tegenwoordig geen issue meer gezien de lage RAM-prijzen. 4 GB is tegenwoordig wel het minimum in een PC. Windows 10 draait ook nog eens zeer goed met weinig geheugen dus er is nu al genoeg ruimte om de stap naar 128 bit te maken.

Overigens zou ik het erg gaaf vinden als ze weer eens een nieuwe architectuur proberen. Intel's IA64 presteerde bijzonder goed met IA64-software. Wat ze nekte, was de barslechte x86-emulatie waardoor de overstap niet haalbaar was. Met de huidige stand van de techniek zou dat wel eens anders uit kunnen pakken. Ik ben geen techneut dus daar zullen slimmere mensen ongetwijfeld allang mee bezig zijn.

[CAPSLOCK2000]

Overigens zou ik het erg gaaf vinden als ze weer eens een nieuwe architectuur proberen. Intel's IA64 presteerde bijzonder goed met IA64-software. Wat ze nekte, was de barslechte x86-emulatie waardoor de overstap niet haalbaar was.

Een belangrijke reden om een nieuwe architectuur te willen is dat je alle legacy kan dumpen. Als je echter backwards compatible wil blijven dan kun je dat niet dumpen maar moet je het mee blijven slepen. Je kan alleen maar extra instructies toevoegen maar nooit eens iets weg halen. Wat dat betreft is AMD's x86-64 dus een zeer teleurstellende standaard. Het voegde nét genoeg toe aan x86-32 om het voordelig te maken. Hierdoor verloor IA64 momentum en is dat nooit doorgebroken. De 32-bit emulatie van IA64 was helemaal niet zo slecht maar x86-64 hoefde niks te emuleren en was dus sneller en goedkoper.

Hetzelfde probleem blijft bestaan. Als iemand een nieuwe architectuur uitbrengt die niet compatible is met x86 dan is het altijd voordeliger om de features van die nieuwe processor te jatten en toe te voegen aan x86. Op korte termijn is dat goedkoper en daarmee win je de markt.

Een nieuwe architectuur die wel helemaal compatible is met x86 uitbrengen biedt technisch gezien weinig voordelen, we willen juist van die beperkingen af, daar gaat dus niemand meer grote investeringen in doen.

[Reactie gewijzigd door CAPSLOCK2000 op 22 juli 2024 13:27]

[Verwijderd]

IA64 is van Intel en bij mijn weten hebben ze daar het alleenrecht op. Van jatten kan dus geen sprake zijn. Backwards compatibility is in ieder geval tijdelijk nodig om bestaande programmatuur te kunnen blijven gebruiken. Wellicht zouden ze nu in staat zijn om IA64-chips te produceren die x86 zonder merkbare vertraging kan draaien. De vraag is of we dit binnen 5 of 10 jaar mogen verwachten. Ik ben het met je eens dat we van die legacy troep af moeten die x86 met zich meezeult.

[CAPSLOCK2000]

IA64 is van Intel en bij mijn weten hebben ze daar het alleenrecht op. Van jatten kan dus geen sprake zijn.

Sorry, ik had m'n cover-your-ass woordenboek niet geladen. Ik bedoel natuurlijk dat je een innovatieve stap doet om te voorzien in de wensen en behoeftes van de markt

AMD heeft inderdaad geen IA64 gejat van Intel maar wel het idee om op dat moment een 64-bit processor uit te brengen. Het handige van AMD was dat ze net genoeg 64-bit deden om het project van Intel onderuit te halen. De klap zijn we nog steeds niet te boven.

Het plan van Intel was dat IA64 met emulatie uiteindelijk sneller zou zijn dan native x86. Men accepteerde dat dit in het begin niet zo zou zijn maar de eerste jaren waren die processoren toch nog te duur voor de grote markt. Die werden alleen gekocht door bedrijven die 64 bit nodig hadden. Na een paar jaar van de Wet van Moore zouden die IA64 processoren vanzelf wel snel genoeg worden om x86 sneller te emuleren dan de laatste generatie van x86. We moesten alleen even door die overgangstijd heen zien te bijten.

Precies op dat moment kwam AMD met een processor die net zo snel als een native x86 was maar ook een beetje 64-bit kon. Daarmee wilde niemand nog de dure chips van Intel die geen voordelen boden voor ouderwetse x86 code.

Vanuit marketing gezien een briljante zet maar technisch gezien een beetje jammer.

[Reactie gewijzigd door CAPSLOCK2000 op 22 juli 2024 13:27]

[Verwijderd]

Duidelijk verhaal! Wat ik alleen nog steeds niet begrijp is dat IA64 totaal is verdwenen. Voor servers blijft de prestatiewinst staan, met x86-64 erbij of niet. IA64 had gewoon duidelijk meer te bieden. Waarom heeft Intel dan niet aan zijn strategie vast kunnen houden en gewacht tot x86-emulatie minstens net zo snel werd als native x86?

Of breng het alsnog uit. Gooi wat marketing tegen IA64 aan en ze hebben een uniek product dat niemand zomaar na kan bouwen. Dan komen de native IA64 programma's vanzelf en dan móet je wel een IA64-cpu hebben als consument. Intel kan die lange adem best opbrengen denk ik.

[CAPSLOCK2000]

Duidelijk verhaal! Wat ik alleen nog steeds niet begrijp is dat IA64 totaal is verdwenen. Voor servers blijft de prestatiewinst staan, met x86-64 erbij of niet. IA64 had gewoon duidelijk meer te bieden. Waarom heeft Intel dan niet aan zijn strategie vast kunnen houden en gewacht tot x86-emulatie minstens net zo snel werd als native x86?

Ze verloren snel markt aan AMD. Ze moesten dus ook met een x86-64 implementatie komen en eentje die sneller was dan die van AMD en daarmee ook sneller dan hun eigen IA64.

Of breng het alsnog uit.
<knip>
Intel kan die lange adem best opbrengen denk ik.

Het is uit en je kan het gewoon kopen!
Dat je dat niet weet geeft aan hoe succesvol het is

Intel beweert dat ze er geld aan verdienen en ze blijven die processoren verkopen, al is er al drie jaar geen nieuwe meer uitgekomen.
http://www.intel.com/cont...um/itanium-processor.html

Ik denk dat ze vooral verkocht worden aan bedrijven die oude systemen moeten onderhouden en wellicht voor heel specifieke supercomputers. Het grootste deel van de pc & servermarkt heeft voor x86-64 gekozen. Intel heeft het grootste deel van z'n R&D op x86-64 gezet en daarmee is IA64 nooit sneller geworden van x86-64.

[Verwijderd]

Hehe nou ik wist wel dat het te koop is geweest. Natuurlijk doelde ik op regelmatig uit blijven brengen van nieuwe modellen. Als je als bedrijf iets hebt dat niemand anders heeft of kan kopiëren (unfair advantage) dan heb je m.i. goud in handen. Ik denk dat menig tweaker graag zo'n CPU in een desktop of laptop had gehad. De mainstream had wel gevolgd als de prestatiewinst duidelijk was geweest en zodra x86-emulatie op peil was gekomen. Nogmaals, ik ben geen techneut dus Intel zal wel zijn afweging hebben gemaakt op basis van kennis die ik niet heb.

[i-chat]

wait whut, probeer je hier nu amd de schuld te geven van het falen van ia64... de itanium is altijd al een heel ander slag cpu geweest als de x86... en de markt heeft duidelijk bepaald dat men liever compatible bleef met legacy - en toch de voordelen zou houden van een hogere adresruimte...

[CAPSLOCK2000]

"schuld" is een groot woord maar zonder AMD/x86-64 had Intel waarschijnlijk meer succes gehad met IA64. Ze waren dan op een gegeven moment gewoon gestopt met x86 processoren uit te brengen en dan was de markt wel mee gegaan.

[gast128]

Zo simpel ligt het niet. Op Intel geldt dat x64 meer adresseerbaar geheugen en meer registers heeft, maar ook de pointer lengte is langer geworden waardoor applicaties voor 64 bit gecompileerd groter zijn. Dit is voornamelijk nadelig voor (gelimiteerde) CPU caches.

• http://blogs.msdn.com/b/r...re-no-64-bit-version.aspx
• http://askubuntu.com/ques...and-which-should-i-choose

[borft]

Uhm, nee. Op mijn linux machine (ubuntu 15.10) is nagenoeg alle software gewoon gecompileerd voor de amd64 instructieset, oftewel gewoon 64bit. (overigens is op mijn mac ook bijna alles al 64 bit).

[sfranken]

Op mijn Fedora machines ook. Allemaal (3 stuks). 64 bit is de defacto standaard, vreemd dat er nog mensen zijn die op 32 bit (=~15 jaar "outdated") blijven hangen, zeker op Tweakers

[Mushuke]

...

In de zakelijke wereld is alle software nog 32-bits. ... Nu is dat vooral ook vanwege de vele plugins die niet werken op 64-bit.

...

Heb je hiervoor cijfers? want de stelling "in de zakelijke wereld is alle software nog 32-bits" is verkeerd, maar je hebt wel een punt dat heel veel mensen zich aan 32-bits vastklampen wegens de illusie dat een aantal zaken niet zouden werken. Veelal hebben de IT-ers niet de mogelijkheid om alles uitvoerig te testen, maar de houding van de meeste is onnodig rigide tov 64-bit...

[Gomez12]

In de zakelijke wereld is alle software nog 32-bits. Microsoft adviseert bijv. zelfs Office ook nog in 32-bit te installeren en ook IE wordt gewoon nog in 32-bit gebruikt overal. Nu is dat vooral ook vanwege de vele plugins die niet werken op 64-bit.

Oftewel vanwege het hoge aantal prutsers komen we niet verder...

Maar buiten het OS of hele zware applicaties zoals SQL servers zou ik niet weten wat voor voordelen het zou moeten hebben om 64-bit voor standaard software zoals een web browser te gebruiken.

Er is al 1 groot "gratis" basisvoordeel, je hebt betere en snellere optimalisaties want je maakt gebruik van de default van je cpu/os en niet van een halve cpu/os

[Bliksem B]

Neemt niet weg dat 32-bits ondersteuning wat mij betreft 10 jaar geleden al geschrapt had mogen worden. Dat is wel zwaar achterhaald inmiddels.

10 jaar geleden? Intel heeft nog steeds 32bit cpu's uitgebracht tot het jaar 2010 op zn minst. AMD kwam pas met AMD64 (x86-64) in 2003.

De reden waarom Google stopt komt ook mede omdat Chrome onder linux niet populair genoeg is. Iedereen gebruikt Chromium, de opensource variant die niet al de privacyzooi van google herbergt.

[MadEgg]

Wat heeft dat ermee te maken? 64-bit was al lang gemeengoed op Linux voordat Windows überhaupt met een 64-bit versie kwam (de briljante *kuch* Windows XP 64-bit editie). Er was dus sowieso weinig reden voor een 32-bit versie van Chrome op Linux, behalve hoogstens compatibiliteit met plugins, maar met het embedden van een Flash-player was dat in Chrome ook al geen argument.

[ronny]

Nou de reden kan zijn dat je Linux op een 32-bit machine hebt geinstalleerd. Dan wordt het natuurlijk lastig om een 64-bit versie van de software te installeren.

[Reactie gewijzigd door ronny op 22 juli 2024 13:27]

[MadEgg]

Duh... Maar zoals Bliksem het stelt is het bestaansrecht van Chrome 32-bit te danken aan de Linux-versie. Diezelfde persoon zou ook gewoon Windows XP kunnen draaien en daar een 32-bit versie van Chrome op kunnen draaien, dus dat heeft weinig met Linux te maken.

Sowieso is Chrome op oude hardware niet echt aan te raden. Firefox ook niet overigens; mijn favoriet op oude hardware was altijd Opera, die bleef dan wel snel. Geen idee hoe dat is sinds ze over zijn op webkit.

[Bliksem B]

Duh... Maar zoals Bliksem het stelt is het bestaansrecht van Chrome 32-bit te danken aan de Linux-versie. Diezelfde persoon zou ook gewoon Windows XP kunnen draaien en daar een 32-bit versie van Chrome op kunnen draaien, dus dat heeft weinig met Linux te maken.

Heb je het artikel gelezen? Of de titel? "Google staakt ondersteuning Chrome voor 32bit-Linux". Ik stel alleen dat het bestaansrecht van de 32bit variant te danken is aan de populariteit van 32 bits cpu's tot 2010.

Momenteel zou ik daarnaast geen xp draaien. Dus dan is Linux enige optie en dan is 32bit variant soms niet uit te sluiten.

[Reactie gewijzigd door Bliksem B op 22 juli 2024 13:27]

[MadEgg]

Damn, je hebt gelijk. Was dat de hele tijd al zo?

Blijkbaar verkeerd gelezen, ik dacht dat het om 32-bit in het algemeen ging. Dan is je uitspraak wel logisch

[ronny]

Intel heeft nog steeds 32bit cpu's uitgebracht tot het jaar 2010

Ik heb niet alles gecontroleerd, maar de Atom Z2560 is Q2 2013 geintroduceerd. Deze is nog 32 bits.
http://ark.intel.com/nl/p...r-Z2560-1M-Cache-1_60-GHz

[Verwijderd]

Moore's Law is de 5e paradigma van de wet op exponentiele groei (The Law of Accelerating Returns). Ik denk dat Johannes77 dat bedoeld. Inderdaad heeft de genoemde architectuur niet wat te maken met Moore's Law.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 13:27]

[Neko Koneko]

Serieus? 64 bit architectuur is in 1999 aangekondigd, en in 2000 geïntroduceerd. 32 bits pc-architectuur is daarmee echt zwaar verouderd. Ik ben gezien wet van Moore zwaar verbaasd dat we geen 128 architectuur in onze pc's hebben vandaag de dag.

Waarom? De enige echte limiet van 32-bits was de 4GB adresruimte. Dit is bij 64-bit 16.8 miljoen TB. Die limiet komen we voorlopig nog niet tegen. Als je kijkt naar hoe lang het al duurt voordat we van 32-bit over zijn naar 64-bit kun je zelf ook wel nagaan dat wanneer je om de paar jaar een nieuwe architectuur introduceert "omdat het kan", het alleen maar een grotere warboel wordt

edit: wat ik wil zeggen is dat de andere voordelen die 128-bits misschien zou hebben t.o.v. 32-bits zeer waaschijnlijk teniet worden gedaan door het feit dat je opeens met 3 verschillende architecturen opgezadeld zit terwijl het blijkbaar al lastig is om van 32-bits volledig over te gaan op 64-bits Je zou op het 128-bits systeem waarschijnlijk compatiblity lagen voor zowel de 64-bits als de 32-bits software moeten laten draaien, hallo overhead en tot ziens eventuele performance winst

[Reactie gewijzigd door Neko Koneko op 22 juli 2024 13:27]

[Verwijderd]

32 bit software draait op een 64 bit OS zonder prestatieverlies. Het is en blijft x86 dus van echte emulatie is geen sprake. Bovendien is die geheugengrens helemaal niet relevant omdat je ook met 32 bit prima veel meer dan 4 GB RAM kunt aanspreken. Zo ondersteunen oude Windows Server versies voor x86 gewoon 64 GB RAM. Linux idem. Dit dankzij PAE oftewel Physical Address Extention. Die 4 GB is eigenlijk meer een kunstmatige grens dan een hardware grens door gewoon PAE-ondersteuning achterwege te laten.

[borft]

Dit is niet zondermeer waar. Je claim geldt op x86-64, omdat er bij het ontwerp specifiek rekening is gehouden met backwards-compatibility. Op andere 64 bits platforms gaat deze claim zeker niet zonder meer op.

Overigens is het zelfs op x86-64 niet zonder meer zo dat er geen prestatie verlies is. Bijvoorbeeld doordat meer geheugen nodig is voor "grotere" pointers.

[Verwijderd]

Uiteraard, maar het gaat hier dan ook exclusief over x86, de enige relevante desktop-architectuur van het moment. IA64 is zeer slecht in het emuleren van x86 waardoor het (helaas) nooit is aangeslagen. Dat heeft echter niets met bitlengte te maken.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 13:27]

[borft]

Ik heb het ook niet over ia64, maar over x86-64, ook wel amd64 genoemd. Dit is een uitbreiding op x86, waarbij 64bits instructies zijn toegevoegd.

Bij het initiele ontwerp van AMD is er rekening gehouden met een legacy modus die voorziet in een mogelijkheid om 32 bits processen te kunnen draaien op de 64bit processor.

@2fish: helemaal mee eens. Maar de andere 64bit platformen hebben dan ook niet het legacy x86 (i386) als basis.

[Reactie gewijzigd door borft op 22 juli 2024 13:27]

[Verwijderd]

Op andere 64 bits platforms gaat deze claim zeker niet zonder meer op.

[Dreeke fixed]

De enige echte limiet van 32-bits was de 4GB adresruimte.

Dit klopt dus niet, met bijna elke processor kan je met een 32 bit OS toch meer dan 4GB adresseren, Physical Address Extension (PAE) heet dat.
Dit zit alleen niet in Windows, maar zeker Ubuntu heeft kernels waar dat in zit.

[Reactie gewijzigd door Dreeke fixed op 22 juli 2024 13:27]

[PolarBear]

Serieus? 64 bit architectuur is in 1999 aangekondigd, en in 2000 geïntroduceerd.

De eerste processoren met 64 bits waren er in 2003, en dat waren AMD Opterons. Server/workstation processoren. Intel volgde in 2004. Echte doorbraak in de consumentenmarkt (onder andere mobiel enzo) was eerder richting 2006-2008.

Ik ben gezien wet van Moore zwaar verbaasd dat we geen 128 architectuur in onze pc's hebben vandaag de dag.

Wat heeft de wet van Moore met instructie grootte te maken?

[servies]

Even een verbetering:
De eerste 64 bits processoren waren geen AMD Opterons en geen Intel Itaniums...
De eerste 64 bits processoren waren er minimaal 10 jaar eerder, DEC Alpha is geintroduceerd in 1992 en Mips had de R4000 in 1991 al...
En dan hebben we het nog niet over de Crays....

[Reactie gewijzigd door servies op 22 juli 2024 13:27]

[nelizmastr]

Eerste 64-bit systemen waren Intel's Itaniums en die waren er al een heel stuk eerder dan de AMD'tjes. Was weliswaar geen x86, maar ia64, maar wel 64-bit.

[Reactie gewijzigd door nelizmastr op 22 juli 2024 13:27]

[freaky]

MIPS en SPARC waren er eerder.

https://en.wikipedia.org/wiki/64-bit_computing

[borft]

Ik had in de jaren 90 al een setje DEC (later Compaq, tegenwoordig HP) Alpha's. Die waren ook al 64 bit. Kon je leuk DEC OSF op draaien

[nelizmastr]

Ah nice. The more you know

[freaky]

Tja word oud geloof ik. Heb er nog weleens achter gezeten ook .

[praseodymium]

Itanium gebruikte echter de IA-64 architectuur die nooit echt groot is geworden buiten high-end markten. x86-64, de 64-bit architectuur die we nu allemaal gebruiken, is inderdaad pas in 2003 in de eerste CPUs (Opterons) beschikbaar gekomen.

[Snow_King]

Ik snap het ook echt niet. Heb al jaren geen 32-bits systeem meer op gezet.

[SirNobax]

Ik ben gezien wet van Moore zwaar verbaasd dat we geen 128 architectuur in onze pc's hebben vandaag de dag.

Een CPU architectuur (ALU/registers/etc) volledig 128-bit maken is onpraktisch en kost een hoop cpu oppervlakte wat niet word benut omdat we lang niet overal zulke precisie/bandbreedte/groottes nodig hebben, wat ten nadele komt van de (performance van) parallelisme.

Wat cpu-bakkers overigens al lang doen is hetgene vergroten wat vergroot moet worden, Intel heeft bijvoorbeeld al jaren 256-bit SIMD registers en doet instructies voor 128/256-bit berekeningen met behulp van AVX/SSE.

[Reactie gewijzigd door SirNobax op 22 juli 2024 13:27]

[Verwijderd]

Kijk eens verder dan je neus lang is intel atoms hebben sinds wanneer 64bit ondersteuning? nog niet heel lang, een nog betere vraag Hoeveel Arm cpus hebben 64 bit aanboord? Juist dat is bijzonder weinig. Ik vind het niet erg verstandig van Google.. Het duurt nog een aantal jaar voor 32 bit hardware echt uit gefaseerd is.

[batjes]

IA64 != AMD64. De eerste chip met AMD64/X86-64 instructies is pas in 2003 uitgebracht.\

Tevens kon Windows 2003 32bit rustig meer dan 4GB geheugen aansturen. Dit is geen direct limiet van 32bit.

[Foske76]

Je hebt al lang een 128 bit architectuur, sterker nog, je hebt een 512 bit architectuur als je een moderne Intel processor koopt. Niet voor je adresbus, om de simpele reden dat meer dan 2^64 bytes voorlopig voor niemand betaalbaar zal zijn, en zelfs virtueel het niet interessant is om zoveel geheugen te ondersteunen. Je hebt met 64 bit adresbussen al last van het IPv6 effect: Je processor heeft zoveel virtueel geheugen dat er erg slordig mee wordt omgesprongen.

Voor je data zitten we al lang boven de 64 bit. Alleen is er totaal geen toegevoegde waarde voor 256 of 512 bit integer of floating point berekeningen, dus is het geimplementeerd als Single Instruction Multiple Data instructies (MMX, SSE 1-4, AVX, AVX-512). Je data bus is op de plekken waar het er toe doet al lang 256 of 512 bit. Alleen: Het doet het er op veel plekken niet toe.

[diyoo]

Ik moest grinnikken om de knuppel die je in het hoenderhok gooit. (en de serieuze reacties daarop door mensen wiens sarcas-o-meter niet functioneert).

OT: Het lijkt me een logisch stap. Kan me niet herinneren wanneer ik voor het laatst een 32-bit systeem gebouwd/geinstalleerd heb. Je ziet sowieso al steeds meer dat applicaties niet meer voor 32 bit uitkomen, en terecht w.m.b. De techniek is inmiddels >15jr oud en heeft vooral qua geheugenadressering teveel beperkingen. Nu houd ik zelf van een overzichtelijke hoeveelheid tabs in mijn browsers, maar ik zie regelmatig collegae met >40 tabs open.

[Verwijderd]

Kan me niet herinneren wanneer ik voor het laatst een 32-bit systeem gebouwd/geinstalleerd heb. Je ziet sowieso al steeds meer dat applicaties niet meer voor 32 bit uitkomen, en terecht w.m.b. De techniek is inmiddels >15jr oud en heeft vooral qua geheugenadressering teveel beperkingen.

Zakelijk gezien ligt de focus voor client-OS-en nog steeds op Windows. Omdat de footprint van een 32-bits Windows client flink kleiner is dan de 64 bits versies wordt in veel grote VDI omgevingen nog steeds voor een 32-bits Windows gekozen.

[batjes]

Het footprint verschil tussen 32bit en 64bit is met Windows 10 bijna verwaarloosbaar.

[MadEgg]

Onzin, met PAE kun je tot 4GB per process alloceren. Aangezien elke tab in een eigen process draait in Chrome is dat niet zo'n probleem.

[Reactie gewijzigd door MadEgg op 22 juli 2024 13:27]

[g4wx3]

PAE is een lap middel, en het is minder efficiënt
Ook Windows heeft PAE ooit ondersteund, maar dit is gestopt ten voordele van stabiliteit problemen met drivers (closed source)

[Reactie gewijzigd door g4wx3 op 22 juli 2024 13:27]

[PolarBear]

Windows ondersteund nog steeds PAE, alleen inde 32bits versies van Windows wordt er maximaal 4 Gb gebruikt, uit licentietechnische overwegingen. Daarbij klopt het dat bepaalde drivers onstabiel kunnen zijn omdat er geen rekening mee is gehouden dat er meer dan 4Gb RAM kan zijn.

[ReDnAx1991]

Volledig ontopic en ik ben het helemaal met je eens, ik heb ook het idee dat hier een achterliggende gedachte achter zit.

Wel vind ik het natuurlijk tijd dat iedereen naar x64 overstapt.

[CAPSLOCK2000]

Ik weet niet of iedereen hier weet wat Chromium precies is.
Chromium is het origineel.

Chromium is geen open-source kloon van Chrome en het is ook geen versie van Chrome waar de stukken van Google uit zijn gesloopt. Chromium is juist de officiele naam van het hele project en het wordt door Google zelf ontwikkeld. Er zijn verschillende browsers die op het Chromium-project zijn gebaseerd. De bekendste is Chrome van Google. Dat is dus Chromium met een aantal Google-specifieke uitbreidingen.

Het is dus een misverstand dat Chromium een gecastreerde versie van Chrome is. Het werkt juist andersom. Chrome is Chromium met wat extensies en een deel daarvan kun je ook zelf aan Chromium toevoegen. De render-engine is precies hetzelfde en Chromium gebruikt typisch de nieuwste versie. Overstappen van Chrome naar Chromium zal voor de meeste (zeldzame) gebruikers dus een non-issue zijn. Alleen als je veel Google-diensten gebruikt via Chrome-extensies ga je misschien iets missen.

[arjan1995]

En Flash natuurlijk. Dat wordt bij Chrome altijd netjes meegeleverd en bij Chromium niet! Zeker onder Linux is het lastiger om Flash te installeren.

[CAPSLOCK2000]

Klopt, maar Flash wordt steeds minder belangrijk. Telefoons kunnen ook zonder en zelfs Adobe wil er van af. Voorlopig kunnen die paar 32-bit Linux gebruikers met Chrome daar mee vooruit. De meesten gebruiken al lang de 64-bit versie en die blijft wel.

[batjes]

Vergeet de HTML5 video DRM die o.a. Netflix gebruikt niet.

[Nitroglycerine]

Op zich logisch daar de grote distributies ook niet meer als 32 bit uitkomen (RHEL met zijn aanverwante distro's) of 32 bit alleen maar als alternatieve keuze aanbieden (zoals Ubuntu). Daarnaast maakt een 64 bit OS het beste gebruik van een 64 bit CPU. Ik verwacht dat steeds meer software fabrikanten de ontwikkeling van 32 bit applicaties zullen stoppen.

[Verwijderd]

Dat x86 32-bit niet meer ondersteund is meer dan logisch.

Maar ARM 32-bit is nog volop in de markt en daar draait ook vaak nog wel chrome op. Vaker denk ik dan op X86 32-bit. Omdat elke x86 distro meestal al 64bit is vanwege dat de meeste x86 processors van deze tijd toch wel 64bits zijn. ARM loopt daar iets mee achter.

[Jvann]

Kdag al, grootste deels van de Smartphones zijn nog 32-bit en deze worden ook nog flink verkocht. Tzou een beetje raar zijn als die allemaal niet meer ondersteund worden.

[Reactie gewijzigd door Jvann op 22 juli 2024 13:27]

[RMvanDijk]

De meeste smartphones draaien volgens mij op ARM architectuur, ik denk niet dat ze die versie van chrome laten vallen, alleen de x_86 32 bit versie.

[Neko Koneko]

De meeste smartphones draaien volgens mij op ARM architectuur, ik denk niet dat ze die versie van chrome laten vallen, alleen de x_86 32 bit versie.

Sterker nog, dit bericht gaat specifiek om de Linux-versie. Waarschijnlijk blijven de 32-bits Windows versie en 32-bits Android versie voorlopig nog even rondhangen.

[Mitsuko]

Verbaast me op zich niet. Vond het eerlijk gezegd al een teleurstelling dat Windows 10 ook in een 32-bit versie uitkwam - als Windows 10 inderdaad de laatste Windows wordt zoals de geruchten gingen, dan wordt het nog lastiger om van 32-bit af te komen (omdat software er niet van uit kan gaan dat op Windows 10 alleen 64-bit nodig is).

[Reactie gewijzigd door Mitsuko op 22 juli 2024 13:27]

[Loller1]

Waarom is dat teleurstellend? Is het nadelig voor jou dat er nog een 32bit versie is? Nee. Het maakt niet uit of ontwikkelaars ervanuit kunnen gaan of het wel of niet 64bit ondersteund, die versie moet nog steeds apart worden ontwikkelden om er gebruik van te maken.

Daarbij kan Microsoft in de toekomst ook gewoon zeggen dat ze stoppen met het uitbrengen van nieuwe versies op basis van 32bit. Het is niet alsof Microsoft nu voor altijd aan de systeemeisen van Windows 10 build 10240 vast zit.

[Mitsuko]

32-bit is niet zonder baggage. Je kan er niet vanuit gaan dat processoren SSE of SSE2 ondersteunen, waardoor het lastig wordt om de precisie van wiskundige functies consistent te krijgen, je kan geen gebruik maken van address space randomization om processen te beschermen tegen aanvallen, de pointers zijn te klein om extra informatie in op te slaan, je hebt een 32-bit versie van iedere JIT compiler nodig, en die moeten zich in bochten wringen om genoeg registers beschikbaar te hebben.. en er is vast nog meer waar ik nu niet aan denk.

Dus ja, als ontwikkelaar is het onhandig om 32-bit te moeten ondersteunen. Als Windows 10 alleen als 64-bit versie beschikbaar zou zijn, dan kan je de ondersteuning voor 32-bit op hetzelfde moment staken als de ondersteuning voor eerdere versies van Windows. Dat zal hoe dan ook nog jaren duren, maar nu is die optie er dus niet.

[Olaf van der Spek]

Je kan er niet vanuit gaan dat processoren SSE of SSE2 ondersteunen,

Waarom niet? Kun je toch gewoon als eis stellen voor jouw app?
En als ze SSE2 (en dus x64?) niet ondersteunen is het toch logisch dat ze 32-bit Windows draaien? Jij wilt die mensen dus verplichten hun hardware te upgraden?

de pointers zijn te klein om extra informatie in op te slaan,

Dan sla je het toch gewoon buiten de pointer op?

[Mitsuko]

Waarom niet? Kun je toch gewoon als eis stellen voor jouw app?
En als ze SSE2 (en dus x64?) niet ondersteunen is het toch logisch dat ze 32-bit Windows draaien? Jij wilt die mensen dus verplichten hun hardware te upgraden?

Je kan dat als eis stellen, maar dan moet je ook weer wat inbouwen om te controleren dat het programma zonder SSE2 niet draait. Uiteindelijk is het toch onmogelijk om alle software te blijven draaien op oude hardware - ik zeg alleen dat het makkelijker zou zijn voor ontwikkelaars als de keuze gekoppeld was aan het besturingssysteem.

Dan sla je het toch gewoon buiten de pointer op?

Dat is uiteraard mogelijk, maar dan kan je aan de pointer dus niet zien wat voor stukje geheugen het is. Dan moet je dat dus of opzoeken in een tabel, of je moet die gegevens meesturen. Dan heb je dus op 64-bit een directe pointer en op 32-bit een struct met een pointer erin. Dat voegt allemaal complexiteit toe. Niet het einde van de wereld, maar ook niet gratis.

[batjes]

SSE2 is een Windows 10 vereiste. Dit was voor Windows 8 al een vereiste. Dus je kunt er gewoon vanuit gaan dan Windows 10 32bit SSE en SSE2 ondersteund. Je moet je in bochten wringen wil je Windows 10 instaleren op een SSE-loos systeem.

ASLR werkt gewoon in 32bit Windows.

[Olaf van der Spek]

Waarom wil je van 32-bit af?
De meeste apps hebben genoeg aan 32-bit..

[Mitsuko]

Ik wil niet van 32-bit applicaties af, alleen 32-bit besturingssystemen. Zo lang Windows 32-bit applicaties ondersteunt is het voor ontwikkelaars geen extra moeite. Andersom is het wel vervelend om een 32-bit versie aan te moeten bieden terwijl alle ontwikkelaars de 64-bit versie gebruiken, alleen omdat een significant percentage gebruikers 'per ongeluk' op een 32-bit OS zijn blijven steken (terwijl hun hardware gewoon geschikt is voor 64-bit applicaties).

[Olaf van der Spek]

Andersom is het wel vervelend om een 32-bit versie aan te moeten bieden terwijl alle ontwikkelaars de 64-bit versie gebruiken,

Hoe vervelend en waarom is dat?

Als RAM weer wat goedkoper wordt en het 'minimum' naar 8GB gaat verdwijnt 32-bit vrijwel vanzelf denk ik, maar op dat punt zijn we nog net niet.

Waarom zou je op een machine met 2GB RAM een 64-bit OS gaan draaien? Qua geheugengebruik is dat alleen maar minder efficient.

[Mitsuko]

Zie mijn antwoord op Loller1 hierboven. Als je beperkt bent tot 2GB RAM dan is 64-bit inderdaad iets minder efficiënt, maar dat valt op zich wel mee denk ik. Daarnaast is de grootte van de addresseringsruimte onafhankelijk van de hoeveelheid fysiek geheugen, dus daar kunnen programma's nog steeds baat bij hebben.

[batjes]

En gezien Windows 10 een AIO OS is moet dit op zoveel mogelijk hardware draaien, waaronder portable meuk... Dan kun je er vandaag de dag niet vanuit gaan dat 32bit niet nodig is. Geen 32bit Windows 10 maken zal MS een bult klanten kosten omdat er nog pijnlijk veel hardware is met slechts 32bit CPU's...

[borft]

omdat je dan moet emuleren, of eigenlijk je CPU in een legacy mode moet draaien.

[Vale vista]

Windows server is al sinds 2008R2 64 bit only

[Mitsuko]

Voor servers is het waarschijnlijk makkelijker te rechtvaardigen, die gebruiken toch vaak veel geheugen. Microsoft wil duidelijk heel graag iedereen op Windows 10 krijgen, ook computers met heel oude hardware.. toch vind ik het jammer.