Debian 32 oder 64bit?

[flaschenpfand24521]

Hallo zusammen,

möchte mir gerne eine Debian-Desktop-OS zusammenbauen. Es ist ein starker Rechner (x6 Phenom, 8GB DDR3-Ram). Jetzt stellt sich mir die Frage ob ich nicht ein 64bit OS installieren soll bezüglich der vollen RAM-Nutzung. Ist das mittlerweile empfehlenswert oder noch nicht wirklich ausgereift. Gibt es mit 32bit-Debian ein möglichkeit zur Nutzung des vollen RAMs?

[ben.a]

siehe z.B. http://debianforum.de/forum/viewtopic.php?f=27&t=126279

[syssi]

Die Frage findest du mehrfach im Forum, wenn du die Suche bemühst. Kurze Antwort: 32bit + 686-pae Kernel kann mehr als die ueblichen ~2GB adressieren. Empfehlen würde ich dir aber ein 64bit System, da die Architektur amd64 mit Compiler-Flags gebaut wird, welche spezielle auf 64bit CPUs und deren Feature zugeschnitten ist. Man nutzt deshalb seine CPUs effizienter, als man es bei i686/i386 tun wuerde.

[flaschenpfand24521]

Danke schonmal. Wie sieht es im Alltag mit Programmen aus? Bekommt man mit der 64bit-Variante alles zum laufen? Ich meine damit sämtliche .deb-Packete als auch exotische, selbstcompilierte Programme... Fand das mit den .deb aus den Quellen (bisher nur mit 32bit) wirklich eine feine Sache und es wäre schade wenn ich alles nur noch mit "Workarounds" zum laufen bekommen würde...

Unter Win7-x64 werden ja 32bit-Anwendungen "emuliert" oder so ähnlich. Ist das mit Debian-x64 auch möglich?

[syssi]

Du kannst problemlos auf einem 64bit System 32bit Userland betreiben. Wo es also keine 64bit Loesung gibt, da greifst du auf 32bit zurueck.

[flaschenpfand24521]

Ok, dann spricht nichts dagegen die 64bit-Variante zu wählen...

Danke euch für die Antworten!

[DeletedUserReAsG]

Ansonsten sind alle Pakete, von denen es eine i386-Variante auf debian.org gibt, auch als amd64 vorhanden.

cu,
niemand

[Kermit24]

Ich hänge mich mal hier ran, da ich mich von diesen Beitrag bei der Installation beeinflussen gelassen habe. Habe auf meinem neuen Rechner (i5-Prozessor) nun auch die amd64-Version installiert und bin überhaupt nicht begeistert davon. Lange hat's gedauert, bis ich herausgefunden habe, warum er keine 32bit binaries ausführen konnte! Denn statt "falsche Architektur" oder ähnliches, hat mir bash und zsh nur sowas gemeldet wie "./program nicht gefunden", als ob es gar nicht da wäre! Dachte erst, es läge an Berechtigungs- oder Pfadproblemen. Daran sollte man unbedingt noch mal arbeiten, dass man eine anständige Fehlermeldung bekommt!

Jedenfalls habe ich dann nach langer Recherche endlich rausgefunden, dass man ia32-libs noch installieren muss. Kleinere 32bit binaries laufen jetzt auch! Aber ich bekomme z.B. das offizielle(!) Seamonkey (gibt es nur in 32bit) einfach nicht zum Laufen! Ich möchte (wegen den offiziellen Updates) auch keine inoffiziellen 64bit Builds oder gar iceape nutzen und so bleibt mir nun mal nur die 32bit Variante.
Beim Starten meldet mir seamonkey nun, dass es libxul.so nicht findet. xulrunner ist aber installiert - allerdings auch aus dem 64bit repository!
Muss ich jetzt noch irgendwie das 32bit repository hinzufügen und alles doppelt installieren? Also ich bin kurz davor das 64bit System runterzuwerfen und direkt wieder i686 zu nehmen. Dass die Kompatibilität so schlecht/kompliziert ist, hätte ich nicht gedacht

[Cae]

Hier ging es doch wohl offensichtlich um das Betriebssystem und die "mitgelieferte" Software, also den offiziellen Repositorys. Da ist es tendenziell sinnvoller, amd64 zu nehmen, wenn die CPU das kann und man >3 GB RAM hat. Da gibt es noch die Overhead-Sache, dass i386 da effizienter sein kann.

Wenn du andere Software einsetzen willst, die es nur als 32-bittige Version gibt, ist das eher ein abweichendes Problem. Das muss man halt wissen. Die angesprochenen ia32-libs bringen wohl nicht alle Funktionen mit.

Die Lokalisierungen sind tatsächlich nicht so toll, Test mit

Code: Alles auswählen

tmp/coreutils/bin/cat: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, BuildID[sha1]=0x2ce1d8c50e4b0550c526f20aea9090abb4d2bf5e, stripped
3.2.0-2-amd64 x86_64
$ readlink -f $(which sh)
/bin/dash

ergibt das:

Code: Alles auswählen

zsh% LC_ALL=C tmp/coreutils/bin/cat
zsh: exec format error: tmp/coreutils/bin/cat
zsh% tmp/coreutils/bin/cat
zsh: fehler im Format der Programmdatei: tmp/coreutils/bin/cat
sh$ tmp/coreutils/bin/cat # ist wohl schon C
tmp/coreutils/bin/cat: 1: tmp/coreutils/bin/cat: Syntax error: word unexpected (expecting ")")
bash$ tmp/coreutils/bin/cat
bash: tmp/coreutils/bin/cat: Kann die Datei nicht ausführen.
bash$ LC_ALL=C tmp/coreutils/bin/cat # kein Unterschied, wtf?
bash: tmp/coreutils/bin/cat: Kann die Datei nicht ausführen.
bash$ tmp/coreutils/bin/cat # hier ist die Bash schon mit LC_ALL=C gestartet
bash: tmp/coreutils/bin/cat: cannot execute binary file

Eindeutig ist da übrigens immer

Code: Alles auswählen

bash$ tmp/coreutils/bin/cat || echo $?
bash: tmp/coreutils/bin/cat: cannot execute binary file
126

der Rückgabewert! (okay, die sh spielt da nicht mit, aber die ist auf einem total falschen Dampfer und versucht das als Shellskript zu interpretieren)

Gruß Cae

[wanne]

Also i686 ist einfach Tefchnologie die seit 5 Jahren tot ist. (Ende 2004 überholten bei AMD die 64Bit die 32Bit Produktion.) (Jetzt kann man sich überlegen wie lange so ein Prozessor im schnitt lebt und wieviele 32Bit Prozessoren dann jetzt noch leben...)
Auf den 64Bit Prozessoren 32Bit Anwendungen laufen zu lassen ist auch dämlich (Die Performanzeeinbusen sind zwar nicht erheblich aber warum? Das klngt für mich wie ich installier mir Squeeze um dann Lenny drauf zu emuieren.)

@Kermit24: Versuche mal ein 64Bit-programm unter nem 32Bit system auszuführen...
Zu Seamonkey: Den gibt's als Source und der hat somit gar keine Architektur. Die Binarys sind in erster Linie für Windoofuser, die für 64Bit draufzahlen. Und da man sich den Anstrich geben will, dass man auch linux unterstützt werden halt noch Linux-binarys. Nutzen tut die niemand denke ich mal. (So klein wie die sind sind die auchnoch dynamisch gelinkt, sodass man exakt die richtige Version der entsprechenden Lib installiert haben muss was bei der Vielfalt an distros eher unwahrscheinlich ist. Ich wette auch unter nem 32Bit System bekommst du ordentlich Ärger mit denen.) Wer für Linux nutzer 32Bit Anwendungen anbietet will nunmal keine Linux-Nutzer haben sondern mit Platformunabhängigkeit werben können. Solche Software will man im Normalfall gar nicht haben.

[debdog]

Eine Seamonkeyversion für 64bit findet sich auf der Internetseite[1], allerdings etwas versteckt, unter "Contributed builds (other platforms)". Diese ist englisch aber die deutschen Sprachdateien lassen sich nach der Anleitung "Installationsanleitung: Language Packs"[2] einfach nachinstallieren.

Dies ist wohl der einfachste Weg, den Seeaff' auf einem 64bit-OS zu installieren. Nimmt man die 32bit-Version, hat man später Probleme mit den Plugins die im Debianrepo enthalten sind,

[1] http://www.seamonkey-project.org/releases/#contrib
[2] http://www.seamonkey.at/download/

Edit: den Tatsachen entsprechend angepasst.

[Kermit24]

Die offizielle Seamonkeyversion für 64bit findet sich auf der Internetseite[1], allerdings etwas versteckt, unter "Contributed builds (other platforms)". Diese ist englisch aber die deutschen Sprachdateien lassen sich nach der Anleitung "Installationsanleitung: Language Packs"[2] einfach nachinstallieren.

Nein, die 64bit Version habe ich durchaus gesehen! Allerdings ist es eben gerade KEINE offizielle Version, wie es doch da direkt steht:
"Note: These are unofficial builds and may be configured differently than the official SeaMonkey builds. Please read their "readme" files for further information."

Ich nutze schon seit mehreren Jahren die offizielle 32bit Version auf meine Alltagsrechner, die allesamt eh keine 64bit Unterstüzung haben. Vorteil ist die schnell Updatebarkeit: Ich bekomme sofort gemeldet, wenn eine neues (Sicherheits-)Update verfügbar ist und kann es quasi mit einem Klick aus dem Programm heraus sofort installieren! Mit keinem debian hatte ich je Probleme, bzw. jemals mit dem offiziellen Seamonkey "ordentlich Ärger" mit irgendwelchen libs!

[catdog2]

Nimm Wheezy da kannst du so viele 32 bit libs installieren bis du platzt oder so. http://wiki.debian.org/Multiarch/

(Jetzt kann man sich überlegen wie lange so ein Prozessor im schnitt lebt und wieviele 32Bit Prozessoren dann jetzt noch leben...)

Intel Atom.

[wanne]

@Kermit24: Du wirst es mir nicht glauben, aber der iceape updatet sich ganz ohne klick, irgend wann mitten in der Nacht, wenn man nicht gerade vor dem Rechener sitzt und man ihn benutzen möchte....

Ich nutze schon seit mehreren Jahren die offizielle 32bit Version auf meine Alltagsrechner, die allesamt eh keine 64bit Unterstüzung haben.

Darf man fragen wieviele Minuten der seamonky dadrauf zum starten braucht? So mit Hardware, damit ich das nachvollziehen kann.

Intel Atom.

Es gibt auch ARM Prozessoren. Irgend welche nieschen gbt es immer. Aber die überwiegende Mehrheit ist eben amd64. (Im übrigen ist mittlerweile auch der Intel Atom amd64.)
Ich finde es halt Sinnlos Systeme von vor 5 Jahren zu nutzen nur weil es 3 Firmen gibt, die meinen sie müssten auschließlich Software für Hardware von vor 5 Jahren herstellen...

[wanne]

Ich muss mich verbessern. Eine Firma. Skype hat's mittlerweile geschafft 64Bit Binarys anzubiten. Kaum hat der Anbieter aus Redmond 64Bit Systeme kann man auch bei Skype amd64....
Und wenn man jetzt unbedingt Die SW von Mozilla drekt haben will, dann darf man die sich ja compilieren...
Ist alles kein Problem. Finde es da auch absolut verschendung irgend welche 32Bit libs nachzuinstallieren.

[Kermit24]

Ich nutze überwiegend einen FitPC2i mit Atom Z530 SingleCore 1,6GHz, der rund um die Uhr läuft mit den drei Ressourcenfressern kmail, liferea und seamonkey auf lxde-Oberfläche läuft. Ja, zum Starten braucht der Browser auf dem "schwachen" System in der Tat einige Sekunden. Aber i.d.R. bleibt er dann immer offen! Eine Zeit lang habe ich zu Anfang auch IceApe aus dem Repository genutzt, hatte aber nur Probleme damit. Der hat aber gefühlt genauso lange zum Starten gebraucht wie der offizielle Seamonkey!
Dieser Rechner reicht mir zumindest für meine tägliche Arbeit (Websurfen, Emails-/Briefe schreiben, Drucken, Scannen, wenig Grafikbearbeitung mit Gimp, usw.).

Dann habe ich noch ein IBM Thinkpad PentiumM 1,2GHz, ein Netbook Samsung NC10 (Atom) und noch zwei mehr oder weniger ausgemusterte Rechner (Tualatin P3 1,2GHz+1,3GHz). Meine Frau nutzt einen Pentium4 2GHz. Alles i32-Maschinen und auf allen nutze ich ausschließlich debian! Wieso muss man denn immer die neuste HW nutzen? Die gute Unterstüzung älterer Hardware ist doch gerade das schöne an Linux-Systemen!
Der gebrauchte i5 Vierkern-Rechner, den ich gratis geschenkt bekommen habe, ist nun jedenfalls mein aller erster mit i64-Architektur! Und da habe ich den Worten von "syssi" wohl leider zu viel Glauben geschenkt.

[wanne]

Naja Intel hat ein bisschen Länger gebraucht. Der Atom wurde ja schon als Ausnahme genannt und die Thinkpads sind halt eher langlebig. Bin trotzdem überzeugt, dass mittlerweile über 90% (dh. jeder 10. noch nicht...) der im betrieb befindlichen Rechner 64Bit Prozessoren sind. (Ich kenne außer mir einen einzigen (meinen Opa), der noch eine 32Bit Kiste produktiv hat.) Leider gibt's die einzige schöne Statistik zu eingesetzten Prozessoren bei Seti und die ist nicht wirklich representativ...

Der hat aber gefühlt genauso lange zum Starten gebraucht wie der offizielle Seamonkey!

Ja der soll ja auch nciht schneller sonder stabieler laufen. Und eben die Problenme, die du jetzt hattest (von wegen mein runtergeladenes Progrmm passt ncht zum Rest vonmeinem System) beheben. Für letzteres wurde die Paketverwaltung eingerichtet...
Wenn du den IceApe verwendet hättest hättest du keine Probleme so schon. Leistung fressen sie die gleiche. Spricht doch eindeutig für den IceApe.

PS: i64 klingt so nach dem toten IA64. Ist glaube ich weniger verwirrend, wenn du amd64 oder x86_64 verwendest.

[nudgegoonies]

Ich muss mich verbessern. Eine Firma. Skype hat's mittlerweile geschafft 64Bit Binarys anzubiten. Kaum hat der Anbieter aus Redmond 64Bit Systeme kann man auch bei Skype amd64....

Ich bin sofort auf die Internetseite von Skype gestürzt und finde da immer noch keine 64 Bit Version. Die haben zwar 64 Bit Pakete für Ubuntu und Debian aber das sind immer noch nur die 32 Bit Versionen, welche als 64 Bit paketiert sind damit man nicht force-archicture angeben muss um sie zu installieren und sie haben das Paket ia32-libs als Abhängigkeit.

64 Bit schluckt mehr RAM(!) Aber die wenigsten Leute haben wirklich mal den Speicherverbrauch auf identischer(!) Hard- und Software getestet.

64 Bit schluckt unter Linux aber deutlich(!) mehr RAM wenn man 32 Bit Software laufen hat. Ich hatte Multiarch erst auch falsch verstanden, und das, obwohl ich Informatik studiere! Ich habe schon öfter darüber gegrübelt ob es nicht irgendwie möglich sein müsste, dass ein 32 Bit Programm die 64 Bit Libraries nutzen kann. Aber es scheint wohl nicht möglich zu sein. Das heißt, ein 32 Bit Programm braucht auch alle sein Libraries in 32 Bit. Und wenn dann ein 32 Bit Programm auch noch ständig im Vordergrund (Mozilla) oder gar im Hintergrund (Skype) läuft, wird da komplett die Speicherersparnis durch Shared(!!!) Libraries ausgehebelt. Wenn sagen wir mal 30 64 Bit Programme laufen und die LIBC nutzen, dann wird deren Codesegment nur einmal geladen und in den Speicher aller 30 Prozesse eingeblendet. Aber bei 32 Bit Prozessen unter 64 Bit werden beim ersten Start eines 32 Bit Prozesses ja erstmal alle(!) 32 Bit Libraries nachgeladen. Bei Skype ist das die LIBC, QT, X11, V4L, ALSA, etc., etc. und die hängen ihrerseits auch wieder von Libraries ab und die auch wieder, etc. Ich verfluche jedes 32 Bit Paket was ich noch habe incl. WINE!

[Luxuslurch]

wanne schrieb:
ch muss mich verbessern. Eine Firma. Skype hat's mittlerweile geschafft 64Bit Binarys anzubiten.

Ich muss dich verbessern: afaik ist das immer noch die alte Mogelpackung, in der einfach nur die 32-bit-libs als Abhängigkeiten mitgezogen werden...

ferner:
Auf den 64Bit Prozessoren 32Bit Anwendungen laufen zu lassen ist auch dämlich

Nein, sondern einfach nur praktisch. Zum Beispiel muss ich beim o.g. Programm einen Starter erstellen, der mir die richtigen v4l-Treiber mittels im voraus lädt, sonst geht meine Webcam nicht.

Mal davon abgesehen gibt es sicherlich viele Anwendungsmöglichkeiten, die 64-bit tatsächlich ausnutzen - bei meiner Nutzung spüre ich nichts - außer ein, zwei praktischen Erleichterungen. Insofern würde ich es nicht gerade 'dämlich' nennen sondern vielleicht 'faul'. Da gehen die Meinungen sicher auseinander, aber manchmal habe ich das Gefühl, dass es einige fanatisierte 64-bit-Anhänger gibt. Da muss ich dann immer mit dem Kopf schütteln bzw. Zeigefinger wackeln

PS:

Windoofuser

Meinten Sie: Windows?

[Fjunchclick]

64 Bit schluckt unter Linux aber deutlich(!) mehr RAM wenn man 32 Bit Software laufen hat.

Na und?
Also ich zumindest habe mir meinen RAM gekauft, damit er benutzt wird.

[nudgegoonies]

Nein, sondern einfach nur praktisch. Zum Beispiel muss ich beim o.g. Programm einen Starter erstellen, der mir die richtigen v4l-Treiber mittels im voraus lädt, sonst geht meine Webcam nicht.

Bei mir klappt das sogar ohne dass ich irgendetwas machen muss. Vielleicht hängt es aber auch vom gewählten Treiber ab. Ich habe schon häufiger von diesem Problem gelesen. Ich weiß nicht wie lange es her ist, dass Du es das letzte mal ohne Starter probiert hast. Eventuell hat die neuste Version von Skype das Problem schon gar nicht mehr. Skype wurde dieses Jahr irgendwann mal aktualisiert. Da sind jetzt Squeeze und keine Lennypakete mehr.

Na und?
Also ich zumindest habe mir meinen RAM gekauft, damit er benutzt wird.

Aber es sollte auch effizient genutzt werden. Sowohl in Hinblick auf Speicherverbrauch als auch Geschwindigkeit. Dass es bei heutigen Maschinen an RAM nicht gerade mangelt macht die Situation ja nicht besser. Ein Vorteil an 64 Bit Debian ist ja unter anderem, dass der GCC standardmäßig alle CPU Befehle und Erweiterungen benutzt die alle 64 Bit Prozessoren gemeinsam haben (siehe SSE2) während das 32 Bit Debian ja auch noch auf einem alten Pentium 2 laufen muss und somit die moderneren Prozessoren gar nicht voll ausreizt (einige wenige Programme die extra Routinen mit Untertütgung für MMX, SSE2, etc. mitbringen mal ausgenommen). Dann hat 64 Bit auch noch mehr Register und auch noch diesen schnellen Syscall Befehl. Alles Dinge die ein Programm schneller machen. Aber wenn ein Programm doppelt so viel RAM schluckt (ich weiß, meistens ist es gar nicht doppelt so viel - aber halt mal als Beispiel) dann gibt es doppelt so viele Zugriffe auf den Speicher, doppelt so viele Cache-Miss, TLB-Miss (Pagefaults) welche alle wieder bremsen. Es geht mir nicht um den RAM Vebrauch an sich (egal ob 32 oder 64 Bit) sondern um die damit verbundenen Einflüsse auf die Geschwindigkeit.

P.S.
I mache hier auf der Arbeit von morgens bis Abends Profiling mit perf unter Linux - darum bin ich gerade so fixiert auf Speicherzugriffevents!

[Cae]

Das heißt, ein 32 Bit Programm braucht auch alle sein Libraries in 32 Bit. Und wenn dann ein 32 Bit Programm auch noch ständig im Vordergrund (Mozilla) oder gar im Hintergrund (Skype) läuft, wird da komplett die Speicherersparnis durch Shared(!!!) Libraries ausgehebelt. Wenn sagen wir mal 30 64 Bit Programme laufen und die LIBC nutzen, dann wird deren Codesegment nur einmal geladen und in den Speicher aller 30 Prozesse eingeblendet. Aber bei 32 Bit Prozessen unter 64 Bit werden beim ersten Start eines 32 Bit Prozesses ja erstmal alle(!) 32 Bit Libraries nachgeladen.

Bist du dir sicher, dass der komplette 32-bittige so-Stack geladen wird? Das macht doch gerade keinen Sinn, da kann man ein einzelnes 32-Bit-Programm gleich statisch bauen (oder, wenn man es schon baut, gleich auf x86_64 anpassen). Nach meiner Vorstellung werden separat für x32 und x64 jeweils unabhängig die von den Anwendungen benötigten shared libs geladen, so dass sich alle x32 und alle x64-Prozesse von demselben Speicher aus einbinden. D.h. das zweite..n-te Programm profitiert wieder vom shared-libs-Mechanismus.

Gruß Cae

[Clio]

...aber manchmal habe ich das Gefühl, dass es einige fanatisierte 64-bit-Anhänger gibt. Da muss ich dann immer mit dem Kopf schütteln...

Ja, so geht es mir auch.
Obwohl meine Hardware, ein AMD64 X2 6400 mit 8GB RAM, nicht alt oder unterdimensioniert ist, habe ich ein 32bit Sid als Arbeitssystem und ein zweites als Testsystem installiert. Diese 32bit sind über die Jahre gewachsen, viel "rumgeschraubt" und laufen perfekt und ohne Fehler. Ich käme nicht auf die Idee, diese durch ein 64bit zu ersetzen.
Zwischendurch habe ich immer mal eine dritte Partition mit 64bit, nur zu Testzwecken. Im Augenblick läuft ein ganz schmales Squeeze mit Moneyplex, da die Firma es nicht hinkriegt, die 32 bzw. 64bit Version auf neueren libglibs aus z.B. Sid zu starten.

Ich habe noch nicht feststellen können, daß es bei normaler Nutzung eines PC's irgendwelche Nachteile bzgl. Geschwindigkeit o.Ä. gegeben hätte. Das mag evtl. der Fall sein, wenn man beispielsweise aufwendige Videobearbeitung betreibt. Aber auch das Kompilieren meines Kernels ist in 10 Minuten erledigt.
Ich habe einige alte Programme, wie z.B. metalog, die es nur als 32bit gibt. Da würde ich mich ärgern, wenn ich die evtl. nicht mehr einsetzen könnte.
Mein Eindruck ist, daß bei "normaler" Nutzung ein 32bit genauso gut läuft wie ein 64bit System. Da wird viel überbewertet, und die User sind anschließend enttäuscht, wenn ihnen keine Änderungen auffallen.

[nudgegoonies]

Bist du dir sicher, dass der komplette 32-bittige so-Stack geladen wird? [...] D.h. das zweite..n-te Programm profitiert wieder vom shared-libs-Mechanismus.

Du hast natürlich Recht! Ich bezog mich aber auf den ersten Start eines 32 Bit Programmes unter 64 Bit OS. Sobald die nächste 32 Bit Anwendung gestartet, zieht die Speicherersparnis durch Shared Libraries natürlich wieder. Je mehr 32 Bit Programme man startet, umso mehr Libraries zieht das aber auch nach sich, und umso mehr Libraries hat man auch qasi doppelt (32/64 Bit) im Speicher.

Natürlich juckt das bei einem 8 GB System nicht. Genausowenig juckt es einen Motorradfahrer wenn sein 850 ccm Motor wegen Problemen am Vergaser 10% weniger Leistung hat. Ein 125 ccm Fahrer dagegen merkt das dagegen sofort. Mein PC ist leider nicht ganz so gut bestückt und PC4200 ECC-RAM ist sauteuer. Außerdem habe ich noch einen i386 Zweitrechner der fast paketidentisch zu meiner AMD64 Maschine installiert ist. Ich bin halt immer wieder mal erstaunt, wie wenig RAM sich Iceweasel auf der i386 Maschine gönnt, selbst wenn mehrere Tabs offen sind, während Iceweasel auf der AMD64 Maschine bei einer ähnlichen Tabanzahl 3/4 so viel RAM zieht, wie der i386 Rechner insgesamt hat

P.S.
Auch hier muss ich mich direkt selbst ermahnen, Iceweasel ist kein Benchmark und die Systeme mögen paketidentisch sein, aber die Hardware ist verschieden. Und wenn sowieso weniger RAM verfügbar ist verhalten sich auch die Programme anders und haben andere Cachstrategien, etc...

[wanne]

Und wenn sowieso weniger RAM verfügbar ist verhalten sich auch die Programme anders

Ja eben....
Es absolut humbug das zu vergleichen RAM der nicht genutzt wird ist verschwendeter RAM. Dementsprechend verhällt man sich nunmal anders wenn man mehr RAM hat.

h hatte Multiarch erst auch falsch verstanden,

Ja, ich hatte ja auch gesagt, dass man gar keine 32Bit SW nutzen soll.

Ich habe einige alte Programme, wie z.B. metalog, die es nur als 32bit gibt.

metablog gibts vom Hersteller nur als Source => es hat keine Architektur. Was du draus machst liegt alleine an deinen Compilerflags.

Mein Eindruck ist, daß bei "normaler" Nutzung ein 32bit genauso gut läuft wie ein 64bit System. Da wird viel überbewertet, und die User sind anschließend enttäuscht, wenn ihnen keine Änderungen auffallen.

Damit hast du vollkommen recht. Das ganze gilt aber eben auch umgekehrt.

Ich käme nicht auf die Idee, diese durch ein 64bit zu ersetzen.

Ja, genau deswegen rege ich mich so drüber auf. Wenn alle so arbeiten würden wie du würden wir immer noch Kutsche Fahren und auf die Straße ka**. hat sich nunmal aucbh wewehrt. Und 64Bit schmist ja nicht das ganze System unm sondern erferdert, dass man ein anderes Kompilerflag setzt. Das ist jetzt keine wirklich große Fehlerquelle.
Was ich halt befürchte ist, dass wir nochmal deswegen nochmal 100 Jahre 32Bit nutzen und dann müssen wir uns nochmal 150 Jahre mit hässlichen Würgarrounds rumschlagen nur weil keiner vom alten System ablassen wollte.
Gutes Beispiel ist IPv6: IP gibt's seit 30 Jahren Seit fast 17 Jahren ist klar, dass IPv6 die Bessere Variante ist, weil es viele Dinge besser macht als IPv4. Aber umstellen wil keiner, weil wozu IPv6 wenn man sowieso noch IPv4 zusätzlich braucht, weil es welche gibt die noch kein IPv6 sprechen. Ergebnis: Wir nutzen NAT dynDNS und anderes hässliches Zeug, das eigentlich keiner will und alle möglichen sachen zerschießt (FTP Torrent vernüngftiges VoIP ohne dass jemand mithört, OwnCloud...). Das ganze Zeug währe nie nötig gewesen wenn man vor 12 Jahren den Mut gahabt hätte zu sagen die Technologie ist seit 5 jahren tot nutzen wir sie nciht mehr. Und konsequent jeden Anbieter der nurnoch den alten Dreck anbietet gemieden hätte.