News Historischer Support wird gestrichen: Linux verabschiedet sich endgültig vom Intel 486

PCGH-Redaktion

Kommentar-System
Teammitglied
Der Linux-Kernel gilt als extrem kompatibel, denn selbst jahrzehntalte Hardware wird oft noch unterstützt. Doch steigender Wartungsaufwand setzt nun dem Support der Intel 486 ein Ende.

Was sagt die PCGH-X-Community zu Historischer Support wird gestrichen: Linux verabschiedet sich endgültig vom Intel 486

Bitte beachten: Thema dieses Kommentar-Threads ist der Inhalt der Meldung. Kritik und allgemeine Fragen zu Online-Artikeln von PC Games Hardware werden hier gemäß der Forenregeln ohne Nachfrage entfernt, sie sind im Feedback-Thread besser aufgehoben.
 
Windows XP benutzte den Maschinenbefehl CMPXCHG8B, den der 486 nicht mehr konnte. Daher war ab XP ein Pentium das Minimum. Es gab mal einen Hack, der den Code von XP entsprechend änderte, aber das war eher ein Proof of Concept.

Die Grenze für den 486 sind also Windows 2000 bzw. Windows ME.
Hab auch gerade geschaut, Wikipedia sagt, dass Win 2000 schon einen Pentium 133 MHz gefordert hatte, aber vielleicht lief der 486 trotzdem noch. Wohl eher eine Frage ob der Befehlssteuersatz des 486 ausreichend war
 
In der Praxis wird es wahrscheinlich irgendeinen Fork geben, der sich weiterhin darum kümmert.

Irgendwann ist auch mal gut! 37 Jahre sind eine sehr lange Zeit und was macht man in 2026 noch aktuelles mit einem 486er ? Wer den noch nutzt hat eher ein Retrosystem am Laufen.

Es geht vorallem um Produktivsysteme und weniger um irgendwelche Zocker, die damit Spiele spielen. 486er sind, besonders im Embeddedbereich, sehr weit verbreitet gewesen. Dinge, wie Fahrkartenautomaten und vieles, was einen Bildschirm hat, haben darauf gesetzt. Da war es ganz schön, wenn für die Hardware noch etwas aktuelles zur Verfügung steht.
 
Mir ist auch nicht ganz klar, wie das mit "Um CPUs wie den 486 weiterhin zu unterstützen, sind komplexe Emulationen und spezielle Codepfade nötig" gemeint ist. Erstmal ist der Befehlssatz der 486er CPU kompatibel zu neueren Versionen, es fehlen halt etliche neueren Befehle. Daher muss man nichts emulieren, sondern man muss den Code quasi "unoptimiert" mit ggfls. mehr Befehlen mit dem Compiler generieren.
Spezielle Codepfade sind auch nur dann nötig, wenn man zur Laufzeit entscheiden will, was für eine Library oder was für ein Code generell ausgeführt werden soll. Ich hätte also einfach es so beschrieben, dass der Code mit modernen CPUs ineffizienter ausgeführt wird, weil viele spätere, optimierte CPU Befehle fehlen.
 
Wenn du den Code nicht von Hand umschreibst, brauchst du aber zur Ausführung auf jeden Fall ein Stück Software, das fehlende neue Befehle auf irgendeine andere Art und Weise ausführt, egal ob du das "Emulation" nennst oder nicht.
 
Und selbst wenn etwas zu komplex ist, um es von einem normalen Compiler automatisch umsetzen zu lassen:
Zwischen Architekturen, die deutlich mehr als der 486er können, und heute, liegen locker zwei Jahrzehnte. Kann mir doch keiner erzählen, dass es da keine seit >10 Jahren unverändert genutzten Kompatibilitätslayer gibt, die man auch die nächsten 20 Jahre unverändert in eine angepasste Edition des Kernels kopieren könnte?
Ist ja nicht so, als würde gängige Linux-Distributionen von Hause auf 486ern laufen, da braucht es sowieso speziell abgespeckte Fassungen. Die könnten auch einen modifizierten Kernel nutzen. Aber es wäre halt schön, wenn die Distribution-Maintainer diese Anpassungen nicht selbst (und ohne Ahnung von Kernelcode) vornehmen müssten, um von neuen Entwicklungen auf höheren Leveln (z.B. Sicherheitsfixes weit jenseits der Hardware-Befehlssätze) zu profitieren.

Irgendwann ist auch mal gut! 37 Jahre sind eine sehr lange Zeit und was macht man in 2026 noch aktuelles mit einem 486er ?

Mikrocontroller bauen. 486 war die letzte weithin lizensierte x86-Ausbaustufe und wurde und wird dementsprechend für ein Unzahl an eingebetteten Schaltungen genutzt, die kaum Rechenleistung brauchen, bei denen Kompatibilität zu gewohnten Programmierumgebungen aber nett ist. Seit einiger Zeit haben ARM und RISC-V diesen Bereich natürlich für Neukonstruktionen übernommen. Aber in Anwendungsgebieten mit klar umrissenen Aufgaben gibt es eben keine "Weiterentwicklung". Was einmal funktioniert hat, wird teils über Jahrzehnte unverändert produziert – inklusive 486er-Kern. Und während es bei Desktop-Betriebssystemen wie Windows egal wäre, ob sie dazu kompatibel sind, dient der Linux-Kernel eben als Grundlage für unzählige Embedded-Anwendungen.

Wer da tätig ist, dürfte jetzt auf der veralteten Version hängenbleiben. Vermutlich in den meisten Fällen kein technisches Problem, da eben keine Weiterentwicklung stattfindet und vor 20 Jahren designte Microcontroller nicht selbständig online gehen. Aber Code auf zwei verschiedenen Basen zu pflegen, weil die Version für eine Hardware-Variante nicht mehr maintained wird, klingt trotzdem nicht nach wertvoller Verwendung von Lebenszeit.

Hab auch gerade geschaut, Wikipedia sagt, dass Win 2000 schon einen Pentium 133 MHz gefordert hatte, aber vielleicht lief der 486 trotzdem noch. Wohl eher eine Frage ob der Befehlssteuersatz des 486 ausreichend war

Die offiziellen Angaben haben wenig mit dem tatsächlich notwendigen zu tun, sondern reflektieren teilweise Microsoft Produktpolitik, zum Teil Empfehlungen für annehmbare Leistung. Für Windows 7 ist z.B. das niedrigste, was ich finden konnte, ein auf 5 MHz untertakteter Pentium Pro. Leistungsmäßig also noch ein viel schwächerer Prozessor als ein durchschnittlicher 486er. Aber wenn es um harte Kompatibilität geht, hängt irgendwann alles an bestimmten Befehlen die entweder verstanden werden oder nicht. Bei geringfügig neueren Systemen (486er kenne ich direkt nicht) ist zum Beispiel die Energieverwaltung über ACPI häufig ein Thema. Die braucht eigentlich kein Betriebssystem, um zu funktionieren. Aber wenn es während des Boots explizite Reaktionen erwartet und die nicht kommen, weil irgend ein Pentium-Board noch nie etwas von solch futuristischem Zeug gehört hat, dann bootet es halt nicht weiter.
 
besonders im Embeddedbereich, sehr weit verbreitet gewesen. Dinge, wie Fahrkartenautomaten und vieles, was einen Bildschirm hat, haben darauf gesetzt.
Du glaubst das die Dinger auf dem aktuellen Stand sind ? Ich glaube kaum, dass es da eine wirklich große Rolle spielt. Es würde mich nicht wundern, wenn vieles davon noch mit Windows 95 oder älter läuft. Da spielt Linux dann eh keine Rolle.
Und vieles wurde doch in den letzten Jahren erneuert. In den nächsten Jahren verschwindet davon noch mehr, weil immer mehr mit dem Smartphone erledigt werden kann. Den 486er, der im Embeddedbereich mit einem aktuellen Linux Kernel betrieben wird, würde ich persönlich gerne sehen! Mag es geben, aber wie oft ?
 
dient der Linux-Kernel eben als Grundlage für unzählige Embedded-Anwendungen.
Wobei da meist im industriellen Bereich ein BSD verwendet wird.
Den 486er, der im Embeddedbereich mit einem aktuellen Linux Kernel betrieben wird, würde ich persönlich gerne sehen! Mag es geben, aber wie oft ?
Och ich denke da gibt es ganz sicher noch einige Geräte die das noch nutzen. Schau mal was derzeit für die Industrie angeboten wird. Das was da jetzt hochaktuell ist wird uns hier nicht einmal ein lächeln aufs Gesicht zaubern. Diese Hardware wird aber wirklich sehr sehr lange zum Beispiel zur Steuerung von Maschinen in Produktionslinen genutzt.
 
Mir ist auch nicht ganz klar, wie das mit "Um CPUs wie den 486 weiterhin zu unterstützen, sind komplexe Emulationen und spezielle Codepfade nötig" gemeint ist. Erstmal ist der Befehlssatz der 486er CPU kompatibel zu neueren Versionen, es fehlen halt etliche neueren Befehle. Daher muss man nichts emulieren, sondern man muss den Code quasi "unoptimiert" mit ggfls. mehr Befehlen mit dem Compiler generieren.
Spezielle Codepfade sind auch nur dann nötig, wenn man zur Laufzeit entscheiden will, was für eine Library oder was für ein Code generell ausgeführt werden soll. Ich hätte also einfach es so beschrieben, dass der Code mit modernen CPUs ineffizienter ausgeführt wird, weil viele spätere, optimierte CPU Befehle fehlen.
Also vielleicht mache ich einen Denkfehler, aber ist es nicht genau umgekehrt?

Klar (?) scheint, dass für 486 kompilierte Software auf neueren CPU laufen sollte, der Befehlssteuersatz ist ja größer geworden. Umgekehrt wird es aber schwierig: Wenn Software sagen wir z.b. AVX-512 nutzt, wird es auf nem 486 nicht laufen.

Der Linux Kernel ist auch Software. Wenn er (nur exemplarisch gemeint!) AVX-512 nutzen würde, wäre es nicht möglich ihn auf einem 486 laufen zu lassen.

Sprich: Der Kernel möchte sich halt in Zukunft nicht auf 486 Befehle beschränken, sondern neue Befehle verwenden? Bzw workarounds für 486 nicht ewig nachziehen... Vermutlich weniger aus Effizienz als aus Sicherheitsgründen (Speicherschutz)

Ergänzung: Habe gerade ein bisschen gegoogelt und mehr zum Hintergrund gefunden:

https://hackaday.com/2025/07/02/why-the-latest-linux-kernel-wont-run-on-your-486-and-586-anymore/
 
Zuletzt bearbeitet:
Klar (?) scheint, dass für 486 kompilierte Software auf neueren CPU laufen sollte, der Befehlssteuersatz ist ja größer geworden. Umgekehrt wird es aber schwierig: Wenn Software sagen wir z.b. AVX-512 nutzt, wird es auf nem 486 nicht laufen.
Eigentlich kommt es nur drauf an, wie der Code kompiliert wurde. Man kann denselben Hochsprachencode ja auf verschiedene Arten in Maschinencode übersetzen. In der Regel sollten dabei auch solche Emulationen automatisch umgesetzt werden. Wenn man dem Compiler sagt, dass die CPU, für die man kompiliert kein AVX-512 kann, dann werden diese Aufrufe halt durch sequentielle Berechnungen ersetzt. Warum genau das in diesem Fall nicht geht, bzw. warum das mit einem Workaround im Quellcode aber nicht im Compiler geht, weiß ich auch nicht. Vielleicht gibt es einfach keine passenden Compiler, die aktuellen C- oder Rust-Code auf das 486-Level kompilieren können.
 
Du glaubst das die Dinger auf dem aktuellen Stand sind ? Ich glaube kaum, dass es da eine wirklich große Rolle spielt.

Klar wird das Zeug noch aktuell gehalten, besonders, wenn es mit dem Internet verbunden ist.

Da spielt Linux dann eh keine Rolle.

Für Produktivsysteme ist Linux die Wahl, unter anderem deshalb.

In den nächsten Jahren verschwindet davon noch mehr, weil immer mehr mit dem Smartphone erledigt werden kann.

Das sind Produktivsysteme. Du kannst nicht einfach mal eine CNC Fräse irgendwie mit dem Smartphone verbinden. Das Zeug hat einen Rechner drin und wenn du die austauschen willst, dann wird es teuer. Es hat schon seinen Grund, warum bei Linux auch noch ein 386er Fork gepflegt wird.

Es ist nicht alles Gaming, was mit Computern zu tun hat.

Den 486er, der im Embeddedbereich mit einem aktuellen Linux Kernel betrieben wird, würde ich persönlich gerne sehen! Mag es geben, aber wie oft ?

Wenn du durch die Stadt fährst, dann siehst du diese vermutlich noch häufig. Das sind einfach Dinge, die einen Computer in sich haben. Da geht es nicht ums Gaming, darauf soll nicht gezockt werden. Die Sachen sollen ihre Aufgabe erledigen und solange sie das machen, gibt es wenig Grund den Krempel auszutauschen. Automaten aller Art, Anzeigen, Dinge, denen man nicht ansieht, dass sie einen Computer in sich haben. Dinge, bei denen es auf den zweiten Blick auffällt, etwa, wenn man durch ein Drehkreuz geht. Die Chancen sind recht hoch, dass du irgendwo einem uralten 486er oder noch älter, über den Weg läufst und nichtmal merkst, dass er da war.
 
Eigentlich kommt es nur drauf an, wie der Code kompiliert wurde. Man kann denselben Hochsprachencode ja auf verschiedene Arten in Maschinencode übersetzen. In der Regel sollten dabei auch solche Emulationen automatisch umgesetzt werden. Wenn man dem Compiler sagt, dass die CPU, für die man kompiliert kein AVX-512 kann, dann werden diese Aufrufe halt durch sequentielle Berechnungen ersetzt. Warum genau das in diesem Fall nicht geht, bzw. warum das mit einem Workaround im Quellcode aber nicht im Compiler geht, weiß ich auch nicht. Vielleicht gibt es einfach keine passenden Compiler, die aktuellen C- oder Rust-Code auf das 486-Level kompilieren können.
Na ja, ich denke es liegt daran dass es ein Kernel ist: Sehr maschinennah programmiert in C/Rust und offenbar auch Assembler. Bin nicht sicher ob das mit einem generischen Compiler umsetzbar wäre. Zumindest die Performance würde vermutlich stark leiden
 
Na ja, ich denke es liegt daran dass es ein Kernel ist: Sehr maschinennah programmiert in C/Rust und offenbar auch Assembler. Bin nicht sicher ob das mit einem generischen Compiler umsetzbar wäre. Zumindest die Performance würde vermutlich stark leiden
Dass es ein Kernel ist, ist nicht so wichtig, den gibt es ja jetzt schon in allen möglichen Ausführungen (siehe CachyOS, insbesondere die Varianten für x86-64v3 und v4). C und Rust sind auch kein Problem. Assembler schon eher, weil der halt nicht kompiliert wird. Aber keine Ahnung, in welchem Umfang der eingesetzt wird.
 
Abwärtstransformationen könnte man auch ausgehend von Assembler leicht vornehmen. Die Übersetzung in Maschinencode erfolgt weiterhin automatisch und wenn man das von joecnstr verlinkte Beispiel mit einer fehlenden 8-Byte-Vergleichsfunktion bei vorhandener 1-Byte-Vergleichsfunktion nimmt, dann kann der in Assembler geschriebene, zu neue Befehl, in einen fixen Satz Maschinencode überführt werden. Dass dieser dann aus acht Befehlswiederholungen besteht, geht etwas über pure Assemblierung hinaus, bringt mich aber zu obiger Frage zurück: Macht man das nicht schon seit Jahren genau so und könnte es ohne Mehraufwand weitermachen?

Da würde mich wirklich mal ein Beispiel interessieren, wo Pentium-kompatibler Code der letzten Jahre nicht mit den 486er-Fallback-Mechanismen kompatibel war und händisch debugged werden musste. Die eigentlichen Abwärtskompatibilitätshürden würde ich viel weiter oben, bei noch neuen Formaten erwarten: Wenn ein neues Kernelfragment von AVX512 profitieren soll und man händisch erstmals ein Assembler-Fallback von AVX512 auf AVX2 und AVX1 entwickeln muss, dann hat man einen ordentlichen Batzen Legacy-Arbeit vor sich. Aber die verschwindet halt nicht, in dem man CPUs aus der Kompatibilitätsliste streicht, die zum Teil nicht einmal x87 geschweige denn MMX kennen.
 
Zuletzt bearbeitet:
Warum genau das in diesem Fall nicht geht, bzw. warum das mit einem Workaround im Quellcode aber nicht im Compiler geht, weiß ich auch nicht. Vielleicht gibt es einfach keine passenden Compiler, die aktuellen C- oder Rust-Code auf das 486-Level kompilieren können.

Klar geht das und vermutlich wird es auch irgendetwas geben. So, wie das schon bei den 386ern der Fall war. Der Punkt ist, dass das dann nicht mehr das Problem des Kernelteams ist, sondern derjenigen, die sich dem Problem annehmen werden/wollen.

Einer der großen Vorteil der Open Source, bzw. GPL Geschichte. Niemand kann/will/wird dich stoppen, wenn du Bock hast.
 
Zurück