Das 32-Bit-Ende ist "nahe"?!

[hikaru]

wenn bestimmte "Blockbuster"-Software (Firefox UND Chromium, Multimedia, oder wichtige Toolkits) selbst nicht mehr x86_32-kompatibel ist.

Ich tippe nicht auf Chromium oder toolkits. Das OpenSource-C(++)-Zeug baust du halt für x86 und gut ist. 32Bit Kompatibilität können die nicht auf geben wegen armhf, für da noch mindestens die nächsten 5 Jahre Neugeräte erscheinen.

Ich habe nicht umsonst sauber zwischen "x86_32" und "32bit" unterschieden. x86_32 wird vermutlich nicht wegen der Busbandbreite unbenutzbar werden, sondern weil hier im Vergleich zu x86_64 Instruktionen fehlen, die irgendwann von "moderner" Software hart vorausgesetzt werden. Als möglichen Kandidaten hatte ich die SSE-Familie angeführt.
Arm hingegen ist ein völlig anderes Ökosystem. Was die Busbandbreite angeht, mögen x86_32 und "arm32"* vergleichbar sein. Aber hier enden die Gemeinsamkeiten auch schon. Anzunehmen, dass x86_32 so lange funktionieren wird, wie noch "arm32" unterstützt wird, ist ein Trugschluss.

*) Hier als Sammelbegriff für alles unterhalb von "arm64" zu verstehen

[wanne]

Ich hatte von OpenSource C++ Programmen geschieben. Die können kein SSE vorassetzen. Ich sag dem Compiler halt das ich das nicht habe und der benutzt das nicht. Aus C(++) sicht ist armhf und x86 das selbe. So lange der Code auf den arms läuft tut er das auch auf x86. Problematisch sind nur Programme für die es keinen (vollständigen) Sorce gibt.

[pferdefreund]

Ich sehe das genauso wie einige andere hier. Warum alte voll funktionsfähige Hardware entsorgen ? Mein IBM R52 rennt problemlos - momentan noch auf Debian 9. Alles funktioniert inklusive Videos ohne Ruckeln. Oberfläche ist der schlanke icewm, Browser Palemoon. Das Ding hat eine 1,8 Ghz Centrino-CPU und mittlerweile wohl su um die 15 Jahre auf dem Buckel. Einzige "Reparatur" bisher war eine neue BIOS-Batterie. Ich werde das Teil nutzen, solange es irgendwie geht. Ist einfach zuverlässig wie ein alter Benz Diesel. Ja, mit den Autos halte ich es genauso. So lange fahren, bis es sich wirklich nicht mehr lohnt, was reinzustecken. Waren bei den letzten 2 mal 15 und dann 17 Jahre. Mal sehen, wie lange der jetzige hält - hat jetzt auch schon 10 Jahre auf dem Buckel. Im Notfall dann halt apt-get source und Konsorten, und so möglich, selber bauen. Bin ja ab Juli in Rente und dann hat man Zeit für sowas.

[MSfree]

Ich hatte von OpenSource C++ Programmen geschieben. Die können kein SSE vorassetzen.

Für SSE gibt es spezielle Funktionsaufrufe oder es findet im Assembler statt. Beide Fälle sind aber ausschließlich auf Intel/AMD lauffähig. ARM, MIPS, PPC... kennen SSE nicht, die haben andere zu SSE inkompatible Vektorerweiterungen (was man aber teilweise wieder über den Compiler hinbiegen kann).

So lange der Code auf den arms läuft tut er das auch auf x86.

Jein. Solange man keine speziellen Vektorerweiterungen nutzt, ist das richtig. Aber auch ARM geht in Richtung 64Bit, Apple führt schon seit IOS12 keine 32Bit Apps mehr aus. Auch Raspi-2 und neuer sind bereits 64Bit CPUs, nur, daß das von Raspbian noch nicht genutzt wird, weil man noch kompatibel zum 32Bit Raspi-Zero(W) sein will und wohl keine zwei Distributionen pflegen will.

[hikaru]

Ich hatte von OpenSource C++ Programmen geschieben.

Du hast dich auf meine Aussage bezogen, dass bestimmte Software sich irgendwann nicht mehr unter x86_32 compilieren lassen wird. Es ist reichlich naiv anzunehmen, dass große Projekte wie "Full-Feature-Browser" mit all ihren Abhängigkeiten, welche eigene Build-Optionen setzen, sich von Dritten so durchschauen lassen, dass dort architekturspezifische Quirks angebracht werden können.
Als Beispiel verweise ich mal auf willys letzten Waterfox-Thread, wo es nicht mal um Architektur, sondern "nur" um Glibc-Funktionen ging. [1]
Alternativ kannst du als Übungsaufgabe gern mal versuchen, einen aktuellen Chromium auf i586 lauffähig zu machen!

[1] viewtopic.php?f=29&t=176204

[wanne]

Für SSE gibt es spezielle Funktionsaufrufe oder es findet im Assembler statt. Beide Fälle sind aber ausschließlich auf Intel/AMD lauffähig. ARM, MIPS, PPC... kennen SSE nicht, die haben andere zu SSE inkompatible Vektorerweiterungen.

Genau meine Aussage: Solange die Software auf arm bauen will tut sie das auch auf x86. So hält arm x86 am laufen.

Für SSE gibt es spezielle Funktionsaufrufe oder es findet im Assembler statt.

Ja: Wie gesagt bei Assembler (ob inline oder direkt) ist das ein Problem. Bei C++ nicht. Gibt aber nicht viele Programme die Assembler Anteile haben. Defakto ist das halt der Kernel und ein paar Crypo-Libs.

Aber auch ARM geht in Richtung 64Bit, Apple führt schon seit IOS12 keine 32Bit Apps mehr aus. Auch Raspi-2 und neuer sind bereits 64Bit CPUs, nur, daß das von Raspbian noch nicht genutzt wird, weil man noch kompatibel zum 32Bit Raspi-Zero(W) sein will und wohl keine zwei Distributionen pflegen will.

Ja. Glaube aber nicht, dass sich das in den nächsten 5 Jahren auf dem Low-End Markt durchsetzt. Und dann gibt es noch ne weile Altgeräte

wo es nicht mal um Architektur, sondern "nur" um Glibc-Funktionen ging.

Nein. Das ist nicht "nur" sondern eine völlig andere Größenordnung von Problem. Ne zusätzliche api bereitstellen kann keine Distribution. Ich kenne genau eine Distribution, die verschiedene inkompatible libcs bereitstellt und das ist OpenWRT. Aber Debian kann jetzt schon problemlos 10 Architekturen bereitstellen. Die tun sich mit einer mehr oder weniger nicht schwer. Die Maintainer müssen die Übersicht über die Architekturspezifischen Quirks haben. Sonst tut das nicht. Insbesondere weil sich die Entwickler selbst wenig gedanken darüber machen, wie ihr Zeug auf mipsel compiliert. Da gehört der FF ausdrücklich dazu der bis vor kurzem offizell sogar ausschließlich x86 kannte. (Und gar kein x86_64. In Debian war das natürlich trotzdem drin. So wird das auch in die andere Richtung luafen.) Wenn du den Mozilla Leuten mit mips kommst fragen sie dich was das ist. Das ist btw. auch der unterschied zu vielen anderen Distros die eh nur x86_64 und x86 machen. Für die ist es eine Erleichterung, wenn sie sich darum nicht mehr um unterschiedliche Architekturen kümmern müssen.

[wanne]

Hier die Open Source-Debian Pakete, die Assembler enthalten:

Sind laut Wikidata insgesamt 18¹:

Code: Alles auswählen

Aircrack-ng
american fuzzy lop
Arduino
GMP
GNU GRUB
Go
libvpx
LILO
Linux kernel
Memtest86+
Mesa
mpg123
Nettle
OpenSSL
SYSLINUX
Tiny C Compiler
UPX
x264

Kann sein dass die was vergessen haben. Aber das sind drein Hand voll Andwendungen. Die aller meisten (OpenSSL, GMP..) funktionieren expizit auch ohne die Assembler teile und es ist nur eine Option zum Beschleunigen. Gefährlich weil wirklich nötig ist halt: libvpx, Mesa, mpg123 und eventuell Go damit sind wir bei 4 relevanten Paketen. Für alles andere gibt es dann im Zweifelsfall das eine unwichtige Paket nicht. Für alle anderen Pakete hast du das Problem nicht.

[¹] https://query.wikidata.org/#SELECT%20DI ... 0%7D%0A%7D

[nudgegoonies]

Die i386 Platform ist auch beim Linux Kernel selbst nicht die gepflegteste wie ein Kernel-Entwickler anmerkt:
https://www.heise.de/ct/artikel/Linux-5 ... ml?seite=8
Ich vermute aber, dass uns i386 im Kernel wegen Embedded/Industrie, IOT, etc. noch extrem lange erhalten bleibt.

Tatsächlich hat mein Mini-Server den letzten ATOM Prozessor, der kein amd64 kann. Aber das wichtigste Argument pro i386 in Debian für mich persönlich ist WINE. Ohne Wine müsste ich Multiarch nicht mal aktivieren. Ich habe so viele alte 32 Bit Windows Spiele, die ich nicht missen möchte. Da gab es auch bei Ubuntu lange Diskussionen, als sie die i386 Architektur rauswerfen wollten. Den Heise Newsticker Eintrag dazu finde ich leider nicht. Aber ich meine der Tenor war, dass man alle für WINE benötigten 32 Bit Bibliotheken weiter bauen könnte. Ohne ein 32 Bit WINE und die 32 Bit Bibliotheken von denen es abhängt kann man nun mal wirklich nur noch 64 Bit Windows Programme laufen lassen. Und da habe ich auch diverse, wo der Installer als 32 Bit Binary daherkommt obwohl er ein 64 Bit Programm installiert.

[MSfree]

Ich vermute aber, dass uns i386 im Kernel wegen Embedded/Industrie, IOT, etc. noch extrem lange erhalten bleibt.

Nein. Bitte nicht alle 32Bit-CPUs in einen Topf werfen. Embedded ist nur in den seltensten Fällen i386. Intels Quark-Plattform ist z.B. gescheitert.

Es gibt im Kernel Code, der CPU-spezifisch ist. Wenn im 32Bit-ARM-Code ein Fehler behoben wird, ist der noch lange nicht aus dem i386-Code raus. Und das ist es, was der Kernelentwickler gemeint hat, der i386-Code ist teilweise vernachlässigt, während ARM-Code in deutlich besserem Zustand ist.

[wanne]

Es gibt im Kernel Code, der CPU-spezifisch ist. Wenn im 32Bit-ARM-Code ein Fehler behoben wird, ist der noch lange nicht aus dem i386-Code raus. Und das ist es, was der Kernelentwickler gemeint hat, der i386-Code ist teilweise vernachlässigt, während ARM-Code in deutlich besserem Zustand ist.

Ja. Am Ende nehme ich stark an, dass Debian genau so lange supportet wie der Kernel es tut. Wenn die aufhören kann Debian auch nichts mehr machen. Leider verdanken wir ja systemd, dass Hurd und kFreeBSD rausgeflogen sind. Zumindest ersteres wird vermutlich noch auf Ewigkeiten x86 supporten. Eventuell bringt devuan ja bald Hurd support.

[Lord_Carlos]

Warum alte voll funktionsfähige Hardware entsorgen ?

z.B. weil man neue Umsonnst bekommt and dann steht die alte nur im Weg.

[jph]

Die i386 Platform ist auch beim Linux Kernel selbst nicht die gepflegteste wie ein Kernel-Entwickler anmerkt:

Wobei die Bezeichnung i386 irreführend ist: alles ab Kernel 3.8 ist auf einem echten 80386 nicht mehr lauffähig, die glibc hat den Support m.W. 2012 eingestellt. Debian verlangt mittlerweile nach i686: „Allerdings wird Debian GNU/Linux Buster nicht auf 586-er Prozessoren (Pentium) oder älter laufen! “ (https://www.debian.org/releases/stable/ ... tml#idm273).

[nudgegoonies]

Nein. Bitte nicht alle 32Bit-CPUs in einen Topf werfen. Embedded ist nur in den seltensten Fällen i386. Intels Quark-Plattform ist z.B. gescheitert.

Tue ich gar nicht. In Kernel Log geht es auch gar nicht um 32 Bit im allgemeinen sondern um nur um i386 (in Debian Architektur-Sprech). Nenne es X86-32Bit wenn Du magst. Aber ich habe Embedded und Industrie in einen Topf geworfen. Und viele Industrieanlagen sind per se Embedded.

Dass der echte 80386 nicht mehr unterstützt wird hatte ich auch mitbekommen.