Linux-Kernel: Nur noch zwei Jahre Unterstützung

[cosinus]

Siehe heise --> https://www.heise.de/news/Linux-Kernel- ... 12377.html

Was haltet ihr von dieser Entwicklung? Ist jemand von euch auf einen lange gepflegten Kernel angewiesen?
Ich nutze/installiere ein älteres Linux nur denn, wenn das eine Vorgabe ist, zB haben wir im Büro von unseren Kollegen mal den Auftrag bekommen, VMs für eine bestimmte Software einzurichten. Eine Software erforderte ein älteres Ubuntu 20.04 LTS (normalerweise Kernel 5.4, aber 5.15 ist nachinstallierbar über apt) und eine andere wollte unbedingt ein RHEL oder Rocky 8 (Kernel 4.18)

Wieviel Mehrarbeit haben die Debian-Maintainer nun dadurch wenn sie wie gewohnt ältere Debian-Releases weiterpflegen wollen?

[Upi2017]

Schreibe mal als Privat User, auch wenn es deiner Frage nicht entspricht. Es ist ja vom Büro die Rede, mit alten Kernel.
A: Bei solchen Nachrichten bin ich mittlerweile eiskalt.
B: Das Aus für Cinnamon. Und nun pflegt ein neues Team mein Cinnamon.
C: Kein Mensch weiß, wie es weiter geht. Überraschungen sind schon programmiert.

[cosinus]

Das mit dem Büro war nur ein Beispiel. Natürlich ist mir jede AW recht, auch wenn sie nur von einem Privatuser ist

[Upi2017]

So ein Mist, habe ich es mir doch gedacht bei dir.
Aber nun mal im Ernst. Denke mal, das Debian mich auf die richtige Spur gebracht hat, mit Bullseye und dem Kernel 5.10. Alles hat bei mir 1a funktioniert.
Nun gibt es ja Vertreter, die immer den neuesten Kernel haben müssen, egal ob es Sinn macht, oder nicht. Aus meiner Sichtweise. Belehre mich bitte.
Meine Geräte sind ja auch noch nicht alt. Und trotzdem komme ich mit dem Kernel 5.10 zurecht. Nun gibt es den Kernel 6.......? Also denke ich mal, dass noch viele Jahre abgedeckt sind.
Nun noch ein anderer Gedanke, zum Thema, ich muss immer das neueste haben.
Bei Security ist die Einstellung richtig. Bei Hardware sicherlich nicht. Habe ja auch eine Niewieder Karte, 2060 Super. Fahre heute noch den Treiber 470, obwohl es inzwischen den 530iger gibt.
Die Probleme von meinen Kollegen im LM Forum lese ich mir sehr gerne durch. Dadurch lerne ich selber.
Zudem habe ich folgende Hintergedanken. Wenn ein System funktioniert, dann spiele an diesem nicht herum.
Als ehemaliger Modellhubi Pilot ein absolutes muss. Die 600er Klasse möchte man unter keinen Umständen abbekommen.

[cosinus]

Nun gibt es ja Vertreter, die immer den neuesten Kernel haben müssen, egal ob es Sinn macht, oder nicht. Aus meiner Sichtweise. Belehre mich bitte.

Neue Kernel bringen neue Funktionen und unterstützen neuere Hardware. Es können aber auch Fehler/Bugs beseitigt worden sein. Ich finde es ist schon wichtig, einen halbwegs aktuellen Kernel zu benutzen. Wobei es aber auch vorkommen kann, dass obsolete Dinge irgendwann rausfliegen zB keine Unterstützung von floppy drives oder dem Dateisystem reiserfs mehr.

Ich weiß nicht ob ich die Problematik richtig einordne, aber deswegen gibt es diesen Thread hier ja auch
Also: es gibt ja Distris die richtig lange gepflegt werden also Updates bekommen. Das wären zB Ubuntu LTS oder RHEL. Aber auch das Debian oldstable also bullseye. V.a. bei Debian frag ich mich, wie denn da die LTS-Pflege aussehen soll, denn Debian 11 hat ja Kernel 5.10 und nach dem Plan sollten die Kernel nur noch zwei Jahre gepflegt werden. Wäre das schon der Fall wäre 5.10 seit einem Jahr veraltet. Kümmern sich die Debian Maintainer dann darum oder bekommt ein älteres Debian Relase dann gar einen neueren Kernel solange es noch LTS hat?

[rhHeini]

Bei mir daheim brauch ich in der Regel keine gepflegten alten Kernel.

Die beiden Arbeits-PCs auf AM4-Basis, meinen Laptop (mit ner AMD APU) und den Fileserver (Xeon auf X99-Board) halte ich relativ aktuell (ich fahre seit einem Jahr Devuan Daedalus, der Rechner meiner Frau ist noch auf Chimaera, der Laptop kann beides) und lasse die in der Regel mit Backports-Kerneln laufen, und ich hoffe das die HW noch mindestens 10 Jahre tut. Ich hab da nicht mehr vor viel zu investieren, als Rentner fehlt es mir an Kapital.

Ältere SW hab ich in VMs laufen, z.B. ein 98SE, XP, Win7, Squeeze, Wheezy, ...

Ich hab zwar noch nen paar ältere PCs zum Basteln rumstehen, u.a. ein TR-DLS, die sind aber nimmer am Netz, da läuft dann ein älteres Debian drauf.

[MSfree]

Bei mir daheim brauch ich in der Regel keine gepflegten alten Kernel.

Auch zuhause hat man normalerweise ein Interesse daran, daß der Kernel immer wieder gegen Sicherheitslücken abgedichtet wird.

Debian hat auf jeden Fall ein Problem mit der zweijährigen Unterstützung. Zum Zeitpunkt des Releases ist der Kernel ja schon rund 3 Monate alt und dazu kommen noch die zwei Jahre bis zum nächsten Release. Der Vorgänger soll auch noch 2 Jahre weitergepfelgt werden.

Technisch gesehn könnte Debian natürlich auch alten Releases einen neueren Kernel als Upgrade unterschieben. Das widerspricht aber dem Konzept von Debian, die Versionsnummern stabil zu halten. Ich verweise hier nur mal an die Diskussion um den Firefox-ESR, für den die Mozilla Foundation keine weiteren Updates mehr zur Verfügung gestellt hatte und Debian auf eine neuere Version umsteigen mußte, was zusätzlich einen neueren Rust-Compiler nachsich gezogen hat. Das war eine massive Verletzung des Stable-Prinzips.

[rhHeini]

Bei mir daheim brauch ich in der Regel keine gepflegten alten Kernel.

Auch zuhause hat man normalerweise ein Interesse daran, daß der Kernel immer wieder gegen Sicherheitslücken abgedichtet wird.

Ich krieg die Plege über die backports.

[cosinus]

Ich krieg die Plege über die backports.

Ja, aber genau das will man ja nicht immer. Da will oder muss man dann aus bestimmten Gründen dann zB bei Kernel 5.10 bleiben. Bin mal gespannt wie es mit Debian-LTS und dem Kernel weitergeht.

[Livingston]

Gibt's denn schon Diskussionen auf der Mailingliste des Debian-Kernels? Bin da nicht drauf und ne Suche hat grad nicht viel ergeben. (Tomaten auf den Augen nicht ausgeschlossen. )

[Meillo]

Ich frage mich: Muessten mit zunehmendem Fortschreiten der Informatik nicht die Systeme etablierter, standardisierter und laenger supportet werden? In letzter Zeit beobachte ich aber die gegenteilige Entwicklung. Sehe ich die Informatik nur an der falschen Stelle ihrer Entwicklung oder ist meine Grundannahme falsch oder ist das gerade nur so eine Phase oder spielen noch ganz andere Faktoren mit rein?

[cosinus]

spielen noch ganz andere Faktoren mit rein?

Ich glaube ja es fängt langsam an, dass uns alles über den Kopf wächst. Im heise Artikel steht ja, dass die kernel maintainer mittlerweile ausgebrannt und genervt seien.
Was passiert, wenn man nicht rechtzeitig alte Zöpfe abschneidet bzw. alte Dinge beerdigt, sieht man recht gut an Windows. Windows wurde immer fetter und fetter, das Updatesystem ist nur eine einzige Katastrophem bloat ohne Ende Wie schön, aufgeräumt und easy war das alles noch mit Windows 2000!

[baeuchlein]

Man sollte wohl eher schauen, dass es eine vernünftige Balance zwischen dem "Abschneiden alter Zöpfe" und dem dauernden Hinterherhetzen hinter'm allerneuesten SuperDuperYeahBaby-Krempel gibt. Und man darf darüber auch nicht vergessen, die relativ frisch etablierten Dinge auch mal von Fehlern zu befreien. Wenn ich sehe, dass systemd bei mir immer noch mitten in den Startmeldungen fremdsprachige Zeichen bringt anstatt der drei Punkte ("..."), die dort offenbar hingehören, dann frag' ich mich, wann die Jungs das eigentlich mal angehen wollen. Oder sollte das alles nur bei meinen Systemen liegen? Kann ich kaum glauben - ich sehe wohl eher genau hin, was da läuft...

In den vergangenen ca. 10 Jahren fielen mir immer wieder Dinge auf, die darauf hindeuteten, dass Entwickler versuchten, eine Überlastung durch noch mehr Arbeit und schnelleres Im-Kreise-Drehen zu bekämpfen. Ähnliche Entwicklungen sehe ich auch sonst in der Gesellschaft. Dass das nicht gut geht, habe ich schon vor vielen Jahren gesehen, als bei mir Stress dazu führte, dass gesundheitlich alle roten Lampen angingen. Irgendwann habe ich dann das Studium, obwohl kurz vor dem Abschluss, abgebrochen - wenn ich vor dem Abschluss krepiere, hab' ich nix mehr davon.

Aus meiner Sicht müssen die Entwickler daher auch mal Tempo aus etwas 'rausnehmen. Ich vermute, das würde auch der Qualität helfen. Wie man dann den Spagat schafft, dass manche Dinge (z.B. das Beheben kritischer Sicherheitslücken oder auch die Unterstützung neuer Hardware) relativ zügig erledigt werden müssen, ansonsten aber eher "Eile mit Weile" gefahren wird, weiß ich auch nicht - das Problem muss aus meiner Sicht aber angegangen werden.

Wenn man natürlich meint, man müsste alle Naselang wieder irgendein Kernel-Interface o.ä. ändern, dann ist das kein Wunder, dass man irgendwann in Arbeit ersäuft. Alte Zöpfe nicht abzuschneiden kann da auch mehr Ruhe bringen.

Ich fürchte aber, viele an wichtigen Stellen sitzenden "IT-ler" haben ein ähnliches Problem wie vor ca. 100 Jahren die Ärzte: Waren Letztere damals die "Halb(?)götter in Weiß", sind heutzutage Entwickler oft zu unkritisch hoch angesehen. Man sollte nicht vergessen, dass die einst auch die "Update-Kultur" ins Rollen gebracht haben, bei der man wohl dachte, dank des Internets ist es ja egal, wenn man Fehler im Programm hat - schiebt man halt einfach 'n Update nach, und schon ist alles paletti. Zu dumm, dass bei der heutigen Komplexität ein Update gelegentlich einen Fehler behebt, aber zwei weitere erschafft...

[MSfree]

Das Abschneiden alter Zöpfe bringt für die Maintainer herzlich wenig Entlastung. Wenn ich lese, daß der Floppydisktreiber entfernt werden soll, kann ich nur laut lachen. Da sollen also ein paar Kilobyte an Code, der seit Jahrzehnten unverändert ist, entfernt werden. Im Gegensatz kommen dann mit jedem neuen WLAN-Interface zig Megabytes an Code und Firmware dazu, die noch dazu fehlerhaft sind, weil die Firmen, die solche Kernelmodule erstellen, den Linuxkernel nicht ausreichend verstanden haben. Kein Wunder, daß man für solche neuen Interfaces die Kernelmodule aus Git holen muß, weil sie von den Maintainern noch nicht als reif für die Aufnahme im Kernel erachtet werden.

Natürlich ist es einigermassen sinnlos, heute noch das Floppyinterface zu unterstützen, denn es fehlt inzwischen an Laufwerken und Mainboards/Steckkarten mit dem passenden Interface. Arbeit bereiten solche Kernelmodule aber so gut wie keine, denn der Code ist einfach nur da und schadet nicht.

Arbeit kommt vor allem durch ständig neue Hardware, die neue oder zumindest angepaßte Kernelmodule erfordern. Die Industrie wirft jährlich 20-30 neue Graphikkarten, 50 neue CPUs, 20 neue WLAN-Karten, und ständig mit neuen Funktionen überfrachtete USB-Schnittstellen auf den Markt, und alles soll sofort und fehlerfrei funktionieren.

USB kann inzwischen Diisplayport, HDMI, PCIe und ganz nebenbei sogar noch das traditionelle serielle Protokoll ud das alles gleichzeitig auf demselben Kabel. Das ist inzwischen dermassen Komplex, daß USB mehr Code im Kernel einnimmt als der komplette Kernel 2.0.

[baeuchlein]

Bei dem Floppytreiber sagt wohl der Maintainer, dass er keine Floppycontroller und/oder Laufwerke mehr hat. Da ich fordere, dass ein Programmierer möglichst seine Programme auch testen muss, kann ich das Problem da noch nachvollziehen. Ich habe schon genug Dinge unter Linux (Kernel+andere Software) gesehen, die ich mir nur noch mit Null Testen erklären kann. Das ist IMHO auch für kostenlos angebotene Software zu wenig. Andererseits: Bin ich echt der einzige Linuxer auf dem ganzen Planeten, der noch mehrere alte (aber höchstwahrscheinlich funktionierende) Diskettenlaufwerke im Schrank und in einigen Rechnern drin hat? Und Mainboards mit Floppycontrollern und noch unterstützten CPU-Architekturen gibt's hier auch noch ein paar.

Gut, man kann jetzt drüber diskutieren, ob die Mühe bei dieser alten Hardware noch lohnt. Spätestens, wenn mal wieder an Kernel-Interfaces "geschraubt" wird, wird's dann schwer, da noch für Qualität zu sorgen. Allerdings könnte man die so noch "mitgeschleppten", aber nur noch unzureichend getesteten Treiber ja so "markieren", dass sie in der Kernel-Konfiguration nur angezeigt werden, wenn man ausdrücklich auch solche Treiber will. Ich bin mir sicher, früher mal sowas in der Kernel-Konfiguration gesehen zu haben - jetzt gerade in der Konfiguration für Kernel 5.4.256 allerdings fand ich das nicht (mehr).

Bei der dauernd von der Industrie nachgeschobenen neuen Hardware, die zuweilen nicht mal am Namen eindeutig identifiziert werden kann, fällt mir auch nur ein, dass man möglichst erst mal auf Kompatibilitätsfunktionen setzt, sofern vorhanden. Ich meine sowas wie VESA bei Grafikkarten. Ob sowas bei anderer Hardware auch nur annähernd so weit verbreitet ist, weiß ich allerdings auch nicht.

[rjh]

Kernel 6.6 bekommt noch drei Jahre Support:
https://www.heise.de/news/Linux-Kernel- ... 32885.html

[cosinus]

Andererseits: Bin ich echt der einzige Linuxer auf dem ganzen Planeten, der noch mehrere alte (aber höchstwahrscheinlich funktionierende) Diskettenlaufwerke im Schrank und in einigen Rechnern drin hat? Und Mainboards mit Floppycontrollern und noch unterstützten CPU-Architekturen gibt's hier auch noch ein paar.

Disketten und Laufwerke habe ich im Büro auch noch einige. Aber keinen einzigen Rechner mehr mit dem Controller dazu. Selbst IDE-Controller gibt es nicht mehr. Fliegt das auch bald aus dem Kernel?

[KBDCALLS]

Gerade bei Heise gelesen Kernel 6.6 soll 3 Jahre unterstützt werden.

[bitterlemon]

spielen noch ganz andere Faktoren mit rein?

Ich glaube ja es fängt langsam an, dass uns alles über den Kopf wächst. Im heise Artikel steht ja, dass die kernel maintainer mittlerweile ausgebrannt und genervt seien.
Was passiert, wenn man nicht rechtzeitig alte Zöpfe abschneidet bzw. alte Dinge beerdigt, sieht man recht gut an Windows. Windows wurde immer fetter und fetter, das Updatesystem ist nur eine einzige Katastrophem bloat ohne Ende Wie schön, aufgeräumt und easy war das alles noch mit Windows 2000!

So ganz raff ichs nicht: theoreddisch müsste es da schon Wrapper geben, die die einzelnen Programmteile voneinander unabhängig machen. Die Kernel ist ja keine einzige Datei mit abertausenden GoTo- Anweisungen, die bei der Nachverfolgung zu einem kausalitätszerstörendem Zirkelverweis führen, der den Verstand jedes nachvollziehendem in den Abgrund eines Lovecraft'schen Fiebertraumes ziehen.

Ja, könnte sicherlich eine schwierige Angelegenheit sein und Programmieren ist stressig - Aber ein Artikel kann auch nur so gut sein, wie sein Author/ContentCreator.

Die EOF Timelines seh ich inzwischen eher unter dem Aspekt, wie diese Ankündigung von Mikroweich Fenster 10 - "Danach wird es kein anderes mehr geben" - paar Jahre drauf dann: "Es wird ein anderes geben! Warum? Es ist Neu und Blau - wie ich!" K.a. obs richtig rüber kommt, was ich zum Ausdruck bringen will aber mich interessieren solche Meldungen eigentlich garnicht mehr so richtig. Gut, man könnte sich selbst mit dran beteiligen - das wäre noch eine Idee.

[Livingston]

So ganz raff ichs nicht: theoreddisch müsste es da schon Wrapper geben, die die einzelnen Programmteile voneinander unabhängig machen. Die Kernel ist ja keine einzige Datei mit abertausenden GoTo- Anweisungen, die bei der Nachverfolgung zu einem kausalitätszerstörendem Zirkelverweis führen, der den Verstand jedes nachvollziehendem in den Abgrund eines Lovecraft'schen Fiebertraumes ziehen.

Das ist halt der Unterschied zwischen einem Microkernel und einem Hybrid wie dem Linux-Kernel. (Am anderen Ende der Skala gäbe es noch monolithische Kernel.): Zwar ist viel modular/Microkernel-like aufgebaut (ich vermute, das meinst Du mit Wrappern), aber es bedarf einer soliden Grundstruktur. Und wenn da Neuerungen reinkommen, betreffen sie so ziemlich alles im Kernel - u.U. auch bereits langjährig existierende Module. Hier als Beispiel ein wenig Lesestoff zum Big-Kernel-Lock, an dem 15 Jahre herumgedoktort wurde: https://de.wikipedia.org/wiki/Big_Kernel_Lock

Ähnliches steht heutzutage bevor: Der große Wurf, Rust als zuverlässige Programmiersprache für die Kernelprogrammierung nutzen zu können. Da steckt der Teufel im Detail und kann zu Lovecraft'schen Fieberträumen führen.

Die EOF Timelines seh ich inzwischen eher unter dem Aspekt, wie diese Ankündigung von Mikroweich Fenster 10 - "Danach wird es kein anderes mehr geben" - paar Jahre drauf dann: "Es wird ein anderes geben! Warum? Es ist Neu und Blau - wie ich!" K.a. obs richtig rüber kommt, was ich zum Ausdruck bringen will aber mich interessieren solche Meldungen eigentlich garnicht mehr so richtig. Gut, man könnte sich selbst mit dran beteiligen - das wäre noch eine Idee.

Hu, da gibt's aber einen ganz dicken Unterschied: Linux hat die Vorgabe, die User-API nicht umzumodeln und eben nicht zwischendurch das Rad neu zu erfinden. Aus Usersicht verändert sich der Linux-Kernel evolutionär. Es wird eben nicht ständig alles über den Haufen geworfen. Der Preis dafür ist, dass man innerhalb ganz schön rumrödeln muss, um nach außen hin alles weiterlaufen lassen zu können. Da ziehe ich höchst respektvoll meinen Hut.

[bitterlemon]

Das ist halt der Unterschied zwischen einem Microkernel und einem Hybrid wie dem Linux-Kernel. (Am anderen Ende der Skala gäbe es noch monolithische Kernel.): Zwar ist viel modular/Microkernel-like aufgebaut (ich vermute, das meinst Du mit Wrappern), aber es bedarf einer soliden Grundstruktur. Und wenn da Neuerungen reinkommen, betreffen sie so ziemlich alles im Kernel - u.U. auch bereits langjährig existierende Module.

Hi,
K.A. was jetzt tatsache ist - ich meine der Kernel ist monolytisch (meint Wikipeida ebenfalls in der Section Architektur in https://de.wikipedia.org/wiki/Linux_(Kernel)) aber das ist auch etwas abhängig vom Standpunkt, von wo aus man das betrachtet. Monolythisch kenn ich auch im Zusammenhang mit "aus einer Hand/vom selben Maintainer". Von daher sind wir uns zumindest darin einig, dass es eine Kernel ist, ob monolytisch oder nicht, ... tja ... macht eigentlich keinen großen unterschied für den Anwender; im Grunde läuft die Theorie um Standarts in der EDV eh irgendwann ins leere.

Um Missverständnissen vorzubeugen, mit Wrappen meine ich folgendes: Ich erklärs am Beispiel Firewall . Im Kernel hat man das Modul netfilter. Damit ist es höhere priveligiert als Dinge im Userspace/Ring 3. Man kann sich streiten, ob das jetzt Ring 0, 1 oder 2 ist, falls es da intern noch eine Priorisierung gibt. Müsste man im Source im Zweifel nachsehen.
Wenn man jetzt ufw, iptables oder nftables benutzt, ist das im Userspace, also Ring 3 und hat keinen direkten Zugriff auf die Hardware ansich. Es sind einfach Anwendungen im Userspace/Ring 3, die am Ende des Tages dem Kernelmodul netfilter mitteilen, was es zu tun hat. Ufw, iptables oder nftables sind also - abstrakt ausgedrückt - drum herum gewrapped. Es sind vermittelnde Schnittstellen bzw. Abstraktionsschichten. Die eigentliche Arbeit/Ausführung Calls und Triggern an die, Bsp-Weise Netzwerkkarte, übernimmt netfilter und der jeweilige Gerätetreiber zum HAL.
Wenn ich in Programmen Abwärtskompatibilität herstellen will, dann wrappe ich um die alte Klasse eine neue, rufe erst die Wrapperklasse auf, die dann als Weiche dienen kann, um eine neue Klasse aufzurufen, als auch die bisherige alte Klasse. Im Grunde ist das eine Art von Überladung. Es gibt da auch noch andere Entwicklungsmuster, Bsp-weise eine Factory oder das Plugin Modell. Was ich damit sagen will ist, dass es schon Designmöglichkeiten gibt für solche Probleme. Ich sage nicht, dass das einfach ist und ich weiß effiktiv auch nicht, ob es überhaupt notwendig wäre - ich bin kein Kernelprogrammierer und kann das nicht genau abschätzen.

Kann auch sein, dass ich mich da komplett Irre: Ich hab noch nie in die Kernel Sources reingeschaut und kenn' das nur als Theorie von der Ausbildung. In der Richtung war der größte Move gewesen, dass ich einen Gerätertreiber für Wlan selbst kompiliert hatte.

Ich möchte das auch nicht klein Reden. Das ist durchaus eine Leistung, was sich in den programmierten Zeilen als auch im Organisationsaufwand zeigt.

[Livingston]

Linux liegt eindeutig zwischen monolithisch (griechisch: mono=ein, lithos=Stein, Fels) und Microkernel - allein schon daran zu sehen, dass Module einbindbar sind.
Die Ringe interessieren inzwischen eigentlich gar nicht mehr. Genutzt werden 0 für Hardwarezugriff und 3 für den Rest. Außerdem gibt es Architekturen, die sich um dieses Segmentgedöns gar nicht mehr scheren.
Um Speicher zu schützen, gibt es schon seit Jahrzichten wesentlich bessere und feingranuliertere Techniken.

Deine Beschreibung von iptables/nftables trifft's genau auf dem Punkt, denn eigentlich stellt der Kernel nur die Basics zur Verfügung, welche die Userspaceanwendungen dann nutzen können.
Noch ein einfacheres Beispiel wäre der Bash-Befehl echo. Kannst ja mal selbst recherchieren, durch wieviele Programmier-Schichten diese einfache Textausgabe durch muss, bis sie in den Kernel gelangt, und wieviele Instanzen dann dort aufgerufen werden, um endlich was auf dem Bildschirm zu sehen. Ich komme auf mindestens 5:

• Auswertung in der Bash
• Umsetzung als libc-Aufruf printf
• Übergabe an Lowlevelaufruf write
• Übergabe an Kernelschnitstelle write
• Weitergabe an Hardwaretreiber

Eigentlich habe ich oben deshalb geschrieben, weil noch einiges mehr dazu gehört, als nur Service/Programmierschnittstelle zu sein: Scheduling, koordinierte Input- und Outputpufferung, Prozessorzuteilung, Timer, Interrupt-Anforderungen von innen und außen und Hassenichgesehn.

[Cordess]

Nun gibt es ja Vertreter, die immer den neuesten Kernel haben müssen, egal ob es Sinn macht, oder nicht. Aus meiner Sichtweise. Belehre mich bitte.

Neue Kernel bringen neue Funktionen und unterstützen neuere Hardware.

Neue Kernel werfen auch mal den Support von alter Hardware raus. Insofern ist das nicht immer gut.
386 CPUs werden schon einmal nicht mehr unterstützt. Der 6.0er Kernel war der letzte, der 486er CPUs unterstützt.

Für Retro PCs waren diese Kernel ganz hilfreich, weil man so durch die Installation einer entsprechenden Linux Installation recht einfach eine gute Netzwerkunterstützung bekam um Daten hin und her zu schicken und diese Lösung mit Sicherheitspatches versorgt wurde.

Jetzt ist das alles weg und man muss sich mit so Krücken wie Windows for Workgroups und dessen TCP/IP Stack abfinden und den Retro Rechner in ein eigenes VLAN packen oder alternative aktuelle Betriebssystemlösungen finden. (Minix, irgendein BSD vielleicht?)

Bald dürften die Pentium CPUs folgen und dann fliegt der 32 Bit Support raus.
So ein ewig lange supporteter Kernel ist da dann schon sehr hilfreich.

Wobei es aber auch vorkommen kann, dass obsolete Dinge irgendwann rausfliegen zB keine Unterstützung von floppy drives ...mehr.

Ui, das habe ich noch gar nicht mitbekommen. Wie sieht es denn mit Floppy Images aus? Kann man die dann noch mounten?
Die nutze ich nämlich regelmäßig zum Datenaustausch zwischen VM.

Für spätere Retro Rechner, wie bspw. Pentium CPUs ohne USB Unterstützung dürfte das aber noch ein Problem sein.
Linus Torvald hätte meiner Meinung nach erst einmal warten sollen, bis er auch den Support von Pentium CPUs beendet, denn dann kann man sich sicher sein, dass die nachfolgenden Rechner zumindest alle mit USB Sticks umgehen können.

Aber auch das Debian oldstable also bullseye. V.a. bei Debian frag ich mich, wie denn da die LTS-Pflege aussehen soll, denn Debian 11 hat ja Kernel 5.10 und nach dem Plan sollten die Kernel nur noch zwei Jahre gepflegt werden. Wäre das schon der Fall wäre 5.10 seit einem Jahr veraltet. Kümmern sich die Debian Maintainer dann darum oder bekommt ein älteres Debian Relase dann gar einen neueren Kernel solange es noch LTS hat?

Ich glaube nicht, dass die Debian Maintainer die Pflege eines Kernels ganz alleine stemmen können. Und sollten sich mehrere Distributionen zur Kernelpflege zusammenfinden, dann würde das ohnehin direkt über Kernel.org ablaufen.
Das Naheliegendste wäre daher, dass man auf die nächste noch unterstützte LTS Version wechselt.

[Cordess]

Ich frage mich: Muessten mit zunehmendem Fortschreiten der Informatik nicht die Systeme etablierter, standardisierter und laenger supportet werden? In letzter Zeit beobachte ich aber die gegenteilige Entwicklung. Sehe ich die Informatik nur an der falschen Stelle ihrer Entwicklung oder ist meine Grundannahme falsch oder ist das gerade nur so eine Phase oder spielen noch ganz andere Faktoren mit rein?

Ich sehe das auch so, dass uns das alles über den Kopf wächst.

Aber da hört es ja noch nicht einmal auf, siehe Internet of Things, Häuser mit Smart Home Infrastruktur etc.. Der eigene PC ist da noch das kleinste Übel.

[Cordess]

Bei dem Floppytreiber sagt wohl der Maintainer, dass er keine Floppycontroller und/oder Laufwerke mehr hat. Da ich fordere, dass ein Programmierer möglichst seine Programme auch testen muss, kann ich das Problem da noch nachvollziehen.

Ich nicht. Wer sich als Maintainer eines Floppycontrollers meldet. Der sollte doch zumindest über einen alten Retro Rechner mit entsprechender Ausstattung verfügen und diesen auch behalten, damit er den Floppycontrollercode testen kann, sofern sich da Änderungen ergeben.

Andererseits: Bin ich echt der einzige Linuxer auf dem ganzen Planeten, der noch mehrere alte (aber höchstwahrscheinlich funktionierende) Diskettenlaufwerke im Schrank und in einigen Rechnern drin hat? Und Mainboards mit Floppycontrollern und noch unterstützten CPU-Architekturen gibt's hier auch noch ein paar.

Nein, bist du nicht. Ich habe noch alle meine alten Rechner mit Ausnahme meines 286er, der wurde im Rahmen des Upgrades auf einen 486er verkauft.

Bei der dauernd von der Industrie nachgeschobenen neuen Hardware, die zuweilen nicht mal am Namen eindeutig identifiziert werden kann, fällt mir auch nur ein, dass man möglichst erst mal auf Kompatibilitätsfunktionen setzt, sofern vorhanden. Ich meine sowas wie VESA bei Grafikkarten. Ob sowas bei anderer Hardware auch nur annähernd so weit verbreitet ist, weiß ich allerdings auch nicht.

NVidia hat doch schon recht frühzeitig zur Zeit der ersten Geforce Karte (oder war es sogar der TNT Chipsatz) einen ordentlichen VGA Support aufgegeben. Wer eine ordentliche Unterstützung der von DOS Programmen unterstützten VGA Modi wollte, der setzte auf die Konkurrenz von 3DFX, die haben sich wenigstens noch um eine hohe Kompatibilität bemüht.