Seite 7: Linux-Kernel herunterladen, allgemeine Informationen zur Linux-Entwicklung

Inhaltsverzeichnis

Anhang

Im folgenden einige im Artikel bereits verlinkte Hintergrund-Informationen zum Linux-Kernel und dessen Entwicklung:

Linux-Kernel herunterladen

Linux-Kernel stehen über die Server der Domain Kernel.org zum Download bereit; die Version 2.6.24 etwa als Bzip2 komprimierter Patch gegen 2.6.23 oder als komplettes Archiv über die die in Europa aufgestellten Server des Kernel.org-Verbunds. Schon bald nach der Veröffentlichung neuen Linux-Versionen sind sie auch über die deutschen Spiegelserver als Patch oder das komplette Archiv erhältlich. Die Server werden dynamisch zugewiesen; es kommt daher gerade kurz nach der Freigabe neuer Dateien gelegentlich vor, dass man auf einem Spiegelserver landet, der die neuen Dateien noch nicht vorhält.

Wenn es keinen triftigen Grund für den Umstieg auf eine neue Kernel-Version gibt, sollte man die Kernel-Pflege dem Linux-Distributor überlassen, denn einen Kernel selbst zu konfigurieren, kompilieren und installieren, erfordert fortgeschrittene Linux-Kenntnisse und ist zeit- und arbeitsintensiv – letzteres insbesondere auch durch die später benötigte Pflege, denn die Kernel-Entwickler geben pro Monat meist mehrere überarbeitete Versionen heraus. Einige von ihnen stopfen Sicherheitslücken, sodass man die ganze Installationsprozedur erneut durchlaufen muss.

Zudem enthalten die Kernel der Distributionen gelegentlich Patches oder zusätzliche Treiber, die dem offizielle Kernel fehlen. Wer für seine Hardware solche Treiber benötigt, muss diese im Internet suchen, herunterladen, kompilieren und installieren, was die Installation eines eigenen Kernels weiter verkompliziert und verlängert. Auch die zusätzlichen Patches im Distributions-Kernel sind teilweise von Wichtigkeit. So manche die Distribution läuft daher mit einem selbst kompilierten Kernel nicht so rund wie gewohnt oder es fehlen gewisse Funktionen.

Die Entwicklerzweige der jeweils nächsten Distributionsversionen von Fedora, OpenSuse oder Ubuntu enthalten häufig aktuelle Kernel-Versionen und sind daher häufig die beste Basis, wenn man einen neuen Kernel braucht. Will man nicht gleich auf eine solche Entwicklerversion wechseln, um die Vorteile eines neuen Linux-Kernels zu genießen, können fortgeschrittenen Linux-Anwender diese häufig mit vertretbarem Aufwand auch in den aktuellen Versionen der jeweiligen Distribution einbinden. Bei Fedora kann man aber auch schlicht ein bisschen warten, denn das Projekt liefert traditionell neue Kernel-Version einige Tage oder Wochen nach deren Erscheinen als reguläres Update für die die aktuellen Versionen der Distribution aus.

Versionswirrwarr

Die Kernel-Hacker entwickeln den Linux-Kernel im Rahmen der 2.6-Serie stetig weiter. Dabei scheuen sie auch nicht vor umfangreichen Änderungen zurück – einen 2.7-Entwicklerzweig, aus dem irgendwann ein Linux 2.8.0 oder 3.0.0 hervorgeht, wie Linux 2.6.0 aus dem 2.5-Entwicklerzweig entstand, wird es daher auf absehbare Zeit nicht geben.

Die Hauptentwicklungslinie stellen die Versionen mit drei durch Punkte getrennten Nummern (2.6.x, also etwa 2.6.24) dar, über die Linus Torvalds selbst wacht. Bei vielen Entscheidungen greift er aber auf die Hilfe zahlreicher anderer Kernel-Hacker zurück. Parallel zur Hauptentwicklung pflegen die Verwalter der Stable-Kernel-Serie die beiden jeweils neusten Versionen der 2.6-Serie weiter und kennzeichnen die Überarbeitungen durch eine zusätzliche Zahl (2.6.x.y, beispielsweise 2.6.22.10 oder 2.6.23.8). Um nicht mit der Hauptentwicklungslinie zu konkurrieren und möglichst nur Fehler zu korrigieren, statt neue auszulösen, haben sich die Stable-Kernel-Betreuer selbst strenge Regeln auferlegt; so dürften die Patches nicht länger als hundert Zeilen sein, müssen einen kritischen Fehler korrigieren und sollten auch in den von Torvalds gewarteten Kernel bereits aufgenommen worden sein.

Die aktuellen Linux-Versionen werden zirka fünf Monate (zwei Entwicklungszyklen) gewartet, bevor man auf einen neue 2.6.x-Version umsteigen solle, weil die Stable-Kernel-Verwalter dann selbst bei Sicherheitslücken keine neue Varianten der alten Linux-Kernel herausgeben. So ein Umstieg ist allerdings nicht ohne Risiko, da sich mit jedem Entwicklungszyklus der ein oder andere neue Fehler einschleicht. Viele Linux-Distributoren pflegen ihre Kernel daher länger, statt neue Versionen auszuliefern – bei den Enterprise-, Server- und Workstation-Distributionen von Debian, Novell und Red Hat erhält man sogar über mehrere Jahre lang Sicherheitsupdates für die enthaltenen Kernel. Die enthalten allenfalls einige neue und überarbeitete Treiber sowie einige wenige, ausgewählte Neuerungen aus jüngeren Linux-Versionen; die Distributoren erhoffen sich davon ein besseres Zusammenspiel mit (neuer) Hardware, ohne dass die Anwender sich mit Fehlern herumschlagen müssen, die neue Kernel-Versionen vielleicht einschleppen.

Adrian Bunk pflegt in Eigeninitiative noch die Kernel der 2.6.16-Reihe nach den Stable-Kernel-Rules weiter – er spart dabei neue Treiber aber weitgehend aus, sodass den 2.6.16.y-Kerneln auf neuen Desktop-PCs häufig Treiber fehlen. Noch weniger Treiber für moderne Hardware enthalten die ebenfalls noch gepflegten Kerneln der 2.4-Reihe; für Server mit bereits installiertem Linux sind diese Kernel-Serien allerdings für von Interesse, da die Gefahr neuer Fehler bei so konservativ gewarteten Kernel-Serien recht gering ist.

Entwicklungszyklus

Direkt nach der Freigabe einer neuen Kernel-Version beginnt die zirka zwei Wochen lange erste Phase des Entwicklungszyklus, in der die Kernel-Hacker umfangreichere Änderungen in den von Torvalds verwalteten Entwicklerzweig aufnehmen, aus dem die nächste Kernel-Version hervorgeht. In der darauf folgenden, meist zirka sieben bis zehn Wochen langen zweiten Entwicklerphase integriert der Linux-Vater dann im wesentlichen nur noch Fehlerkorrekturen oder kleinere Änderungen, bevor er nach zirka zweieinhalb bis drei Monaten wieder eine neue Kernel-Version veröffentlicht. Das soll die Kernel-Hacker dazu bringen, sich in der zweiten Entwicklungsabschnitt verstärkt auf die Korrektur von Fehlern zu konzentrieren, und verhindern, dass komplexere Änderungen neue Fehler nach sich ziehen.

Viele der im ersten Entwicklungsabschnitt integrierten Änderungen in Form von mit Diff erzeugten Patches bereiten die Kernel-Hacker vor. Zumeist erst im stillen Kämmerlein der Entwickler, bevor diese die Patches auf einer Subsystem-spezifischen Mailingliste und anschließend auf der Linux Kernel Mailing List (LMKL) zur Diskussion stellen. Findet der Patch einigermaßen Anklang, wandert er normalerweise zu Testzwecken in den von Andrew Morton gepflegten mm-Entwicklerkernel. Sehen die für den jeweiligen Kernel-Bereich zuständigen Kern-Entwickler rund um Torvalds den Patch als ausgereift an, wandert er schließlich zu Beginn des nächsten Entiwcklungszyklus in den offiziellen Kernel.

Durch diese öffentliche Entwicklung und einen tiefen Blick in den Kaffeesatz sind der Autor dieses Artikels und der von der Linux-Foundation gewartete Radarschirm des Linux Weather Forecast bereits bei der Vorstellung einer neuen Kernel-Version grob in der Lage abzuschätzen, welche größeren Neuerungen die darauf folgende Version enthalten dürfte. Welche Patches allerdings tatsächlich in die nächste Kernel-Version einziehen, lässt sich dennoch nicht sicher vorhersagen. Schon häufig ist es vorgenommen, das Torvalds oder andere wichtiger Linux-Entwickler Neuerungen, denen verschiedene Beobachter und langjährige Linux-Hacker gute Chancen auf einen Einzug in die nächste Kernel-Version gegeben hatten, nachhaltig kritisierten. In Folge dessen wurden die Änderungen dann erstmal ausgespart; sie finden dann häufig nach weiteren Diskussionen und Anpassungen ein oder zwei Versionen später den Weg in den offiziellen Linux-Kernel. Ab und an verschwanden aber selbst größere Neuerungen mit guten Chancen auf die Integration nach Kritik wieder komplett von der Bildfläche und gerieten in Vergessenheit. Gelegentlich aber geht es in der ersten Entwicklungsphase des Linux-Zyklus auch ganz schnell und die Entwickler integrieren erst kurz zuvor veröffentlichte Patches nach nur wenigen Tagen direkt in den offiziellen Kernel. (thl)