Installationsbericht Jessie 8.2 Bugs & Bees

[SGibbi]

"Fehler im Skript" besagt, daß ein Skript einen Fehler enthält.

Falls man Debian Jessie i586 auf einer "echten" i586 / K6 Maschine ausführt, bekommt man gelegentlich diese Fehlermeldung, und sie verschwindet bei gleicher Software und gleicher Website, falls man die Festplatte in eine i686 Maschiene einschiebt. Das ist dann, wenn auch nicht eindeutig erkennbar, tatsächlich ein Hardwareproblem.

Das openJDK Java aus Debian Jessie funktioniert bei mir ansonsten durchaus, und deshalb soll es hier kein Java Thread wie anderswo werden.

Sagen wir, wo i586 draufsteht, da sollte auch i586 drin sein. Und wenn es eigentlich i686 ist, sollte das auch so bezeichnet werden. Nix gegen technischen Fortschritt, ich wollte ursprünglisch die Fehldeklaration (und nicht nur in Debian) kritisieren. Immerhin kommt man mit Debian i586 und einer i586 CPU noch bis in dieses Forum, aber ein wirkliches i586 Betriebssystem ist Jessie halt nicht mehr. Obwohl es als ein Solches bezeichnet ist.

[hikaru]

Falls du exakt das Paket (oder eine Gruppe von Paketen die aus dem selben Source-Paket gebaut werden) identifizieren kannst, würde ich dafür einen Bugreport aufmachen.
Ich habe das kurz vor dem Jessie-Release (und daher bezüglich der Recherche überhastet) für Browser (was sich als libwebkit-Problem herausstellte: 783293) und Videoplayer (stellte sich als libav-Problem heraus: 783082) gemacht. Für libav ist das Problem beseitigt. Bei libwebkit stellte es sich als zu kompliziert heraus i586 und i686 zu trennen, wobei die Performanceeinbußen für i686 als zu gravierend angesehen wurden um die Pakete i586-kompatibel zu machen.

Im aktuellen Zustand ergibt Jessie/i586 nicht viel Sinn. Ich finde das sollte für Stretch bereinigt werden, indem man:
1. sauber funktionierende Weichen in allen betroffenen Paketen einbaut
2. i586 und i686 in eigene Repos auftrennt
3. i586 fallen lässt.

1. und 2. haben das Problem, dass der Aufwand das ganze Repo zu durchforsten groß wäre, wohl kaum ein Maintainer noch Zugang zu i586-Hardware hat, und selbst wenn doch wäre es wohl wegen der geringen Performance der Plattform wohl aufwendig hier gründlich zu testen. Eine i586-Qemu-VM ist keine wirkliche Alternative, denn die ist selbst auf schneller Hardware noch langsamer als auf einer echten i586-Maschine.
3. wäre natürlich schade für alle die noch i586-Maschinen betreiben, aber man hätte dann wenigstens wieder einen sauberen Zustand.

[SGibbi]

Eure Forensoftware hat mir gerade meinen Beitrag gefressen. Nach einem Timeot und wieder Einloggen war mein Beitrag leider weg. Also nochmal.

Vielen Dank für die Antwort, zudem Du offenbar auch einiges an Herzblut in die Sache investierst.

Gefordert wird:

(1) Die Programmierer mögen ihre Pakete gemäß dem von ihnen gesetzten Compilerflag benennen. Der Programmierer (spätestens der Compiler) weiß ja durchaus, welches CPU Flag er für die Compilierung gewählt hat, und er soll sein Binärpaket denn bitteschön auch entsprechend kennzeichnen.

(2) Die Software Tester sollen bitteschön nicht nur nach ihrer theoretischen Vorbildung, sondern auch an der von ihnen eingesetzten Hardware ermessen werden. Wer i586 testen will, soll nachweisen, daß er i586 benutzt. Wer AMD64 testen will, möge vorab nachweisen, daß er AMD 64 benutzt. usw.

Zur Diskussion:

Phu, Ich bin zu neu für Debian, um die Interna um die Programmierer zu kennen, wäre dort wohl auch kaum willkommen. Zu meiner Zeit (die noch gar nicht sooo lange her ist) gab es noch kein Informatikstudium, oder wenn, dann nur an wenigen Unis und in den Kinderschuhen. Es war in den frühen 1990ern eine ziemliche Aktion, unsere Professoren endlich vom Fortran 66 wegzubringen um wenigstens mal C- (ANSI-C) zu unterrichten. Im Gegenzug habe ich die Klobberei um CP/M und Unix ("echtes" Unix) noch am Rande miterlebt.

Vieles was wir Heute neu zu lösen ersuchen, ist aus meiner Sichtweise eigentlich ein "alter Schuh", der halt irgendwie wieder neu erfunden wurde. "Früher", sagen wir mal IBM 360 bis 8-Bit Aera (6002, Z-80, usw) war Software grundsätzlich quelloffen, mit CP/M gab es bereits ein plattformunabhängiges Betriebssystem und mit dBase, das nicht nur eine Datenbank, sondern auch eine Programmiersprache war, eine platformunabhängige Skriptsprache. Es gab z.B. einen platformunabhängigen dBase-Fork für das Spiel "Tetris".

Das war sicherlich nicht alles besser. Man sollte aber wissen und aus den Erfahrungen gelernt haben.

Um dem technischen Hardware Fortschritt genügend schnell folgen zu können, etablierten sich seinerzeit grundsätzlich zwei plattformunabhängige Systeme:

(1) Quelltextbasiert, z.B. UNIX. Die Software lag im offenen (aber nicht copyrightfreien) Quelltext vor (bei Unix in C, für 8-Bit meist in BASIC), Sie konnte per Interpreter geprüft, und dann für schnellen Ablauf compiliert werden. Die resultierende Compilation (Binär) ist für die jeweilige Maschine optimiert, sodaß sich trotz Hochsprache eine gute Performance ergibt. Der Quelltext hinggen ist völlig plattformunabhängig soweit der Compiler plattformunabhängig ist.

(2) Binärbasiert, z.B. CP/M. Das Betriebssystem verfügt über einen gesplitteten Kernel. Der hardwarenahe Teil des Kernel (Heute würde man "Treiber" sagen) wird per Assembler angepaßt, wie auch insgesamt aus Performancegründen Assembler bevorzugt wurde (z.B. war die Textverarbeitung "Wordstar" in purem CP/M Assembler programmiert). Weitere Teile des Systemkern und auch die aufgesetzte Software sind in Binärdaten (zumindest theoretisch) hardwareunabhängig plattformübergreifend austauschbar.

Verschlossene Quellen bei Weitergabe von Binärdaten kamen mit der Aera 16 Bit und ist eng an den Softwaregedanken von Redmond verknüpft. Redmond 16 Bit sehe ich nach wie vor als einen CP/M 86 Clone, vom gesplitteten Kernel über die Einbindung von Treibern, den abgesetzten Kommandointerpreter (z.B. Windows 16-Bit) usw. Spätestens mit der Umstellung nach 32-Bit kam Redmond nicht mehr nach und bediente sich (wohl unter Druck von OS/2) im großen Stil an Unix. So sind z.B. wesentliche Teile von Windows in C erstellt und unixtypisch programmiert. Freilich bei verschlossenen Quellen, und per "Bioslock" und "Aktivierung" künstlich an eine Hardware geknüpft.

"Otto Normalverbraucher" hat sich dran gewöhnt und zahlt. Wohl 99% aller Computer werden verkauft, weil der User zu Hause genau das will wie auf der Arbeit. Die Zeiten, da Arbeitgeber ihre Mitarbeiter schulten sind bekanntlich vorbei. "Otto Normalverbraucher" würde selbstredend auch Unix oder sonstwas teuer kaufen, wenn das auf der Arbeit und für den Broterwerb sinnig erscheinen würde. Denn wirklich Anwenden tun die Wenigsten. So weit, so schlecht.

Problem modernr Software, gleich welcher, ist das Mißlingen der Mischung von Quellbasiertem und Binärbasiertem Prinzip. Einerseits benötigt man mittlerweile zwingend das am Quelltext basierte plattform unabhängige Prinzip, um mit bestehender Software genügend schnell dem Hardware Fortschritt folgen zu können Andererseits hängt man am binärbasierten Prinzip, weil nicht menschenlesbare Binärdaten einen recht guten Kopierschutz bewirken, weil "Otto Normalverbraucher" dran gewöhnt worden ist und wohl kaum noch bereit wäre, freiwillig einen Quelltext zu compilieren. Auch hat sich der gesplittete Kernel mit der Möglichkeit der Einbindung von quellverschlossenen Binärtreibern bewährt, obwohl monolithische Kernel ja doch grundsätlich leistungsfähiger wären.

Gewünschter Blick nach Vorne:

Es gibt verschiedene Möglichkeiten die Problematik um Hardware(in)kompatibilität und des Fortschritt anzugehen, z.B.

(1) Back to Unix, zurück zum Quelltext. Das ist gar nicht mehr sooo aufwendig da es schon seit geraumer Zeit sog. "Makefiles" gibt, kann die Compilierung automatisiert werden. Ob der Installer nun ein ZIP entpackt oder einen Quelltext compiliert ist "Otto Normalverbraucher" herzlich egal. Nachteile: Hohe CPU Belastung während der Installation, die Binaries sind grundsätzlich für die Hardware optimiert (kann auch ein Vorteil sein, je nachdem). Vorzug: Vergleichsweise kompakte Distribution, da (fast) nur noch Quelltext gepflegt werden muß. Jederzeit problemlos erweiterbar. Und, wesentlich, Die Sch*** läuft stabil, und zwar tatsächlich platformunabhängig.

(2) Binärbasiert, für jede Hardwaregeneration eine eigene, geringfügig anpaßbare Compilation aus selbem Quelltext. Vorzüge: Entspricht dem, was "Otto Normalverbraucher" aus Redmond beigebracht wurde, geringe CPU Belastung (schnell) während der Installation, Binärpatches (modularisierte Treiber) sind möglich, ohne das System neu compilieren zu müssen. Nachteil: Es wird einiges an Performance und Stabilität verschenkt, weil auf exakte Hardwareanpassung, wie ja eigentlich möglich, verzichtet wird. Und wesentlich: Die Distributionen quellen sehr stark auf und sind faktisch nicht mehr zu pflegen. Auf diesem Wege werden sowohl Redmond und insbesondere auch das distributionsgebundene Linux längerfristig "auf die Schnauze" fallen.

(3) Virtualisierung, z.B. durch Java. Die Programme laufen unabhängig von Hardwareplattform und Software Compilation, müssen auch nicht in die Distribution eingebunden werden (z.B. für kommerzielle Linux Anwendungen gut geeignet). Nachteil: Geringe Performance, und mit sehr viel Aufwand hat man schlußendlich etwas erreicht, wie es vor Jahrzehnten bereits üblich war. DOS Programme, zum Beispiel, liefen unabhängig der jeweiligen DOS Version und (zumindest anfangs) auch in Windows (oder z.B. im Dosemu von Linux). Binärunabhängigkeit ist ja nun keine Erfindung von Java, das konnte CP/M, wenn auch auf 8-Bit-Niveau, schon in 1974.

Für die Istzeit:

Plädiere ich für eine Mischcompilation. Es ergibt keinen Sinn, z.B. HD-Videoplayer noch für i586 zu compilieren, oder z.B. Transcoder für 32 Bit.

Im Gegenzug sind Programme, die in großem Umfang auf Bussysteme, Netzwerke oder gar "langsame" Festplatten zugreifen müssen in i586 oftmals schneller, weil die Datenmenge kleiner ist. So ist z.B. "Iceweasel i586" eine wirklich schnelle Software, gemessen z.B. an den 64-Bit Tarballs aktueller Mozilla Ausgaben.

Büroprogramme sollten grundsätzlich laufen, ihre Verarbeitungsgeschwindigkeit spielt keine große Rolle, daher sollten sie nach meinem Ermessen i586 compiliert sein.

Bei Spielen ist es sehr unterschiedlich. Das Urtetris konnte man noch in "i8080" auf der Konsole spielen, viele der modernen 3D Spiele sind faktisch nur auf AMD64 flüssig spielbar.

Alternativ:

Wenn schon hardwarebasierte Distros, dann bitte richtig, und "ewig" gepflegt. Nennen wir es mal "Debian i586". Was die "i586" Aera nicht kann, braucht man in einer solchen Distro nicht implemendieren. Damit ergibt sich ein natürliches Limit und ein (hoffentlich) überschaubarer (und mit der Zeit auch sinkender) Pflegeaufwand. Und nach jahrelanger Pflege hoffentlich schlußendlich mal ein wirklich stabiles System. Falls "Debian Wheezy" in i586 tadellos läuft, wie oben angekündigt, und tatsächlich, wie bei Wikipedia angekündigt, bis 2018 gepflegt wird, so wären die entsprechenden Rechner bis dahin mindestens 20 Jahre alt. Was wohl auch den weiteren Pflegeaufwand für "ewige" Distros wieder verringern würde. Gebe gerne zu, Hardwarebindung ist nicht gerade Unix-alike, aber sie wäre eine Möglichkeit, sinnige Milestones zu setzen.

Wünsche schönen Sonntag noch.

[DeletedUserReAsG]

Wieder schön geschrieben, wieder diverse inhaltliche Fehler. Ich geh’ mal nicht wieder drauf ein, erfahrungsgemäß interessiert’s dich eher nicht.

Dieser Beitrag ist nur ein Hinweis für Leute, die etwa via $suchmaschine drauf stoßen.

[SGibbi]

Naja, ne Klobberei um Java müssen wir uns nicht geben. Du siehst es aus der Seite des Programmierers (abweichende Syntax), ich sehe es aus der sicht des Administrators (die selbe Engine). Jeder kann "Recht" behalten oder auch nicht.

Danke fürs Lob.

[DeletedUserReAsG]

Ich meinte hier eher andere Sachen, etwa den angeblichen direkten Zusammenhang zwischen der Architektur eines Binarys und seiner Geschwindigkeit. Überhaupt scheinst du dir einige Zusammenhänge eher herbeigedichtet, als recherchiert oder gar gelernt zu haben. Entsprechend wirr sind deine Vorstellungen.

Und bitte, informiere dich auch über Java und JavaScript. Da ist nichts gleich, außer den ersten vier Buchstaben im Namen. Schon gar nicht irgendeine „Engine“. Hat nichts mit „Recht behalten“ zu tun, es sind einfach verschiedene Sachen – egal aus welcher Sicht.

Keine Sorge, ich halte mich fortan aus dem Thread raus. Bin mir gerade sowieso nicht sicher, ob das ernstgemeint ist.

[Lord_Carlos]

Ich glaube er spricht von Java vs. Java applet.

[DeletedUserReAsG]

Das würde zu der Aussage passen, dass es das Gleiche wäre, ja. Aber dann passen andere Aussagen wieder nicht:

Völlig anders sieht es wiederum aus, falls man z.B. für Firefox nicht die "hauseigenen" Compilations benutzt, sondern die offiziellen Mozilla Tarballs, denn diese enthalten wiederum ihr eigens Java, das sich meist in Dateien wie "libmozjs.so" (usw.) versteckt.

… z.B. da spricht er wieder von Java und meint JavaScript, nicht Java(-Applets).

Ich finde halt, wenn man so längliche Artikel mit dem Anspruch, andere damit zu informieren, verfasst, sollte man einigermaßen wissen, wovon man schreibt. Und die Sache mit Java/JS ist halt nicht das Einzige ….

[SGibbi]

Sorry, Java Klobberei muß jetzt nicht sein.

Und sorry das noch einmal hoch zu holen, aber das folgende Problem füllt laut Google seit nun mehr als 5 Jahren etliche Forenthreads. Habe zwar keine wirkliche Lösung, aber wenigstens eine Ursache gefunden. Also: Ich habe mal meinen alten Pentium II beigeholt (Siemens Nixdorf Xpert 7800, Marken PC aus 1998) und die Debian 8 Festplatte reingeschoben. Pentium II ist nun wirklich i686 pur, und man sollte glauben, daß ein i586 spezifiziertes Betriebssystem wie Debian 8 i586 wenigstens auf i686 uneingeschränkt lauffähig wäre. Das ist es leider nicht. Beim Start von KDE läuft es bis zum Splash Screen, dann bricht der Boot ab und ich bekomme in einem X-Terminal die folgende vieldiskutierte Meldung:

Code: Alles auswählen

root@Debian-8:~# Could not start ksmserver, Check your installation

Das ist einigermaßen verwirrend, weil "ksmserver" als Solches in keinem Paket angeboten wird, sodaß man die Fehlermeldung nicht zuordnen (oder gar beseitigen) kann, zumindest nicht mit "einfachen Mitteln". Also fahre ich alles X herunter, finde mich im Konsolen Modus wieder (den ich als alter DOS Hacker mag und tippe:

Code: Alles auswählen

root@Debian-8:~# ksmserver
root@Debian-8:~# The current CPU does not support SSE

Das ist durchaus korrekt, der Pentium II hatte nunmal keine SSE Unit. Die gibt es in der Intel Welt erst ab Pentium III. Das eigentliche Problem dürfte damit geklärt sein, die Software ist einwandfrei, wie ein Wechsel der Festplatte in andere Hardware beweist, hier ist die CPU schlichtwegs zu schwach. Das ist ein Hardwareproblem. Will das einfach mal mitteilen, falls noch einmal jemand mit dem Problem ankommt.

Ansinsten, LXDE läuft, Iceweasel läuft (in Grenzen, schlechter als auf einem AMD K6), man hat ein aktuelles Betriebssystem und einen zeitaktuiellen Browser und kommt mindestens bis ins Debian Forum, um sich Rat zu holen. Das ist doch schonmal was.

Es verbleibt das Problem der etwas unsauberen Deklarierung von Linux Software, wie bereits angesprochen. Das ist, wie bereits gesagt, sicherlich kein reines Debian Problem, aber ziemlich "Scheiße", Falls Du i586 tatsächlich auf i586 installierst und nach Stunden feststellst, daß die Deklaration schlichtwergs erlogen war. i586, wie deklariert, ist Debian 8 sicherlich nicht, es ist nicht einmal mehr i686. Auch für Software Entwickler ist so etwas sehr ärgerlich. Man könnte ja i686 compilieren und Performance Vorzüge geben, aber es ist nunmal ein i586 Betriebssystem, also compilieren "ehrliche" Entwickler tatsächlich auf i586, und haben hinterher in Sachen Performance das Nachsehen bzw. werden kritisiert. Wer hingegen bewußt lügt, genießt den Vorzug, solange man es nicht wirklich mal auf Spezifikation prüft.

Also, liebe Leute, deklariert Eure Compilations doch bitte genau so, wie sie compiliert wurden.

Ich wurde in weiter oben als "ungelernter Anfänger" beschimpft (habe studiert, bin tatsächlich kein Lehrberufler) als ich für eine "Mischcompilation" plädiert habe. Nun, lliebe Leute, hier ein paar "Benchmarks", aufgenommen mit der Freeware "memtest86" in Version 4.0:

"Echtes" Intel i586, Pentium MMX mit 166 MHz auf Board Gigabyte GA-586 HX, mit Intel Chipsatz, 512 KB Cache, nacgerüstetem TAG-RAM und immerhin 128 MB RAM, BIOS Datum 21.08.1996:

Datendurchsatz Hauptspeicher = 145 MB /sec. (PS/2 RAM)

Auf diesem Rechner laufen bei mir Caldera Open Linux oder SuSE 9.1 und der kann durchaus Büroanwendungen oder z.B. MP3 Wiedergabe. Das Board gilt als eines der Besten Sockel 7 Boards (wenn der Dallas Chip noch funktioniert ...) aber für HD-Video usw. ist das bei allem gebührenden Verhalt schlichtwegs zu langsam.

Der bereits erwähnte Pentium II (350 MHz), echtes Intel i686, im Siemens Xpert (BIOS Datum 19.06.1998, etwa 2 Jahre jünger) kommt immerhin auf

Datendurchsatz Hauptspeicher = 259 MB /sec. (DIMM 168 RAM)

Das ist in etwa 2 Jahre jünger und in etwa doppelt so schnell. Auch damit kann man sehr gut MP3 hören, auch eine 96/24 Soundkarte geht hier, und "Iceweasel" läuft durchaus flüssig bis zum Absturz wegen zu kleiner CPU.

"Falsches i586" wäre z.B. mein bereits mehrfach erwähnter K6 Rechner.Bei BIOS Datum 31.12.1999 (smile, ist wirklich so) bringt er es immerhin auf

Datendurchsatz Hauptspeicher = 288 MB /sec.(DIMM 168 RAM)

Das DFI K6-BV3+ ist eines der schnellstern Sockel-7 Boards und auch gefühlt schneller als ein Pentium II. Man kann damit auch noch Heute ganz gut internetten, und ich habe eine ausgesprochene High End Soundkarte drin. Video, naja, mit VLC Version "Goldeneye" und vielleicht in Auflösung 320 * 240 ist es tatsächlich noch flüssig.

Zum Vergleich: Pentium IV Prescott Hyper Threading (virtuelle Doppel CPU) 3 GHz auf Board Elitegroup PF 1 Photon (in zartem Lila und mit vielen blinkenden LED) mit Intel Springdale Chipsatz und 2 GB RAM im Tile Mode (paarige RAM)

Datendurchsatz Hauptspeicher = 2326 MB /sec.(Tile Mode, DDR-1 400 und CAS 2,5-3-3-8)

Das ist (auch gefühlt) in etwa zwehnmal schneller als i686 bei einem (inoffiziellen) BIOS Datum 14.11.2003 ist das Board geratemal 2 bis 3 Jahre jünger.

Zum Vergleich: AMD Athlon 64 3200+ (Venice Kern) mit real 2 GHz auf Asrock ALiveNF6G-DVI (Sockel AM 2) mit 1 GB DDR-2 (533) RAM, BIOS Datum 26.09.2006:

Datendurchsatz Hauptspeicher = 1692 MB /sec.

DDR-2 wurde oft belächelt, gefühlt ist die 64 Bit Maschine durchaus auf Pentium IV Niveau, aber wehe, man mißt es nach, dann wird es arg peinlich.

Zum Vergleich: Intel Core Duo E 5700 2 mal 3 GHz auf Asrock G 41 MH mit 2 Stück "Corsair" High End DDR-3 Speichern je 4 GB und im schnellen Paarmodus:

Datendurchsatz = 3402 MB /sec. (Tile-Mode, 64 Bit, DDR-3)

Bei einem BIOS Datum 08.06.2011 ist das Board beinahe noch "aktuell" und fast 10 Jahre jünger als der Pentiuum IV aus zuvor. Befeuert mit gleichem Linux Betriebssystem geben sich die beiden Rechner nicht viel, allenfalls bei wirklich prozessorlastigen Anwendungen wie z.B. dem Recodieren von Video ist das aktuelle Board tatsächlich merklich schneller.

--------------------------

Hardware Bindung ist zwar garnicht Linux-Alike, doch es verbleibt der Wunsch bezüglich hardware optimierter Linux Versionen. Nee, mit wirklich i586 optimiertem Linux ohne Ballast wie PCI-E oder USB 3 usw. im Kernel kann man auch noch Heute Büro und internetten und wirkliches High End Audio. Sofern es denn endlich mal wirklich endlich mal stabil wird.

Und Video und Recodieren macht auf solchen Maschinen keinen Sinn. Und warum sollten die Software Entwickler ihre Binaries denn nicht ehrlich deklarieren dürfen ?

Nach mittlereile rund 25 Debian 8 Installationen möchte ich bei allem gebührenden Verhalt (GPL Haftungsausschluß) einen Intel Pentium III /800 (1999, geprüft mit Siemens T-Bird) oder einen AMD Athlon XP ab Thoroughbred 1600+ (ca. 2002, auf DFI Board) als Minimum angeben. i586 ist das sicherlich nicht, aber auch schon 12 bis 15 Jahre alt, und noch immer massiv und preisgünstig auf dem Gebrauchtmarkt zu finden.

Daß noch ältere CPU auch nicht schlecht waren, steht außer Frage. Schon mit einem IBM XT aus 1982 konnte man prima BBS und Fidonet machen, Textverarbeitung und nächtelang Tetris spielen, usw.

Gab / Gibt es eigentlich unixioiide Betriebssysteme für 8088 oder 80286 ? Ist ja nur ne Frage ...

[DeletedUserReAsG]

ksmserver: https://packages.debian.org/search?sear ... e&arch=any

Dein Problem damit, dass KDE unter der non-SSE-CPU nicht läuft, ist auch schwer nachvollziehbar: keiner, der eine solche Hardware ernsthaft nutzen möchte, käme auf die Idee, überhaupt KDE draufzutun. Es gibt genug Alternativen mit der Aussicht, unter den Hardwarevoraussetzungen einigermaßen nutzbar zu sein. Auf der anderen Seite gibt es eine Menge Pakete, die bestimmte Hardware(-eigenschaften) voraussetzen, welche nicht unbedingt in jedem Gerät zu finden ist. Was forderst du also? Dass für jede mögliche Hardwarezusammenstellung ein eigener, kompletter Zweig gepflegt wird? Dann könnte sich Debian mit „Unterstützt 1827 Architekturen!!k“ rühmen – und wäre unwartbar. Oder soll lieber das ganze System mit der minimalen Hardwarevoraussetzung gelabelt werden, unter der alles zum Laufen zu bekommen ist? Dann dürften min. 99,99% der existierenden Systeme offiziell nicht unterstützt werden. Meiner Meinung nach: derzeit wird angegeben, unter welchen Voraussetzungen es grundlegend läuft. Dass einzelne Pakete andere Voraussetzungen haben mögen, sollte jedem klar sein, der einigermaßen realistisch eingestellt ist. Ein tatsächliches Problem wär’s, wenn in der Beschreibung „läuft auf i586“ stünde, und der Installer beim Grundsystem mit „läuft nicht unter i586“ ausstiege.

Was „Java Klobberei“ angeht: keine Ahnung, was ein „Klobberei“ ist – aber du hast Schlussfolgerungen aufgrund falschen Verständnisses der Tatsachen gezogen und es wurde korrigiert. Ich sehe da kein Problem mit. Ist besser, als wenn ein unbedarfter Leser deine faktisch falschen Behauptungen wahr annimmt, weil keiner widersprochen hat.

Gab / Gibt es eigentlich unixioiide Betriebssysteme für 8088 oder 80286 ? Ist ja nur ne Frage ...

Minix vielleicht, wenn das unixoid genug ist. Linux jedenfalls lief nie auf Sachen unterhalb von 80386.

[SGibbi]

ksmserver: https://packages.debian.org/search?sear ... e&arch=any

Dank für den Link.

Dein Problem damit, dass KDE unter der non-SSE-CPU nicht läuft, ist auch schwer nachvollziehbar: keiner, der eine solche Hardware ernsthaft nutzen möchte, käme auf die Idee, überhaupt KDE draufzutun.

Naja, wie gesagt, die exakte Debian Grenze habe ich noch nicht probiert, im Moment läuft auf meinem K6 / i586 ein SuSE 11.2 mit KDE 4. Durchaus brauchbar und Stabil. Man muß allerdings sehr genau aufpassen, das originale SuSE Release aus 2009 ist arg instabil, und mit dem Long Term Support kam so manches Paket, das unter i586 gar nicht mehr läuft. Die Installation nutze und pflege ich seit mehr als 5 Jahren. Ich war damit fleißig auch bei ebay und auch bei GMX unterwegs, habe 96/24 Referenz Tonaufnmahmen z.B. aus alten Plattenspielern gezogen, pflege eine umfangreiche Bildersammlung auf diesem System, und habe mehrere Bücher auf der Hardware geschrieben. Ist das "ernsthaft" genug ? Flaschenhals ist der Webbrowser, daher meine Begeisterung für iceweasel. Außerdem ist der SuSE Support seit Oktober komplett beendet (mittlerweile vom Server gelöscht)

Was forderst du also?

Daß die Softwareentwickler (alle, nicht nur die Debianies) von Anfang an ehrlich dranschreiben, was sie compiliert haben, denn das im Nachhinein zu probieren kostet unendlich Zeit.

Dass für jede mögliche Hardwarezusammenstellung ein eigener, kompletter Zweig gepflegt wird? Dann könnte sich Debian mit „Unterstützt 1827 Architekturen!!k“ rühmen – und wäre unwartbar.

Genau. Ich plädiere daher dafür, eine bereits vorhandene, gepflegte und bewährte Architektur weiter zu pflegen (z.B. Bugfix, Webbrowser), jedoch auf "i586" in Zukünftiger Version zu verzichten. Der Aufwand bleibt sich in etwa gleich, jedoch hat man dann keinen "Ballast" wie PCI-Express oder USB 3 auf der alten Maschine.

Oder soll lieber das ganze System mit der minimalen Hardwarevoraussetzung gelabelt werden, unter der alles zum Laufen zu bekommen ist? Dann dürften min. 99,99% der existierenden Systeme offiziell nicht unterstützt werden.

So ist es, und das kritisiere ich, denn das muß nicht sein.