Die Woche: Distributionen brauchen frische Treiber
Manche Linuxer wollen ein stabiles System ohne ständige Updates, andere wünschen sich immer die neuesten Versionen, auch um Treiber für neue Hardware bekommen. Ein mehrstufiges Modell mit zwei "aktuellen" Distributionen könnte eine Lösung sein.
- Thorsten Leemhuis
In der Software-Entwicklung hat sich das Modell "Programmcode verbessern, in Vorab-Version stabilisieren und dann freigeben" etabliert; anschließend beginnt das ganze von vorne, während die freigegebene Version parallel mit Fehlerkorrekturen versorgt wird. Auch die meisten Linux-Distributionen folgen diesem Muster, um die enthaltene Software aufeinander abzustimmen und die Mischung zu testen. Um dieses Gefüge nach der Freigabe einer Distribution nicht ins Wanken zu bringen, gehen viele Distributoren bei der Pflege sehr vorsichtig vor – statt Updates auf neuere Programm-Versionen reichen sie lediglich Änderungen nach, die Sicherheitslücken und andere schwerwiegende Fehler korrigieren.
Das mag Anwendern eine stabile, sich kaum verändernde Arbeitsumgebung bieten, koppelt sie aber komplett vom "Upstream" ab – also den Programmierern der Software, aus denen die Distributionen zusammengestellt wird. Wenn die Upstream-Entwickler eine neue Version freigeben, die zahlreiche Fehler behebt (und gar keine gefährlichen Neuerungen bringt), heißt das keineswegs, dass Distributionen diese neue Version auch an die Anwender weiterreichen. Wer sich auf die Updates der Distribution verlässt und nicht eigenhändig ein Update einspielt, muss sich unter Umständen mit Programmfehlern arrangieren, die deren Entwickler schon vor Monaten beseitigt haben.
Das allein ist schon ärgerlich genug. Es sind allerdings nicht nur Fehlerkorrekturen, die nicht oder nur erheblich verzögert bei den Anwendern ankommen – auch die Verbesserungen kommen nur langsam zu den Nutzern. Besonders krasse Folgen hat das beim Motor des Linux-Systems: dem Linux-Kernel. Der sorgt sich nämlich nicht nur um Basis-Infrastruktur wie den Start des Systems oder das Speicher- und Prozess-Management, sondern enthält auch fast alle Treiber.
Das stellt insbesondere jene Hardware-Hersteller vor Probleme, die Open-Source-Treiber für ihre Hardware entwickelt und diese in den Standard-Kernel einbringen. Sie müssen nämlich Treiber für neue Prozessoren, Grafikkarten oder andere Chips bereits Monate vor der Einführung dieser Bauteile in den Kernel integrieren, damit die zur Produkteinführung aktuellen Distributionen ordentlich auf den neuen Chips arbeiten. Bei den schnellen Produktzyklen moderner Hardware bekommt das kaum eine Firma richtig hin.
Schwergewicht Intel schafft es noch vergleichsweise gut. Der Anfang August fertiggestellte Linux-Kernel 2.6.35 etwa unterstützt bereits Funktionen, Grafikchips und Mainboard-Chipsätze der Sandy-Bridge-Prozessoren, die Intel aktuellen Gerüchten zufolge erst Anfang nächsten Jahres einführen wird; nur dadurch werden im Herbst erscheinende Distributionen wie Fedora 14 und Ubuntu 10.10 auf den nächstes Jahr erhältlichen Sandy-Bridge-Systemen halbwegs ordentlich arbeiten. Das dann noch aktuelle OpenSuse 11.3 mit Kernel 2.6.34 hingegen dürfte nicht wirklich rund laufen.
Im Rahmen der regulären Updates gibt es bei OpenSuse allerdings ebensowenig neue Kernel wird bei Ubuntu und den meisten anderen Distributionen; OpenSuse-Anwender werden also auf das nächste Release der Distribution wareten müssen. Fedora hingegen liefert Kernel-Updates nach, doch auch dort gibt es laute Stimmen, die auf eine konservativere Update-Strategie drängen: Der Kernel ist eine so zentrale Komponente des Linux-Systems, dass eine neue Kernel-Version immer für unliebsame Überraschungen sorgen kann.
Ein Trugschluss ist die Annahme, eine Abspaltung der Treiber vom Kernel würde die Problematik beseitigen. Vielmehr verlagert sie das Problem nur, wie Ubuntu mit den proprietären Grafikkartentreibern von AMD und Nvidia zeigt. Die der Version 10.04 (Lucid Lynx) beiliegenden Treiber stammen aus dem Frühjahr dieses Jahres – seitdem sind zahlreiche neue GeForce- und Radeon-Grafikkarten auf den Markt gekommen, die neuere Treiberversionen erfordern. Teilweise sind solche Treiber und neue Kernel über (inoffizielle) Add-On-Depots erhältlich. Von denen muss man allerdings wissen; gelegentlich gibt es zudem Abstimmungsprobleme zwischen den regulären Updates und denen aus dem Zusatzdepots.
Und wer für seine Hardware sowohl einen frischen Kernel als auch einen neuen Grafikkartentreiber braucht, muss diese teilweise selber aufeinander abstimmen – oder zu einer Vorabversion der kommenden Version seiner Distribution greifen. Dann muss man sich allerdings damit arrangieren, dass dann auch unreife Alpha- und Beta-Software auf der Platte landet, welche die Entwickler als noch nicht reif für Anwender einstufen.
All das ist auch eine der Hauptursachen für den Ruf, Linux laufe auf älterer Hardware besser. Die Entwickler der Distributionen könnten dem erheblich entgegenwirken, indem sie aktualisierte Kernel und andere Treiber als reguläres Update für die jeweils neuste Version ihrer Distribution ausliefern; auch über größere Versionssprünge bei Anwendungen wie Firefox, Gnome, KDE, OpenOffice, Thunderbird und Co. würden sich viele Anwender freuen.
Ein Allheilmittel ist das allerdings auch keineswegs, denn trotz aufwendiger Tests kann jede neue Version einer Software auch neue Probleme mit sich bringen. Die meisten Distributoren pflegen aber ohnehin neben der aktuellen Version einer Distribution noch ein oder zwei ihrer Vorgänger, bei den sie die konservativere Herangehensweise nutzen können.
Bei einer imaginären Distribution "Knurdix" könnte das wie folgt aussehen. Distributions-Entwickler und wagemutige Tester nutzen einen Entwicklerzweig mit Alpha- und Beta-Software, in dem ähnlich wie bei Fedora Rawhide, Mandriva Cooker oder OpenSuse Factory die nächste Version der Distribution vorbereitet wird – beispielsweise das für Herbst 2010 geplante Knurdix 7.
Knurdix 6 wäre die aktuelle, im Frühling 2010 nach einer Stabilisierungsphase erschienene Version, die bei der Vorstellung den zu der Zeit aktuellen Kernel 2.6.33 nutzte. Nach einer über dedizierte Test-Depots realisierten Testphase von ein bis drei Wochen erhält sie die zwischenzeitlich erschienenen Kernel-Versionen 2.6.34 und 2.6.35 als reguläres Update; auch Userspace-Treiber wie die Sane-Backends oder Gutenprint sowie Software wie Firefox oder Gnome sind mittlerweile aktualisiert. Anwender sind daher in etwa auf dem Entwicklungsstand, den die Upstream-Entwickler der einzelnen Programme als "aktuelle stabile Version" einstufen.
Das klingt wagemutig, ist aber ein Konzept, das sich bei einigen Rolling-Release-Distributionen und in ähnlicher, leicht abgeschwächter Form auch bei Fedora nicht nur als gangbar erwiesen hat, sondern auch viele fortgeschrittene Linux-Anwender angelockt hat. Auch Debian-Unstable und -Testing funktionieren je nach Punkt im Entwicklungszyklus ähnlich – die Bezeichnungen dürften Neulinge allerdings verschrecken.
Durch die Update-Strategie in der ersten Lebensphase wäre Knurdix 5 jetzt im Spätsommer auf dem Stand etwa des ebenfalls im Frühling erschienenen Ubuntu 10.04 und käme mit nicht ganz brandaktueller Hardware gut klar. Wer Unterstützung für neuere Hardware bräuchte oder gerne neue Versionen von Software hat, wäre hingegen mit Knurdix 6 gut bedient; allerdings ohne Alpha- und Beta-Software ausgesetzt zu sein, wie man es derzeit mit den Vorabversion von Fedora 14 und Ubuntu 10.10 ist.
Etwas in der Art ist mit Debian unter Zuhilfenahme des Backport-Depots schon heute möglich und stellt so manchen Anwender zufrieden. Bei Distributionen wie OpenSuse oder Ubuntu könnte es jene Anwender ruhig stellen, die sich mehr Updates wünschen; bei Fedora hingegen jene Stimmen, die sich eine konservativere Update-Strategie wünschen. (thl)
(thl)
