Mit Android engagiert sich Google seit einiger Zeit auf dem Markt der mobilen Betriebssysteme, mit ChromeOS will man schon bald auch den Netbook/Desktop-Markt erobern. Was beide Produkte verbindet ist eine zentrale Softwareentscheidung: Im Hintergrund werkelt jeweils ein Linux-Kern, das Open-Source-Betriebssystem hat also in der künftigen Entwicklung beim Softwarekonzern längst eine zentrale Rolle eingenommen.

Internas

Doch das Engagement von Google im Linux-Bereich beschränkt sich bei weitem nicht nur auf Consumer-Produkte, schließlich setzt das Unternehmen auch intern schon längst auf das freie Betriebssystem. Nicht nur die Server, auch ein Großteil der Desktop-Systeme bei Google laufen mit Linux, für Letztere nutzt man übrigens eine eigene, firmeninterne Variante von Ubuntu.

Einblick

Da kann es nicht verwundern, dass der Softwarehersteller längst ein eigenes Entwicklungs-Team etabliert hat, dass sich ausschließlich um spezifische Verbesserungen am Linux-Kernel kümmert. Im Rahmen des unlängst in Tokio abgehaltenen Kernel Summits 2009 hat man nun erstmals einen näheren Einblick in dessen Aktivitäten gewährt, wie LWN.net berichtet.

Kritisch

Dabei gibt sich Google-Entwickler Mike Waychison durchaus selbstkritisch, vieles am eigenen Entwicklungsprozess sei noch verbesserungswürdig. So  bewege sich der interne Kernel erheblich hinter den offiziellen Releases von kernel.org, entsprechend mache die Portierung von neuen Features auf die ältere Code-Basis auch bereits ein Viertel der gesamten Arbeiten aus.

Basis

Aktuell bereite man gerade erst den Umstieg auf Kernel 2.6.26 vor, aktuell ist hingegen die Version 2.6.31. Der Google-Kernel unterscheide sich von der offiziellen Release dabei um nicht weniger als 1.208 Patches, die mehr als 300.000 Zeilen Code betreffen.

Code

Ein Umstand, mit dem man auch bei Google selbst nicht zufrieden ist, als entscheidenden Schritt zur Verbesserung hofft man auf den internen Wechsel auf das - auch beim offiziellen Kernel eingesetzte - Code-Verwaltungssystem GIT. Bisher kommt hier das recht monolithische Perforce zum Einsatz. Dieser Wechsel soll auch ermöglichen, dass der interne Code künftig vierteljährlich auf die neueste Kernel-Basis portiert wird - und in Folge die Zusammenarbeit mit dem Upstream-Kernel-Projekt erleichtern.

Problembereiche

Allerdings gebe es auch einige Problembereiche, die das Rückfließen des eigenen Kernel-Codes erschweren würden, wie man vor der versammelten Linux-Prominenz beklagte: So mache es das äußerst flotte Tempo der Kernel-Entwicklung äußerst schwer mit den eigenen Patches Schritt zu halten. Zusätzlich ist man aber auch nicht mit allen technischen Entscheidungen der letzten Zeit zufrieden. Der Wechsel auf den aktuellen "Completely Fair Scheduler" habe etwa einige Probleme verursacht, im Endeffekt waren diese so massiv, dass man den alten O(1)-Scheduler auf den neuen Kernel-Code aktualisiert hat. (apo, derStandard.at, 09.11.09)