News Bye Bye Pentium und 486er: Entwickler wollen Support streichen
- Ersteller PCGH_Sven
- Erstellt am
x2K
Freizeitschrauber(in)
Das ist zwar eine Wissenschaft für sich aber nicht unmöglich. Habs einmal versucht, ging aber auf Anhieb schief.
Allerdings lässt sich der Kernel sehr flexibel anpassen für alle möglichen embedded Geräte und CPUs. Wenn du dich da einliest krigst du das schon hin. Ggf kannst du ja auch die teile aus dem Kernel raus lassen die deine cpu nicht unterstützt um Recourcen zu sparen.
Capucius
Software-Overclocker(in)
Kann man. Einfach Gentoo als Distri wählen und man lernt eine Menge.
Hätte ich vielleicht nicht als Erste wählen sollen.
Zik7
Software-Overclocker(in)
Irgendwo muss man ja anfangen....
Nutzen die nicht MS DOS ?Also demnächst Ausfälle ohne Ende bei der Bahn?
Mazrim_Taim
Volt-Modder(in)
Der neue Bond-Bösewicht?
Sorry aber etwas mehr Feedback wer das ist wäre echt cool.
Linus Torvalds sagt einem was aber von einem Ingo Molnar höre ich zum ersten mal was.
@ Streichung von Pentium 1 / 486
Wenn man das in Relation mit:
setzt ist das schon etwas ~krass nun auf einmal gleich zwei Generationen auf einmal zu streichen.
Anderseits wie groß ist die Verbreitung und die aktive Nutzung dieser CPUs heute noch?
Mein alter P1 (meine der hat 120Mhz) ist aber nur für Retro (Voodoo1 bzw. 2) und für Win98Se
inhuman_nature
Software-Overclocker(in)
Waaaas? Einfach so Support für 26 bzw. bis zu 36 Jahre alte CPUs einstellen? Das ist ja frech! Ph, dann wechsele ich eben zu Windows ... oh, äh, Moment, das neueste Windows (11) unterstützt offiziell gar 8 Jahre alte CPUs nicht mehr?!? Das ist ja noch 3-4 Mal frecher! 
Dann, äh, ...
Später hatte ich dann einen Athlon XP 2500+(?), den ich noch auf einen 3200+(Barton) aufrüstete. Lang ist's her ... .gif "sm_=) =)")
Ich bin mir nicht mehr sicher, wieviel RAM und Festplattenspeicher damals üblich waren. Die Zahlen würden den Unterschied zu heute auch nochmal deutlich machen. Waren es 4 MiB RAM beim 486er?
Dann, äh, ...... muss ich wohl auf andere Betriebssysteme setzen.
Done! Quasi"Die Unterstützung für den 386er beispielsweise wurde im Jahre 2012 aus dem Linux-Kernel gestrichen."
Das ist unerhört! Da soll nochmal einer über Windows 11 herziehen!
Muß ich jetzt meinen 486 DX 4 100 auf den Schrottplatz senden
Ne ne der läuft auch weiterhin mit MS-DOS 6.22.gif "sm_B-) :-)")
Ein geiler Prozessor! Den hatte ich auch!
Mein erster PC war ein 286er mit 12 MHz, dann ein 386er mit 25, ein 486er mit 33 und dann der 486 DX4 100.
Was für eine lange Liste an Prozessoren da zusammen kommt:
Pentium 90
Pentium 133
Pentium II 233
Pentium III 500
Duron 800
Athlon 1 GHz
Ob ich danach einen Athlon 64 oder schon einen Core2 Duo hatte, kann ich nicht mehr sagen.
Mein erster PC (nach dem C64) war ein 486er DX2 66 (MHz). Mit einem Knopf, anhand der Betätigung von diesem die CPU nur auf 33 MHz lief.Ich hatte mit einem IBM 486 SX2 angefangen - genau, als der 486 DX2 50 MHz rauskam
Dann lange nichts und dann glaub die 100MHz-Marke (oder knapp davor?) mit nem Pentium (?) gerissen.
Dann kam relativ bald AMD mit einem K5, glaube ich, und dann der Thunderbird ...
(dazwischen war bestimmt noch was, aber ich kann mich nicht mehr erinnern. 333MHz? K6, K6 III ... ich weiss es nicht mehr)
Später hatte ich dann einen Athlon XP 2500+(?), den ich noch auf einen 3200+(Barton) aufrüstete. Lang ist's her ... Ich bin mir nicht mehr sicher, wieviel RAM und Festplattenspeicher damals üblich waren. Die Zahlen würden den Unterschied zu heute auch nochmal deutlich machen. Waren es 4 MiB RAM beim 486er?
Zuletzt bearbeitet:
G4mest3r
gesperrt
Die Bahn setzt auf Linux?Also demnächst Ausfälle ohne Ende bei der Bahn?
Das letzte Mal, als ich so einen BSOD an so nem Karten-Terminal gesehen habe, war da glaube ich Windows XP oder 7 drauf.
Und diese paar Zeilen sollten eigentlich seit drei Jahrzehnten ausentwickelt sein; keine weitere Arbeit verursachen. Es ist ja nicht so, als ob ein 486er noch irgendwelche Besonderheiten hätte, die jedes mal aufs neue gezielt unterstützt werden müssten. Nach dem 386er kamen in der Intel-Linie* meinem Wissen nach bis einschließlich AVX2 immer nur Funktionen hinzu, aber bis vor kurzem (AVX512-Cameo bei Rocket Lake, SGX von Sky- bis Coffee Lake) wurde nie etwas zurückgezogen oder gar ersetzt. Ein x86-Kernel, der sich auf Minimal-Niveau initialisieren muss, sollte also eigentlich automatisch 486-kompatibel sein. Um höhere Aufgaben performant abzuarbeiten, bietet es sich natürlich an, den Code unter Nutzung neuerer Befehlssätze zu kompilieren – aber muss man das exklusiv halten? Tut es weh, wenn der Compiler einen Alternativpfad ausspuckt, der auf moderneren Systemen halt nie aufgerufen wird? Im Zweifelsfall, wenn doch mal was aus der Hardware entfernt oder schlicht nicht richtig erkannt wird, kann das auch den Unterschied zwischen "läuft langsamer" und "läuft gar nicht" machen.
Zumal das im gleichen Atemzug genannte 586er-/Pentium-Niveau vor gar nicht mal all zu langer Zeit noch als Basis für z.B. Xeon Phi diente, aber auch die Existenz von 486er-Derivaten im Microcontroller-Bereich würde mich nicht überraschen. Das war schließlich die letzte Generation, die von deutlich mehr als zwei Herstellern produziert wurde. Hier sollte man nicht vergessen, dass der Linux-Kernel ein multifunktionales Werkzeug mit vielen Anwendungsgebieten ist, kein auf Desktops beschränktes Betriebssystem. Und schon heute auf Distributionsebene leidet die Verbreitung von Linux darunter, dass alle möglichen Anwendungsvorlieben als Sonderfall ausgeforkt werden. Das muss nicht auch für den Kernel selbst praktizieren.
*: AMD hat mehrfach versucht, eigene Befehlssätze einzuführen, die sich aber nicht durchgesetzt haben und deren Support nicht auf allen späteren CPUs gegeben ist.
Duron war die abgespeckte Ausgabe des Athlon und damit formell das Gegenstück zum Celeron. (Auch wenn der Abstand zwischen den Linien die meiste Zeit über bei Intel deutlich größer ausfiel.)
Beide gab es aber erst lange* nach den hier besprochenen CPUs.
*: Je nach Bezugspunkt "nur" 5-9 Jahre bei Intel und 7-11 bei AMD, was damals aber 5-8 Generationen und einer größeren Leistungssteigerung entsprach, als wir heute seit den 0er Jahren gesehen haben.
Beide gab es aber erst lange* nach den hier besprochenen CPUs.
*: Je nach Bezugspunkt "nur" 5-9 Jahre bei Intel und 7-11 bei AMD, was damals aber 5-8 Generationen und einer größeren Leistungssteigerung entsprach, als wir heute seit den 0er Jahren gesehen haben.
RyzA
PCGH-Community-Veteran(in)
Ja sorry ich meinte auch den "Celeron". Hatte mich verschrieben.
Vor dem 750 Mhz Duron hatte ich den K6-2 350 Mhz.
Das war meine erste CPU. Pentium hatte ich nie.
Hallo Torsten,
so wie ich es verstanden habe, geht es nicht darum, dass etwas dazu kommt. Es geht vielmehr um das Fehlen von Funktionalität, die zunehmend zum Problem wird. Dem 486 fehlt ganz konrekt der CMPXCHG8B-Befehl. (Bekannt auch vom Pentium-F00F-Bug.)
Der Befehl ist wohl unverzichtbar, um 64-Bit-Werte auf 32-Bit-Architekturen atomar zu manipulieren. Das wird anscheinend oft gebraucht im Kontext von Nebenläufigkeit. Daher exestiert eine Ersetzung für CMPXCHG8B auf Interrupt-Basis. Die ist aber wohl nicht nebenwirkungsfrei und muss daher vielleicht immer wieder getest werden, wenn sich Dinge ändern. Ich weiß es nicht. Teile hier nur mein Halbwissen.
Mal anders gefragt: Warum soll es nicht weh tun? Die Entwickler sagen, dass es ihnen weh tut. Fest steht, sobald Du einen 64-Bit-Wert atomar verwaltet willst/musst, hast Du auf einem 486 ein Problem. Und wenn diese Fähigkeit von einem Linux im Jahre 2025 zwingend benötigt wird, von einem Linux im Jahre 1995 aber nicht, dann ist es vielleicht einfach so.
Die Frage ist, ob man nicht besser fährt, wenn man auf solchen Systemen auch eine Distribution aus der Zeit einsetzt? Die könnten in einer stark abgeschotteten Umgebung ja sogar noch Netzwerk haben. Den einzigen Anwendungsfall, den ich sehe: Man will diese Uralt-Systeme tatsächlich noch in ein mehr oder weniger offenes Netzwerk stellen.
F00F war (knapp) vor meiner Zeit. Aber soweit ich es verstehe, geht es da nur um eine fehlende Ausnahmehandhabung bei einem logisch sinnlosen Funktionsaufruf. Das System crasht also in einer Situation, in der es auch bei korrekter Funktion nie hätte funktionieren können (sondern die Ausführung verweigern sollte). Sauber kompilierte Software kann diesen Bug eigentlich nie triggern, nur auf dem System ausgeführter Code von böswilligen Angreifern. Der sollte bei allen drei Spielarten derartiger Systeme (sehr alte Rechner, relativ rezente Spezialarchitekturen, ggf. Microcontroller) aber kein Thema sein; nichts davon taugt als Webserver. Aber zumindest die hinteren beiden sollte man zu neuen Aufgaben kompatibel halten können.
F00F hatte ich nur so am Rande erwähnt.
Der Ausgangspunkt der Diskussion ist hier:
https://lore.kernel.org/lkml/20250425084216.3913608-1-mingo@kernel.org/
Da sind auch die inkrementierten Dateien aufgeführt.
Ich habe mir die Anzahl der Commits, die diese Dateien betreffen, mal ausgeben lassen. Im Schnitt ist das vielleicht ein Patch alle sechs Wochen. Manchmal auch weniger wie letztes Jahr, wo es nur drei Patches insgesamt für diese Dateien gab. Dieses Jahr sind wir aber schon wieder bei sieben. Ich habe das Gefühl, dass zentrale Kernelarbeiter wie Ingo Molnár schlicht an ihre Grenze der möglichen Kontextwechsel stoßen. Und Linus Torvald muss diese Leute bei Laune halten. So viele hat er nicht. Der Code ist arkan und nahezu ungenutzt.
Mit genug Geld kann man natürlich alles unterstützen. Man bezahlt einfach einen komplett neuen Entwickler, der den alten i486-/Pentium-Code im Kernel pflegt. Ggf. erstmal in einem Fork. Da dürfte niemand ein Problem mit haben.
Er trinkt Kaffee, schaut YouTube – und reviewed im Schnitt einen Patch alle sechs Wochen, den oft sogar jemand anders geschrieben hat und dem Kommentare wie "No functional change intended" beigefügt sind. Den Rest der Zeit arbeitet er als so eine Art Museumswärter für historische x86-Architekturen, die er in seiner Wohnung oder im Büro beherbergt. Darauf darf er alles gründlich testen.
Der Job klingt entspannt – bis plötzlich ein Merge-Konflikt oder (subtiler) Bug aufschlägt. Dann wird tieferes Verständnis erforderlich. Aber der Kollege oder die Kollegin hat ja viel Zeit sich weiter zu bilden. Also ja, man könnte die Altarchitektur erhalten. Man müsste nur jemanden finden, der’s machen, und jemanden, der’s bezahlen will. Vielleicht starten wir im Forum einfach ’ne Sammelaktion.
Hast du einen Überblick, was für/warum Patches an einem Code-Bereich nötig waren, der nicht genutzt wird und an dem nichts geändert werden sollte?
Grundannahme einer Beibehaltung Bestehendes ist natürlich immer, dass man Bestehendes beibehält. Und sich nicht die Mühe macht, es fortwährend neu aufzubauen.
Grundannahme einer Beibehaltung Bestehendes ist natürlich immer, dass man Bestehendes beibehält. Und sich nicht die Mühe macht, es fortwährend neu aufzubauen.
Ich habe grundsätzlich so viel Überblick wie ich haben möchte und vertragen kann. Der Code und alle Commits sind öffentlich und über git auch sehr gut auswertbar. Jeder auf der Welt kann das Repository herunterladen und damit arbeiten:
Code:
git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.gitWarum die Änderungen nötig waren, dazu müsste ich mir die Commits ansehen und verstehen. Aber warum soll ich die Arbeit von RedHat und Intel kontrollieren? Alles Kernelentwickler mit jahrelanger Erfahrung. Man kann sich aber problemlos die einzelnen Commits ansehen. Sie zu verstehen und ihre Notwendikeit zu beurteilen ist aber etwas anderes.
So funktioniert die Linux-Entwicklung nicht. Es gibt klare Regeln wie Patches eingereicht und von den Maintainer verarbeitet werden. Und selbstverständlich kann niemand unötige Patches einreichen. Auf der anderen Seite können Patches auch nicht einfach ohne guten Grund abgelehnt werden. Bei Grundsatzfragen entscheidet Linus Torvalds persönlich. Das ist über Jahrzehnte austariert. Andernfalls würden zahllose (unnötige) Forks von Linux entstehen, weil Leute sich ausgeschlossen fühlen würden (und es auch wären). Gleichzeitig verhindert das System sehr effektiv Chaos.
Die Änderungen kommen also i.d.R. nicht von den Maintainern (außer bei Merge-Konflikten u.s.w.), sondern von externen Linux-Entwicklern. Das sind Firmen oder Privatpersonen. Ich hab mir von ChatGPT ein kleines Skript schreiben lassen, dass das für die jetzt gelöschten Dateien auf Basis des git-repositories auswertet. Hier mal das Ergebnis von 2023 bis heute:
Änderungen an den betroffenen Dateien seit 2023-01-01:
| Person | Organisation | Anzahl Änderungen | Anteil |
|---|---|---|---|
| thuth | redhat.com | 4 | 26,7 % |
| arnd | arndb.de | 4 | 26,7 % |
| viresh.kumar | linaro.org | 2 | 13,3 % |
| ubizjak | gmail.com | 1 | 6,7 % |
| peterz | infradead.org | 1 | 6,7 % |
| mingo | kernel.org | 1 | 6,7 % |
| masahiroy | kernel.org | 1 | 6,7 % |
| hpa | zytor.com | 1 | 6,7 % |
Die meisten Commits kommen von Firmen, auch wenn man das oft nicht direkt erkennt. Hinter hpa zytor.com verbrigt sich z.B. Intel vor allem aber H. Peter Anvin. Ein erfahrender Linux-Kernelentwickler.
Man muss sich immer wieder klar machen, dass all diese Leute unabhängig arbeiten und sich letzlich nur über git und ein klares Regelset synchonisieren. Zu den Regeln gehört auch, dass im Zweifel Torvalds persönlich entscheidet. Sein Wort gilt. Wem das nicht passt, der kann forken. Das ist dann technisch wahrscheinlich sogar die sinnvollste Lösung.
Der Code, der jetzt (wahrscheinlich) aus den kommenden Releases genommen wird, verschwindet ja nicht. Vielleicht forkt jemand und irgendwann ist der Code sogar wieder drin, weil er so geändert wurde, dass er für die Maintainer wieder akzeptabel ist. Sowieso kann ihn jeder weiter benutzen und sich Kernel bauen (auch aktuelle), die den Code beinhalten. Nur die Linux-Maintainer lösen nicht mehr die Konflikte auf und breiten ihren Segen darüber aus. Dazu fehlt ihnen schlicht die Zeit (und die Lust).
In Fällen wie diesem entscheidet das Torvalds höchstpersönlich und diktatorisch.
Zuletzt bearbeitet:
Ähnliche Themen
