Der Linux-Kernel ist aufgebläht Linus Torvalds hält den Linux-Kernel für aufgebläht und riesig („bloated and huge“).
Zu dieser Aussage kam der Schöpfer des freien Betriebssystems bei einem Round-Table-Gespräch auf der LinuxCon, die gerade im US-amerikanische Portland stattfindet.Das Statement von Torvalds kam als Reaktion auf Fragen, ob die Linux-Entwickler nicht zu schnell zu viele neue Features in den Kernel aufnehmen.
Der Moderator des Gesprächs, Kernel-Entwickler James Bottomley wies auf eine interne Studie von Intel hin, aus der hervorgehe, dass der Kernel bei jedem neuen Release um zwei Prozentpunkte an Leistung einbüße. Für die letzten zehn Releases beziffert sich der Performance-Verlust so auf zwölf Prozent.
Torvalds bedauert, dass der Linux-Kernel nicht unbedingt das schlanke, kleine und super-effiziente Stück Software ist, das ihm vor fünfzehn Jahren vorschwebte. An einen konkreten Plan, wie man den Leistungsabbau stoppen könne, fehle es jedoch.Einen Teil des Problems sieht Torvalds in dem Erfolg von Linux. Das System läuft inzwischen auf so vielen unterschiedlichen Plattformen und unterstützt so viele Geräte, dass der Linux-Urheber die Überladenheit des Kernels zwar für unakzeptabel hält, sie zugleich aber kaum vermeidbar nennt.Immerhin zeigte sich Torvalds zufrieden mit der Stabilität des Kernels: „Wir finden Bugs genauso schnell, wie wir sie hinzufügen – auch wenn wir mehr Code aufnehmen“.
So ist das, wenn man sich den Vanilla-Kernel , oder auch Distributionskernel zur Brust nimmt. Aber wenn man sich mal nicht an die Beginner in Sachen Linux richtet, wird man sehr schnell merken, dass man auch seinen eigenen Kernel bauen kann und nicht z.B. einen Adaptec AHA für seinen Kernel auf dem Laptop mitschleppen muss. Den Kernel anpassen an die Hardware, darin liegt die Methode. Deswegen verstehe ich die Aussage nicht ganz, aber ich beobachte dies schon seit dem Beginn der 2.6er-Kernelära, dass da langsam etwas zu einer Bloatware wird. Ich verstehe auch nicht ganz, warum die meisten Entwickler nun bei dem Code panschen aufgrund neuer Hardware, welche nicht einmal in der Geschwindigkeit vorhanden war, als ich in meinem ersten RZ anfing zu arbeiten. Somit schludern eigentlich alle Seite, sei es die GUI-Fetischisten oder die Kernelmaintainer. Warten wir mal ab, was weiter daraus wird, bis dahin, viel Spaß bei der Kompilierung des eigenen Kernels.
Naja den Kernel an die Hardware anpassen löst ja nur einen Teil des Problems.
Ob Du den Code einbaust, oder nicht, maintained werden muß Er auf jeden Fall.
Der Rest ist jetzt geraten, weil ich kein Kernelprogrammierer bin:
Aber Ãœberhaupt die Möglichkeit zu haben, all die verschiedene Hardware und Architekturen zu unterstützen, macht wahrscheinlich einen komplexeren Grundaufbau des gesamten Kernels notwendig, Der auch zu Buche schlägt wenn die Treiber dann gar nicht eingebaut werden!?
Nun ich gehe in dem Moment nicht von dem „Mainaining“ aus, sondern eher von den Distributionskernel. Und da ist nun erst einmal Alles vorhanden was nicht wirklich sein muss, bzw viele nette Module.So etwas ist langsamer, wie auch der Vanillakernel. Was ich eher bemerkte war genau jenes was zu dieser Aussage passt, es läuft auf zu vielen Architekturen und alle wollen bedient werden. Das fiel mit schon seit längerem auf und war immer wieder Grundlage der Stammtischdiskussion. Ich sehe eher ein Fortschritt darin versch. Hardwarereihen zu fahren für den Kernel. Somit könnte man sich die Arbeit ein wenig leichter machen, imo.
Zwar Modular aufgebaut, welches auch eine feine Sache ist, nur wie es genau in dem Moment mit der HAL und dem Kernel ist, dazu code ich auch zu wenig Kernel. Aber es ist schon ein komisches Gefühl, wenn eine RS6000 mit 375Mhz einen 4fach Xeon abhängt, trotz gleicher Distribution, aber unterschiedlichem Kernel. Einmal 2.6 und einmal 2.4. Da stimmt in dem Moment etwas nicht, denn die IO-Leistung sollte auch bei dem Xeon schneller sein, vor allem weil es das neuer SCSI ist.
Ichd enke da fliesst noch einiges den Bach runter bis das Thema ganz geklärt ist.
Grüsse Dich
Du verwechselst die Groesse des durch spezielle Konfiguration erzeugten binaeren Kernels mit der Architektur des Kernels, die durch z.B. eine zunehmende Anzahl an Subsystemen eine signifikante Verlaengerung des Codepfades bei Funktionsaufrufen erhaelt und dadurch aufgeblaeht wird.