Frage: Wäre es überhaupt möglich Linux so komplett umzuschreiben? Würde das das Projekt nicht Quasi auf den Stand zu Zeiten von 0.01 zurückwerfen?
Am Linux-Kernel entwickeln tausende Entwickler mit. Im Release des 2.6.24er Kernels gab es knapp 10.000! Änderungen zur Vorversion. Zwischen des Releases von 2.6.0 und 2.6.29 sind 5,8 Millionen Zeilen Code hinzugekommen. Der Code hat sich somit mehr als verdoppelt und wie wir wissen, ist eine Menge Kram hinzugekommen, den kaum jemand braucht. Ein Rewrite der Basis hätte nur einen Bruchteil dieses Aufwands ausgemacht, da man bestehende Algorithmen zum Großteil übernehmen könnte. Der Grund, warum es nicht getan wird, ist vielmehr, dass (zu Recht) befürchtet wird, dass viele Treiber nicht in den neuen Kernel einfliessen würden, da die Entwickler dieser Treiber nicht mehr aktiv sind. Das absurde daran ist, dass genau dadurch die hohe Sicherheitsproblematik im Kernel-Code liegt. Es gibt tausende von Codezeilen, die sich seit Jahren niemand mehr angeschaut hat, die aber ggf. in Verbindung mit anderen Bestandteilen des Kernels zu Sicherheitsproblemen führen können. wunderbar_emporium war ein gutes Beispiel dafür. Anstatt sich also zu fragen "Wollen wir weiterhin einen Kernel entwickeln, von dem wir wissen, dass er Sicherheitslücken enthalten kann, die da vielleicht schon seit Jahren drin sind und die einfach noch niemand in der Masse von Code gefunden hat?" stellt man sich lieber die Frage "Wollen wir auf alte ISA-Treiber u.ä. verzichten?" und beantwortet diese dummerweise auch noch mit "Nein".
Allerdings traue ich es bei der derzeitigen Organisation und "Einigkeit" der Kernel-Entwickler dem Linux-Projekt auch nicht mehr zu, solche Schritte organisatorisch zu bewältigen. Man erinnere sich nur mal dran wie lange einige Treiber-Entwickler gebraucht haben, bis sie ihre Treiber vom 2.4er auf dem 2.6er Kernel angepasst hatten, so daß man ewig obsolete Modul-Interfaces mitschleppen musste. Bei einer Restrukturierung des Kernel wäre es vermutlich kaum möglich solche Interfaces weiterhin anzubieten und eine entsprechend kurze Reaktionszeit der Treiber-Entwickler wäre gefragt. Klar, diese entwickeln nur in der Freizeit, aber als Entwickler an einem so großen und wichtigen Projekt sollte man einigermaßen angemessene Reaktionszeiten ermöglichen, falls z.B. mal Sicherheitslücken zu schliessen sind u.ä.. Mir ist klar, dass ein Rewrite eines Treibers keine einfache Sache ist, aber es gibt kaum Systeme, wo man da drumrum kommt. Linux versucht es aber krampfhaft.
Es ist aber primär eine Sache der Organisation. Erwartet ja niemand, dass es heute sofort fertig sein muss, aber es mal für die Zukunft einzuplanen und langsam damit loszulegen, wäre nicht verkehrt. Aktuell könnte man ihn auch bekommen, allerdings müssten die Entwickler dazu bereit sein zeitweise 2 Versionen ihrer Module anzubieten, für den alten/aktuellen Kernel und für den dann neuen Entwicklungskernel. Sicherlich ist der Aufwand hoch, aber ohne diesen sehe ich auf lange Sicht keine Zukunft für Linux. Habt ihr euch mal angeschaut wie riesig der Kernel mittlerweile geworden ist? Die Hardware wird im Laufe der nächsten Jahre nicht weniger und es wird immer wieder neue Hardware-Schnittstellen geben, deren Unterstützung dann wieder in diese monolithische Struktur gefrickelt werden muss. Der Kernel unterliegt damit einem permanenten Wachstum im RAM-Verbrauch, der sich drastisch vermindern liesse, wenn alle Subsysteme über fest definierte Schnittstellen mit dem Kernel kommunizieren würden und dieser sich auf seine eigentlichen Aufgaben konzentrieren würde... Schnittstelle zur Hardware sein und nicht eine Sammlung von Subsystemen um Schnittstellen zu Treibern zu bilden.
@jemo.: Der Noob sieht es daran, dass er dann z.B. Linux-NG nutzt. Ist ja eine Abkürzung, die sich mittlerweile in vielen Bereichen eingebürgert hat, wo man die Notwendigkeit von Rewrites eingesehen hat.