Debian ist frei und seine Entwickler sind Kosmopoliten. Das Linux-Magazin berichtet regelmäßig Interna aus der Debian-Entwicklerszene und angrenzenden Projekten.

Obwohl öffentlich fast nie in Erscheinung getreten, ginge ohne diese Entwickler bei Debian nichts: das Kernel-Team [1]. Es beteiligt sich wesentlich an der Entscheidung darüber, was das nächste Debian kann und was nicht. Für Funktionen wie Virtualisierung oder Support für Spezialhardware braucht es nun mal Kernel-Unterstützung.

Aktueller dank Verzögerung

Der Rest des Projekts arbeitet zeitversetzt zum Kernel-Team. Passende Treiber etwa müssen erst im Kernel vorhanden sein, bevor andere die Infrastruktur erstellen können. Die Zeit kurz vor einer Release ist für die Kernelentwickler deshalb meist eine ruhigere als für den Rest des Projekts. Anders bei Lenny. Jetzt, da die Spanne zwischen geplanter und tatsächlicher Release immer größer wird, nutzt das Team die Zeit und baut nützliche Zusatzfunktionen ein.

In Lenny gibt es mittlerweile Pakete für Kernel 2.6.26, die sogar jene für den eingeplanten 2.6.24er ersetzen. Passend dazu landete der neuere Kernel auch im Installer. Da auf Kernel.org schon Version 2.6.28 verfügbar ist und 2.6.29 sich im Feature-Freeze befindet, startet Lenny zumindest mit einem einigermaßen aktuellen Kernel.

Abbildung 1: Schaltzentrale: Das Kernel-Team entscheidet maßgeblich darüber, was geht. (Bild: © Taffi, Fotolia.com)

Flickwerk

Außerdem war Zeit für Patches. Wie bei fast allen Distributionen entspricht der Debian-Kernel in vielen Teilen nicht mehr dem Vanilla-Kern von Kernel.org. Die Mitglieder des Teams haben viele kleine Patches in die Quellen des Debian-Kernels integriert: Neben den üblichen für neue Sub-Versionen, die von offizieller Seite stammen, enthalten die Debian-Pakete vor allem architekturspezifische Patches. Profiteure sind Architekturen wie S390 oder PowerPC, für die es von anderen Distributoren keine offizielle Unterstützung mehr gibt. Spezielle “Flavours” des Debian-Kernels kommen mit Support für die Virtualisierungs-Frameworks Vserver oder OpenVZ daher.

2.6.26 als Xen-Dom 0

Für Endbenutzer attraktiv könnte der Kernel 2.6.26-xen sein, der in Lenny Xen als Dom U wie auch als Dom 0 unterstützt und damit eine Lösung für ein distributionsabhängiges Dilemma bietet: Wer Xen in Linux als Dom 0 betreiben möchte, muss auf 2.6.18 zurückgreifen – oder auf ein inoffizielles Patch für den eigenen Kernel. Bis auf Open Suse haben die Distributoren den Dom-0-Support daher “auf Weiteres” aus dem Kernel getilgt.

Für Debian hat aber Bastian Blank einen Xen-gepatchten Kernel 2.6.26 hochgeladen, nachdem er das auf der LKML kursierende Suse-Xen-Patch offenbar für stabil genug hielt. In seinem Blog [2] merkt er einschränkend an, dass das Xen-Patch für 2.6.26 “wählerisch” im Hinblick auf die Hardware sei. Nur die Kombination aus 2.6.18 und Xen 3.3 bezeichnet er als “rock stable”. Für den produktiven Einsatz eignet sich die Kombination 2.6.26 und Xen also nicht, leidgeprüfte Admins müssen sich weiterhin gedulden, bis der Code den Weg in den offiziellen Linux-Kernel findet.

Kernel und Installer

Überaus gut funktioniert dagegen die Kooperation zwischen Kernel- und Installer-Team. Jenes setzt die Funktionen, die das Kernel-Team zur Verfügung stellt, ideal um. Lenny bietet so die Möglichkeit, aus dem Installer heraus ein vollverschlüsseltes System zu installieren. Auch profitiert der Installer von vielen kleinen Patches, die das Kernel-Team auf der LKML aufsammelt und in die Pakete integriert. Laptop-Benutzer freuen sich deshalb über eine verbesserte ACPI-Unterstützung.

Schließlich hat das Kernel-Team auch viel mit Security zu tun: Sicherheitslecks werden jeweils nur im aktuellen stabilen Linux-Kernel repariert, ältere Versionen erhalten keine Patches. Die Entwickler müssen also wichtige Patches zurückportieren und integrieren. In der Vergangenheit hat sich das als größte Belastung herausgestellt. (uba)