Linux Linux-Kernel soll keine Rücksicht mehr auf 486-CPUs nehmen

Linux Betriebssystem
Grafik wird auf einem 486er auch schwierig bei den heutigen, fetten, überbordenden Desktop Environments. Da bleibt ja fast nur die Konsole - egal ob Nintendo oder SEGA.
Das war schon auffm DX4-100 mit wimre 16MB RAM eine ziemlich zähe Angelegenheit, und auch nur twm oder sowas.

Guido
 
Warum "Internet"? Es reicht ja, einen alten Rechner, der früher mit XP oder Win2k lief, mit einem schlanken Linux auszustatten, damit das Museumsstück noch nutzbar ist. Das dürfte jetzt auch wegfallen.
Warum sollte für diesen Einsatzzweck – also einen hypothetischen Museums-486er nutzbar zu machen – nicht auch ein Debian 10 oder 11 oder 12 ausreichen? Dass die installierten Softwarepakete nicht die allerneuesten wären, ist doch bei so einer Maschine gerade egal.
 
Warum sollte für diesen Einsatzzweck – also einen hypothetischen Museums-486er nutzbar zu machen – nicht auch ein Debian 10 oder 11 oder 12 ausreichen? Dass die installierten Softwarepakete nicht die allerneuesten wären, ist doch bei so einer Maschine gerade egal.
Das würde eine zähe Angelegenheit werden. Lieber Debian 3.1 oder älter wenn man noch eine GUI nutzen möchte.

Slackware 96 war damals mit X Server als GUI schon nur für ganz entspannte User gemacht.
 
Irgendwie schade, was hier zu lesen war.
Zunächst möchte ich einmal klarstellen, dass ein 486 keineswegs überflüssig oder sonst etwas ist. Wir sind hier in einem Thinkpad-Forum, und wenn jemand bis heute ein lauffähiges Gerät mit 486er Prozessor, am besten noch mit Akku, sein Eigen nennt, dann ist dieses Forum dazu da, das Gerät in Betrieb zu bekommen.

Dieses ist aber nicht dadurch möglich, dass man hierauf ein aktuelles Debian installieren möchte, da ein Debian Bücherwurm bereits viel zu fett für ein solch altes Schätzchen ist. Wenn es also darum gehen soll, einen 486 zu einem MP3- Spieler zu installieren, geht dieses allenfalls mit Software und Betriebssystem aus der Zeit rund um 1995 herum. Mir persönlich fallen hierzu Windows 3.1, Windows 95 und Suse 5.0 bis vielleicht 7.0 ein. Debian hatte ich damals noch nicht auf dem Schirm.

Es geht grundsätzlich um die Frage, warum Linux- Kernelentwickler, oftmals in ihrer Freizeit, weiterhin Code speziell für die 486 pflegen soll, und welchen Sinn dieses ergeben könnte. Wir reden nicht über Pentium oder gar Core2Duo. Wenn ein 486 aufgrund begrenzten Speichers und Rechenkapazität kein aktuelles Linux handhaben kann, muss man dieses auch aussprechen dürfen, ohne für typische "Nerdkultur" angegangen zu werden.
 
Wenn ein 486 aufgrund begrenzten Speichers und Rechenkapazität kein aktuelles Linux handhaben kann, muss man dieses auch aussprechen dürfen, ohne für typische "Nerdkultur" angegangen zu werden.
Speicher und Rechenkapazität sind nicht das Problem veralteter Architekturen.
Debian 10 bootete z.B. noch mit 32MB RAM sauber, und kam selbst mit 28MB noch irgendwie hoch. Danach habe ich es nicht mehr probiert. Und was die Rechenleistung angeht: Dann bootest du eben 30 Minuten statt 30 Sekunden. Wenn du dir das antun möchtest, kannst du das gern tun. Linux hindert dich nicht an dem Unterfangen.

Das Problem sind veraltete Befehlssätze.
Sträflich vereinfachtes Beispiel: Stell dir vor, jemand gibt dir die Aufgabe, die Anzahl der Felder eines Schachbretts zu ermitteln! Du kennst die Lösung nicht und bist auch mit dem Problem nicht vertraut. Also gibt dir der Aufgabensteller folgenden "Befehl": Zähle die Reihen und Linien und multipliziere beide Zahlen!
Nun stell dir aber vor, der "Befehl" "Multiplikation" ist dir nicht bekannt, z.B. weil du Kindergartenkind bist. Du wirst dem Aufgabensteller noch nicht einmal sagen können, dass du keine Multiplikation kannst, denn du hast ja nicht einmal einen Begriff davon. Stattdessen wirst du ihn wohl nur doof anschauen und gar nichts machen. Metaphorisch gesprochen stürzt dein Programm mit einem Segfault ab. Wenn der Aufgabensteller dich als Kindergartenkind erkennt, könnte er dir immerhin den alternativen Befehl geben: "Zähle (addiere) alle Felder!"
Beide Wege führen zum Ziel, aber Ersterer ist deutlich schneller. Und der Aufgabensteller muss deinen "Befehlssatz" erkennen und auf seine Limitierung reagieren können, um von dir ein optimales (schnellstmögliches, korrektes) Ergebnis zu bekommen.

Genau dieser Verwaltungsaufwand zum Erkennen alter Befehlssätze und die Implementierung von Workarounds um ihre Limitierungen ist es, die man als Entwickler gern einspart.

Konkretes Beispiel aus der Praxis:
Bis einschließlich Debian 7 (Wheezy) stellte Debian sowohl einen i486- als auch einen i686-Kernel bereit. Nachdem mit Version 8 (Jessie) die Mindestanforderung von i486 auf i586 angehoben wurde, und man nun einen i586- und einen i686-Kernel anbot, stellte sich heraus, dass das Userland zwar für i586 compiliert sein sollte, aber tatsächlich auch i686-Instruktionen enthielt, weil Einige davon implizit zur Compilezeit gesetzt wurden, und man natürlich aus Performancegründen auf i686-fähiger amd64-Hardware compiliert hatte.
Das Problem fiel nur auf, wenn man Debian tatsächlich auf i586-Hardware ausführte. Zu 90% lief alles entsprechend langsam aber glatt, bis eine i686-Instruktion ins Spiel kam und ein Programm mit einem Segfault starb.

Es gab nun zwei mögliche Lösungswege:
1. Das gesamte Debian-Archiv nach implizit zur Compilezeit gesetzten (und damit schwierig zu findenden) i686-Instruktionen zu durchforsten.
2. Die Mindestanforderung auf i686 anzuheben.

Man hat das Ganze für Debian 8 ausgesessen und dann für Debian 9 die Mindestanforderung auf i686 angehoben.
 
Thorsten Leemhuis schreibt zum tatsächlichen Fortschritt der Aktion:
Support for 486-style CPUs is scheduled to be removed from #Linux according to lots of news sites. But the truth is that the relevant #kernel patches haven't even reached -next yet. ...
 
Zuletzt bearbeitet:
  • Like
Reaktionen: mtu
  • ok1.de
  • IT Refresh - IT Teile & mehr
  • thinkstore24.de
  • Preiswerte-IT - Gebrauchte Lenovo Notebooks kaufen

Werbung

Zurück
Oben