News Release Candidate: Linus Torvalds hat den neuen Linux-Kernel 6.0 freigegeben

[jenzen]

Microkernels sind architektonisch vielleicht schöner aufgebaut als monolithische Kernels, aber das alleine macht noch keinen guten Kernel aus, weil Microkernels viel komplizierter sind durch die ganze Kommunikation der einzelnen kleinen Teile untereinander, und dadurch steigt die Anfälligkeit für Fehler (oder auch "nur" Performanceengpässe etc.) rapide an. Sowohl Windows NT als auch Linux sind sich außerdem näher als man denkt, obwohl NT ursprünglich auf einem Microkernel aufbaute und Linux nicht. Das liegt daran, dass Linux modular ist und einiges auch schon in den Userspace ausgelagert hat (wie z.B. udev, libusb, ...), und zum anderen ist Windows NT seit langem schon ein "hybrider Kernel", d.h. hat sich bereits schon vor längerer Zeit vom Design her dem monolithischen Kernel angenähert (IIRC, aufgrund von damaliger schlechter Performance). Vom Erfolg her gesehen hat sich Linus Torvalds' Design als das in der Praxis bessere bewährt, deshalb hat sich der WinNT Kernel dem auch angenähert, um nicht zu viele Nachteile zu haben. Denn was bringen einem theoretische architektonische Vorteile, wenn sie in der Praxis dann eh nicht ausgenutzt werden können.

 

[I'm unknown]

Eigentlich ist das simpel

Nun ja, so einfach ist das nicht. Da die Änderungen von vielen Leuten beigesteuert werden wäre das bei jedem Release eine Diskussion.

Früher wurden die Versionsnummern sehr lange hochgezählt und es gab Entwicklerkernel (mit ungerader Nummer, z.b. 2.1.x, 2.3.x, 2.5.x). Bei 2.6 ging es sehr lange hoch - leider jedoch nicht ganz bis zur 42 .

Solange die Versionsinkrements der einzige Kritikpunkt beim Kernel ist machen die Entwickler wohl viel richtig

 

[andy_m4]

Die kompletten Treiber-Sourcen zu haben und den Kernel als ganzes bauen zu können ist einfach ein Vorteil.

Man kann ein ganzes Projekt bauen können und trotzdem Modularität haben. Das eine schließt das Andere nicht aus.

Und schicke Abstraktionen sind nicht immer schnell, und Zeit ist Geld.

Abstraktionen kosten nicht zwangsläufig Zeit. Rust ist ja nun nicht gerade langsam. Aber man braucht nicht mal da gucken, sondern da reicht ein Blick auf das gute alte C++. Eine zentrale Idee ist dabei Abstraktionen einzubauen ohne (oder allenfalls minimal) das die sich auf die Laufzeit-Performance auswirken.

Und mir ist ein freies konkurrenzfähiges System wesentlich lieber als wenn es nur rein kommerzielle Systeme geben würde weil Systeme die nach dem Prinzip der reinen Lehre gebaut sind nicht konkurrenzfähig wären.

Es geht dabei weniger um reine Lehre oder so. Aber wenn es grundlegende Probleme gibt, dann sollte man die halt angehen und nicht die Augen davor verschließen. Genau eben aus dem Grund damit es auch weiter freie Alternativen gibt.

In der SGX-Enklave und den Mgmt-Funktionen von Intel-CPUs hat Minix jedenfalls ziemlich versagt.

Ich hier wieder bringst Du irgendwelche Sachen ein zu denen ich gar nix gesagt hab. Ich hätts ja noch verstanden wenn ich hier Minux "über den Klee" gelobt hätte. Aber irgendwelche Sachen vollkommen zusammenhangslos einzuwerfen ... da frag ich mich, was das soll.
Von den technischen Details Deines Beispiels fang ich da lieber gar nicht erst an.

Und die Lizenzen der BSDs haben dafür gesorgt das jeder seinen eigenen Kram gemacht hat und sich das komplett zerfasert hat

Du redest Blödsinn.
Die BSD-Lizenzen sind wesentlich kompatibler als die GPL (was zum Beispiel dafür gesorgt hat, das solche Schen wie ZFS und dtrace schon seit Jahren im FreeBSD-Kernel sind). Und Zerfaserung. Echt jetzt? Angesichts der 500 Mio Linux-Distributionen ist bei den BSDs Zerfaserung ein Problem? Du verarschst mich, oder?

Microkernels sind architektonisch vielleicht schöner aufgebaut als monolithische Kernels, aber das alleine macht noch keinen guten Kernel aus, weil Microkernels viel komplizierter sind durch die ganze Kommunikation der einzelnen kleinen Teile untereinander, und dadurch steigt die Anfälligkeit für Fehler (oder auch "nur" Performanceengpässe etc.) rapide an.

Jaein. Zumindest das Performanceproblem hat man inzwischen ganz gut im Griff.

Vom Erfolg her gesehen hat sich Linus Torvalds' Design als das in der Praxis bessere bewährt

Ob es besser ist lässt sich anhand der Praxis schwierig beantworten da es ja keine praxisrelevanten Mikrokernel gibt die nennenswert verbreitet wären.
Von daher ist das Fazit ... schwierig. :-)

Möglicherweise kommt da aber mal wieder etwas Bewegung rein. Das schon genannte Redox ist ein Microkernel. Und Googles Fuchsia hat mit dem Zirkon-Kernel auch eine Microkernel-Architektur.

Ansonsten hast Du sicher Recht. Microkernel haben auch durchaus Nachteile und sind jetzt nicht automatisch besser. Und Du hast auch damit Recht als Eleganz alleine keine hinreichende Eigenschaft ist die dazu führt das sich Mikrokernel durchsetzen. Es könnte aber irgendwann eine Frage der Notwendigkeiten werden, wenn man bestimmter Probleme (wie z.B. Komplexität) Herr werden möchte oder auch weil sich Gegebenheiten ändern. Und dann kann man immer noch darüber reden, was dann tatsächlich eine probate Lösung sein wird.

Was meines Erachtens nach ein Fehler ist, wäre einfach in einem "Weiter so" zu verharren.

 

[moonwalker99]

Bei dem was heutzutage als modern gilt, hätte ich eher Angst davor. Am Ende kriegen wir ein JS-Kernel, der über 10 verschachtelte Frameworks läuft, unzählige externe Ressourcen ungeprüft nachlädt und am Besten noch mit Blockchains und "AI" verzahnt ist, mit kostenpflichtigen DLCs (leichter Sarkasmus ist beabsichtigt )

Vielleicht wäre Rust eine geeignete Sprache, um den Kernel "modern" zu machen.

 

[KitKat::new()]

Vielleicht wäre Rust eine geeignete Sprache

Linus Torvalds says Rust is coming to the Linux kernel 'real soon now'​

https://www.theregister.com/2022/06/23/linus_torvalds_rust_linux_kernel/

 

[Web-Schecki]

Zum Beispiel das Linux immer noch ein sehr monolithisches System ist. Was die Implikation hat, das ein Problem an einer Stelle den ganzen Kernel mit in den Abgrund reißen kann.

Akademisch gesehen völlig korrekt - aber praktisch? Linux ist, so wie ich das beurteilen kann, in der Praxis ein ziemlich stabiler Kernel. Technisch hab ich leider viel zu wenig Ahnung von den Details, aber mein Eindruck ist, dass die schlicht eine recht vernünftige Herangehensweise an die Weiterentwicklung haben, um mit der Komplexität zurechtzukommen. Letztlich spricht der Erfolg einfach für sich. Die können enorm viel Ändern und Verbessern und sind dennoch stabil.

Und es wurde ja schon gesagt, der Bloat kommt vor allem von Treibern. Die breite Hardwareunterstützung ist aber DER Vorteil gegenüber anderen, akademisch vielleicht besseren Systemen wie Minix. Klar, WENN wir da mehr unification hätten, dann wäre das für alle Betriebssysteme besser, aber die Realität ist einfach eine andere. Und für den Fortschritt der Hardware ist es vielleicht sogar besser, wenn die nicht durch irgendwelche nur mühsam erweiterbare Standards eingeschränkt wird. Das bringt nämlich auch einen Haufen Bloat mit - man denke nur an x86, wo formal immer noch 16-Bit-Support (wenn auch emuliert, soviel ich weiß) mitgeschleppt wird.

Grundsätzlich verstehe ich deinen Punkt absolut, aber der Erfolg ist eben auch ein riesiges Argument dafür, dass die Herangehensweise der Linux-Community nicht ganz falsch ist. Ich befürchte auch, das Kernproblem (Komplexität durch Bloat) hat man einfach unabhängig vom Kernel-Konzept bei Betriebssystemen mit breiter Hardware-Unterstützung.

 

[PHuV]

Auch wenn ich C-Fan erster Stunde bin, fänge ich es gut, man ein OS mit einer aktuellen und modernen Sprache zu erstellen. Ich weiß ja nicht, woran es liegt oder scheitert, aber könnte man nicht schon parallel einen neuen Linux Microkernel unter RUST entwickeln und so bauen, daß er mit Hilfe von Wrappern und Emulatoren mit den anderen Dingen wie Libs, Treibern und Co. läuft? Apple bekommt ja sowas auch hin, siehe die Emulation von x86 nach ARM oder vorher PPC nach x86. Da sollte sowas mit Linux doch auch möglich sein?

 

[KitKat::new()]

aber könnte man nicht schon parallel einen neuen Microkernel unter RUST entwickeln und so bauen, daß er mit Hilfe von Wrappern und Emulatoren mit den anderen Dingen wie Libs, Treibern und Co. läuft?

RedoxOS?
https://www.redox-os.org/

 

[PHuV]

RedoxOS?

Ich meinte das eigentlich bezogen auf Linux. 🙂 Aber danke für den Link, ich schau mir das mal an.

 

[KitKat::new()]

Auf was denkst du habe ich das bezogen?

We want to be able to use it, without obstructions, as an alternative to Linux on our computers. It should be able to run most Linux programs with only minimal modifications.

We are not a Linux clone, or POSIX-compliant, nor are we crazy scientists, who wish to redesign everything. Generally, we stick to well-tested and proven correct designs. If it ain't broken don't fix it.

This means that a large number of standard programs and libraries will be compatible with Redox. Some things that do not align with our design decisions will have to be ported.

https://doc.redox-os.org/book/ch01-03-our-goals.html

 

[Crumar]

Auf den Linux-Kernel 5.19, der unter anderem Fixes gegen die CPU-Sicherheitslücken RETBleed, welche in noch stark verbreiteten Prozessoren von AMD und Intel die im Jahr 2017 entdeckten Schwachstellen Spectre und Spectre-V2 ausnutzen können, erhalten und aufgrund eines Fehltritts von Intel bei der GPU-Firmware insgesamt acht Release Candidates nötig hatte, folgt jetzt die offizielle Freigabe von Linux 6.0-RC1.

Also dieser Satz gehört meiner Meinung nach überarbeitet. Verschachtelter gehts nicht mehr.

 

[SVΞN]

Artikel-Update: Linux 6.0 unterstützt neue Hardware
Der kommende Betriebssystemkernel Linux 6.0 unterstützt wie gewohnt auch wieder die neueste Hardware. Auf Wunsch der Community hat die Redation deshalb eine entsprechende Übersicht der wichtigsten Neuerungen in diesem Bereich zusammengestellt.

Erweiterter Hardware-Support von Linux 6.0

• Initialer Support für AMD Raphael
• Initialer Support für Intel Raptor Lake
• Support für Qualcomm Snapdragon 8cx Gen3
• Erweiterte Support für Intel DG2 („Alchemist“)
• Verbessertes NUMA-Balancing für AMD Zen
• Neue Erweiterungen für RISC-V-CPUs
• PCI-Support für OpenRISC-CPUs

Zudem haben die Hersteller und Entwickler damit begonnen, am Support für Intel Meteor Lake und Ponte Vecchio sowie die RDNA-3-Architektur der Radeon-RX-7000-Serie zu arbeiten. Gestrichen wurde hingegen die Unterstützung für die NEC VR4100 MIPS-Prozessoren.

Viele der neuesten Patches für einen erweiterten Hardware-Support werden bereits mit dem Release von Linux 6.1 erwartet.

 

[andy_m4]

Akademisch gesehen völlig korrekt - aber praktisch? Linux ist, so wie ich das beurteilen kann, in der Praxis ein ziemlich stabiler Kernel.

Ist beim Linux-Kernel sicher so, das der nicht bekannt dafür ist unter argen Stabilitätsproblemen zu leiden. Abstürze sind ja nur ein Symptom in der die Problematik offenbar wird. Es geht dabei ja auch um mögliche Sicherheitslücken und so. Auch die Linux-Entwickler selbst sehen das als Problem. Nicht umsonst bauen die Sachen in den Kernel ein, um davor zu schützen. Man gucke nur auf diese ganzen Kernel-Protection Sachen. Das ist jetzt also kein unbekanntes Problem was völlig neu ist und niemand auf dem Radar hat. Darum weiß man natürlich. Und man weiß es nicht nur, sondern betrachtet die als so praxisrelevant, das man sogar Sicherheitslinien reinzieht.
Allerdings ist das mit nachträglich eingebauter Sicherheit natürlich immer so eine Sache.

Der Linux-Kernel ist trotz aller Stabilität weit entfernt von fehlerfrei. Dazu hast Du noch die ziemlich hohe Entwicklungsgeschwindigkeit wo halt neue Sachen in den Kernel reinkommen. Du hast also nicht nur das Problem bestehende Bugs alle wegzufixen, sondern es kommen stetig noch neue hinzu.

Technisch hab ich leider viel zu wenig Ahnung von den Details, aber mein Eindruck ist, dass die schlicht eine recht vernünftige Herangehensweise an die Weiterentwicklung haben, um mit der Komplexität zurechtzukommen.

Na ja. Aber ja. Beim Linux-Kernel ist man da sicher im Vergleich zu vielen anderen Projekten noch relativ gut aufgestellt.
Und man sieht es ja auch intern durchaus als Problem was diskutiert wird. Das ist also jetzt kein äußerer Eindruck der von außen da heran getragen wird.

Und es wurde ja schon gesagt, der Bloat kommt vor allem von Treibern.

Das macht es ja nicht besser. Und das wäre ja eher ein Grund für Mikrokernel, weil dann der eigentliche Kernel der Einflussphäre des Treibercodes entzogen wäre.

Eine weitere Entkoppelung wären dann schon die angesprochenen stabilen Kernel-APIs für Treiber. Das würde dann erlauben Treiber und Kernels getrennt zu releasen.
Haben wir ja in anderen Bereichen auch. Stell Dir mal vor, Dein Browser würde nur zusammen mit dem System geupdatet werden können und Du könntest nicht einfach nur den Browser ansich aktualisieren.
Woanders ist Modularität schon längst selbstverständlich aber beim Kernel halten wir am monolithischen Ansatz fest?

Und für den Fortschritt der Hardware ist es vielleicht sogar besser, wenn die nicht durch irgendwelche nur mühsam erweiterbare Standards eingeschränkt wird. Das bringt nämlich auch einen Haufen Bloat mit - man denke nur an x86, wo formal immer noch 16-Bit-Support (wenn auch emuliert, soviel ich weiß) mitgeschleppt wird.

Ja sicher. Ab und an sollte man mal alte Zöpfe abschneiden (deswegen ja auch die Idee eines "new linux" anstatt "wir machen so weiter"). Die größten Probleme sind häufig in irgendwelchem legacy-Kram zu finden.
Und ja. Man kann nicht immer alles gut planen und "Standards" schaffen die über längere Zeit gut funktionieren.

Es gibt ja so zwei grundlegende Ansätze.

1. Man hat ein Problem und entwirft dann dazu erst mal ne Quick&Dirty-Lösung. Da hat man schnell etwas, was man auch direkt ausprobieren kann und dann auch sieht, wie gut es in der Praxis funktioniert und ob es überhaupt der richtige Weg ist oder man schon gleich zu beginn sieht, das der Ansatz zum scheitern verurteilt ist und man ihn dann verwirft.
2. Oder man durchdenkt von vorn herein schon die Sachen etwas weiter. Bis man überhaupt ne Lösung hat dauert es länger, aber sie funktioniert dann in der Regel auch, man muss weniger nachbessern und sie überlebt auch länger.

Ich sag mal, im Linux-Umfeld ist man von der Mentalität her eher bei ersterem. :-)
Das führt dazu, das Linux ziemlich volatil ist. Ich meine wie viele Device-Systeme hatten wir durch bis wir jetzt bei udev waren.

Früher hatte man ja auch mal eine Unterteilung in Entwickler-Kernel und stabilen Kernel. Der stabile Kernel war quasi production-ready und der Entwicklerkernel war so ein bisschen Spielwiese um Sachen auszuprobieren. Das fand ich immer gar nicht so verkehrt.

Ich befürchte auch, das Kernproblem (Komplexität durch Bloat) hat man einfach unabhängig vom Kernel-Konzept bei Betriebssystemen mit breiter Hardware-Unterstützung.

Das Problem hast Du ja auch, wenn Du mal den Treiberteil weglässt. Ich hatte ja exemplarisch die Security-Frameworks genannt.

Auch wenn ich C-Fan erster Stunde bin

Ich dachte, das waren Kernighan & Ritchie :-)

daß er mit Hilfe von Wrappern und Emulatoren mit den anderen Dingen wie Libs, Treibern und Co. läuft?

Prinzipiell würde das natürlich gehen. Allerdings ist das durchaus auch aufwendig. Wie das bei Apple läuft weiß ich nicht, aber ich kenne den Code so ein bisschen aus FreeBSD. Dort macht man das ja auch, um z.B. Linux-Grafiktreiber auf FreeBSD zum laufen zu kriegen und das ist relativ aufwändig und schlägt auch durch aufs eigentliche System.
Und das ist halt suboptimal wenn das Ziel ist ein sauberes und schlankes System zu kreieren.
Klar kann man sagen, das man halt ne Transition-Phase hat wo man das halt in Kauf nimmt und dann zurück baut, wenn man alles auf native Treiber umgestellt hat.

In der Praxis ist sowas häufig schwierig. Weil Du dann ja zwei Treiber entwickeln und pflegen musst. Um de. Aufwand aus dem Wege zu gehen, schreibst Du nur einen Treiber. Und Du wirst nicht das Treibermodell vom neuen System wählen, sondern vom Alten weil der funktioniert sowohl beim neuen als auch beim alten System (größere Abdeckung).
Das ist so ein bisschen wie mit Wayland und X11 und wir werden auch noch in 20 Jahren XWayland mitschleppen, weil es irgendwo noch Programme gibt die nur mit X11 funktionieren. :-)

Apple hat das Problem deshalb nicht in dem Ausmaß, weil sie die Hoheit über das Ökosystem haben und daher das einfach vorgeben können.

 

[0x8100]

Früher hatte man ja auch mal eine Unterteilung in Entwickler-Kernel und stabilen Kernel. Der stabile Kernel war quasi production-ready und der Entwicklerkernel war so ein bisschen Spielwiese um Sachen auszuprobieren. Das fand ich immer gar nicht so verkehrt.

dafür hat man ewig gewartet, bis denn mal neue hardware im stable unterstützt wurde. die spielwiese ist heute der "staging" bereich, somit kann man neue sachen ausprobieren ohne auf den stabilen teil verzichten zu müssen.

Eine weitere Entkoppelung wären dann schon die angesprochenen stabilen Kernel-APIs für Treiber. Das würde dann erlauben Treiber und Kernels getrennt zu releasen.

ist nun mal eine getroffene entscheidung, um sich nicht künstlich limitieren zu lassen. die apis zum userspace sind stabil, im kernel kann es sich jederzeit ändern.

 

[andy_m4]

dafür hat man ewig gewartet, bis denn mal neue hardware im stable unterstützt wurde.

Was aber auch nur ein Problem ist weil Treiber mit dem Kernel so eng verbandeln sind.

die spielwiese ist heute der "staging" bereich, somit kann man neue sachen ausprobieren ohne auf den stabilen teil verzichten zu müssen.

Das ist natürlich richtig. Und selbst ohne dem kann man sich ja einfach eine Kopie ziehen und dann darauf basierend einfach mal losstarten.

ist nun mal eine getroffene entscheidung, um sich nicht künstlich limitieren zu lassen.

Ich verstehe die Entscheidung. Und es gibt ja Gründe dafür. Was aber dennoch nicht bedeuten muss, das man nicht mal darüber spricht oder das auf alle Zeit so sein muss.

die apis zum userspace sind stabil,

Meistens schon.

 

[0x8100]

Meistens schon.

nicht meistens, sie sind es aufgrund einer design-entscheidung:

The kernel to userspace interface is the one that application programs use, the syscall interface. That interface is very stable over time, and will not break. I have old programs that were built on a pre 0.9something kernel that still work just fine on the latest 2.6 kernel release. That interface is the one that users and application programmers can count on being stable.

https://github.com/torvalds/linux/blob/master/Documentation/process/stable-api-nonsense.rst

 

[andy_m4]

nicht meistens, sie sind es aufgrund einer design-entscheidung

Ist mir bewusst. Dennoch trifft es nicht in allen Fällen zu.
Sonst bräuchte man auch das (auch noch fett geschriebene) Zusatzwort "very" nicht (was sich zwar positiv liest, aber eigentlich letztlich sogar ne abschwächende Aussage macht).
Denn entweder ist etwas stabil oder nicht. 1 oder 0. Schwanger oder nicht schwanger. Es gibt da kein ein bisschen schwanger.
Da gibts halt keine Steigerungsform und dementsprechend macht es auch kein Sinn von "sehr stabil" zu sprechen. Das macht nur Sinn, wenn es eben keine 100% Aussage ist.

Und wenn das schon der führende Kernelentwickler einräumt, dann ist da ja vermutlich was dran. Insofern ist das kein Widerspruch zu meiner Aussage, sondern eher ein Beleg dafür.

Und das da Beispiele genannt werden, wo alte Programme nach wie vor laufen ist natürlich auch kein Gegenbeweis. Das trifft dann halt nur eine Aussage für genau diese Programme. Was anderes wäre es jetzt, wenn die alle APIs benutzen würden, was aber vermutlich eher nicht der Fall ist.

 

[0x8100]

man kann auch echt alles kleinreden. dass eine api stabil ist, ist nun mal kein naturgesetz und ausnahmen gibt es immer. die sind aber seit ewigkeiten nicht vorgekommen und in die zukunft kann keiner sehen. dass man das aber durchzieht sieht man daran, dass erst letztens intel angezählt wurde, weil sie den userspace inkompatibel machen wollten und das zum release ändern mussten.

auch bei deinem favorisierten microkernel würde es keine garantien geben, dass apis stabil sind.

 

[andy_m4]

man kann auch echt alles kleinreden

Evtl. meinst Du eher kleinlich sein. Das würde zumindest besser passen. :-)

dass eine api stabil ist, ist nun mal kein naturgesetz und ausnahmen gibt es immer.

Ich hab auch nix Anderes behauptet.
Und ich finde das auch gar nicht weiter dramatisch, das es mal zu API-Anpassungen kommt.

die sind aber seit ewigkeiten nicht vorgekommen

Das weiß ich jetzt gar nicht auf Schlag, würde dem aber erst mal zustimmen.
Gerade heutzutage, wo soviel von Linux abhängt würde das ja auch ein riesigen Rattenschwanz nachsich ziehen. Damit würden sich die Linux-Entwickler ziemlich unbeliebt machen. :-)

auch bei deinem favorisierten microkernel würde es keine garantien geben, dass apis stabil sind.

Ich hab nix Anderes behauptet.
Das eine hat auch erst mal wenig mit dem Anderen zu tun. Ist einfach nur ne Frage, die man diskutieren sollte wann und wo das Sinn macht.
Allerdings ist man bei Modularität natürlich eher angehalten Schnittstellen stabil zu halten, weil man sonst ein Teil der Vorteile von Modularität nicht nutzt. Und im Falle des Mikrokernels ging es ja auch um interne APIs. Also genau die, die jetzt ja bei Linux alles andere als stabil sind.
Ob die nun perfekt stabil sind ist die Frage. Vermutlich würde sich aber die Situation zum Jetzt-Zustand in Richtung API-Stabilität verschieben.

Abgesehen davon ist ja immer die Frage, wie lange man die Stabilität überhaupt haben will. Der Punkt der Flexibilität ist ja durchaus valide. Ein Kompromiss könnte ja sein, das man z.B. innerhalb einer Major-Version stabil bleibt, so wie es ja bei einigen anderen Systemen auch üblich ist.
Gut. Dann müsste man sich wieder auf ein vernünftiges Versionsschema einigen und solche Sperenzien a-la "Zahlen größer als 20 sind mir zu hoch" weglassen. Aber das sind ja alles Dinge, die sich regeln lassen. :-)

 

[foofoobar]

Eine weitere Entkoppelung wären dann schon die angesprochenen stabilen Kernel-APIs für Treiber. Das würde dann erlauben Treiber und Kernels getrennt zu releasen.

Die Einführung von multiqueuing und den Umbau des IO-Systems für nvme wäre mit einer "stabilen" Kernel-API sicherlich schwieriger gewesen. Außerdem verhindert eine "instabile" Kernel-API ziemlich gut das der Kernel noch uralte Blobs unterstützen muss. Und mit guten Argumenten geht im Linux-Kernel einiges, siehe das upstreaming von Wireshark, hat zwar etwas gedauert ging dann aber ziemlich flott.

Ja sicher. Ab und an sollte man mal alte Zöpfe abschneiden (deswegen ja auch die Idee eines "new linux" anstatt "wir machen so weiter").

Jeder kann den Linux-Kernel forken oder was komplett neues bauen.

Es gibt ja so zwei grundlegende Ansätze.

1. Man hat ein Problem und entwirft dann dazu erst mal ne Quick&Dirty-Lösung. Da hat man schnell etwas, was man auch direkt ausprobieren kann und dann auch sieht, wie gut es in der Praxis funktioniert und ob es überhaupt der richtige Weg ist oder man schon gleich zu beginn sieht, das der Ansatz zum scheitern verurteilt ist und man ihn dann verwirft.
2. Oder man durchdenkt von vorn herein schon die Sachen etwas weiter. Bis man überhaupt ne Lösung hat dauert es länger, aber sie funktioniert dann in der Regel auch, man muss weniger nachbessern und sie überlebt auch länger.

Ich sag mal, im Linux-Umfeld ist man von der Mentalität her eher bei ersterem. :-)
Das führt dazu, das Linux ziemlich volatil ist. Ich meine wie viele Device-Systeme hatten wir durch bis wir jetzt bei udev waren.

https://de.wikipedia.org/wiki/Die_Kathedrale_und_der_Basar

Prinzipiell würde das natürlich gehen. Allerdings ist das durchaus auch aufwendig. Wie das bei Apple läuft weiß ich nicht, aber ich kenne den Code so ein bisschen aus FreeBSD. Dort macht man das ja auch, um z.B. Linux-Grafiktreiber auf FreeBSD zum laufen zu kriegen und das ist relativ aufwändig und schlägt auch durch aufs eigentliche System.

Es gab auch schon den umgekehrten Fall.

Das ist so ein bisschen wie mit Wayland und X11 und wir werden auch noch in 20 Jahren XWayland mitschleppen, weil es irgendwo noch Programme gibt die nur mit X11 funktionieren. :-)

Im wesentlichen ist das ein X-Server der einen Wayland-Treiber hat, derartige X-Server gibt es unter Windows massenhaft.
Who cares?

Ergänzung (16. August 2022)

Meistens schon.

Manchmal verlässt sich Code auf nicht garantierte Eigenschaften, dann wird es blöd.