Die Woche: Es soll einfach klappen

Ich habe "Warten auf Freitag" ein Plus für seinen Foren-Beitrag zu meiner Tickermeldung Neue Linux-Kernel beseitigen Stromsparproblem gegeben. Es wurmt mich allerdings ein wenig, dass die anderen Forenteilnehmer ihn vorwiegend negativ bewerteten, Fische werfen und das Wort "Troll" in ihren Antworten bemühen. Dafür heimsen sie positive Bewertungen ein, obwohl "Warten auf Freitag" drei wichtige Punkte kurz und knapp anspricht, die ich an dieser Stelle aufgreifen möchte.

Schon mit der Überschrift "Ich will gar nicht wissen, dass es so Zeug gibt" trifft er einen Nagel auf den Kopf, den Linux-Fans häufig vergessen. Bei meiner Arbeit beschäftige mich jetzt schon über ein Jahrzehnt vorwiegend mit Hardware und Linux; dabei bin ich über jedes Detail froh, auf das ich keine Zeit verschwenden muss. Dazu sollte auch die PCIe-Stromspartechnik ASPM gehören, um die es in der kommentierten Tickermeldung geht: Damit will ich mich genauso wenig beschäftigen wie mit der IRQ-Verteilung, der Kernel-Konfiguration, den beim Übersetzen meiner Distribution verwendeten Compiler-Flags oder der gerade genutzten Taktfrequenz-Stufe meines Prozessors.

An alle, die jetzt denken: "Der spinnt doch – diese Techniken arbeiten effizienter, wenn ich sie so konfiguriere, dass sie zu meinen Ansprüchen passen": Ja, das stimmt bis zu einem gewissen Grad. Aber der Aufwand (Hintergründe aneignen, Techniken konfigurieren, Neuerungen verfolgen, Konfiguration pflegen, …) ist hoch und wiegt die erzielten Vorteile in vielen Fällen nicht auf.

Häufig stellt man sich dabei sogar selbst ein Bein. Die Taktfrequenz der CPU ist dafür ein gutes Beispiel: Ich begegne immer wieder Linux-Anwendern, die bessere Batterielaufzeit erzielen wollen, indem sie den Prozessor auf die niedrigste Taktstufe festsetzen. Das funktionierte aber nur in den Anfangszeiten von SpeedStep und PowerNow und der damals noch unausgereiften Linux-Unterstützung: Schon seit Jahren ist es fast immer effizienter, die Automatiken zu nutzen – durch sie schaltet der Prozessor bei größerem Arbeitsumfang zügig hoch und erledigt Aufgaben möglichst schnell, wodurch er sich früher und somit länger schlafen legen kann.

Mit "Das soll einfach klappen, und das bitte nicht erst nach zwei Jahren." beginnt "Warten auf Freitag" den eigentlichen Kommentar – und macht gleich ein neues Fass auf: Manche wichtige Technik funktioniert unter Linux erst nach längerer Zeit. Das seit 2001 immer wichtiger gewordene und heute nahezu unverzichtbare ACPI ist dafür ein gutes Beispiel: Lange Jahre war es Problemfeld Nr. 1 im Zusammenspiel mit Linux – erst sei ungefähr 2007 oder 2008 ist es nur noch selten Problemverursacher.

Die lange Jahre schwelende ACPI-Problematik ähnelt dem jetzigen ASPM-Problem und den Schwierigkeiten, mit denen uns UEFI zumindest dieses Jahr quälen wird: Der Linux-Kernel darf sich bei der Hardware-Nutzung nicht zu streng an die Spezifikation halten, sondern muss gelegentlich ähnlich vorgehen wie Windows, um die Hardware korrekt und effizient zu verwenden. Außerdem müssen Linux-Entwickler Feedback an die Hardware-Hersteller liefern und in den Gremien mitarbeiten, welche die Spezifikationen entwerfen, damit unweigerlich entstehende Probleme aus der Welt geschafft werden. In einer besseren Welt sollte das vielleicht nicht nötig sein – in der leben wir aber nicht, daher sind Taten gefragt, denn Wünsche und Situationskritik schaffen keine Probleme aus der Welt.

An dem vielleicht etwas überspitzten "bitte nicht erst nach zwei Jahren" trägt die Linux-Welt durchaus auch selbst Mitschuld, denn selbst wenn ein Hardware-Hersteller bei Erscheinen einer neuen Hardware-Komponente passende Open-Source-Treiber veröffentlicht, dauert es nicht selten sechs bis zwölf Monate, bis die großen Distributionen sie an die Nutzer weiterreichen. Im November oder Dezember vorgestellte Kernel-Treiber beispielsweise konnten erst im Januar in den Hauptentwicklungszweig von Linux einfließen, aus dem im März der Linux-Kernel 3.3 hervorgehen wird. Das im April erwartete Ubuntu 12.04 LTS wird aber noch Kernel 3.2 verwenden und wohl nur eine Handvoll der Verbesserungen enthalten, die Linux 3.3 bringen wird; die kommen also erst im Herbst mit Version 12.10 bei den Ubuntu-Anwendern an. Debian-Nutzer erhalten die Verbesserungen wohl erst in ein paar Jahren mit dem Nachfolger von Wheezy (7.0).

Meine Doppelplus-Bewertung hat "Warten auf Freitag" allerdings durch das "Linux auf dem Notebook? Ein no-go." verspielt, denn diese Aussage ist dann doch übertrieben. Sie ist aber näher an der Realität als manche Antworten auf den Forenbeitrag, die durchklingen lassen, Linux auf Notebooks sei überhaupt kein Problem. Denn ja, Linux lässt sich auf nahezu allen modernen Notebooks installieren und scheint auf den meisten Geräten auch ganz ordentlich zu laufen. Aber wenn man genau hinsieht, dann findet sich fast immer doch die eine oder andere Komponente, die nicht oder nur eingeschränkt funktioniert.

Das zeigte etwa der c't-Artikel zu Linux auf zehn Business-Notebooks, die die c't-Kollegen aus dem Mobil-Ressort zuvor mit Windows getestet hatten. Die Geräte hatten uns auf gute Linux-Kompatibilität hoffen lassen: Alle Notebooks erhielten gängige Intel-Prozessoren und -Chipsätze, die Linux typischerweise gut unterstützt und die zum Testzeitpunkt schon ein halbes Jahr erhältlich waren.

Linux ließ sich zwar bei allen zehn installieren, bei sechs Notebooks gab es aber so viele Probleme, dass wir den Test abgebrochen haben, um den besser laufenden Geräten mehr Aufmerksamkeit zu widmen. Drei Geräte ließen sich mit gewissen Funktionseinschränkungen immerhin akzeptabel nutzen. Nur bei einem Notebook liefen alle Komponenten mit dem zum Test verwendeten Ubuntu. Durch manuelles Einschalten von ASPM und RC6 sowie dem Drehen an zirka einem halben Dutzend Stellschrauben rund um Stromsparfunktionen bei USB, SATA, HD-Audio und Co. brauchte es auch nur noch 1 Watt mehr als unter Windows. Im Leerlauf hielt es im Akku-Betrieb dann gut fünf Stunden durch; unter Windows waren es knapp zwei Stunden mehr.

Einzelfälle? Nein, denn die Ergebnisse in früheren Jahren waren fast alle noch schlechter; selbst bei Notebooks mit vorinstalliertem Linux waren die Resultate nicht sonderlich besser. Ja, bei älteren Geräten ist die Situation etwas erfreulicher und vielleicht hatten wir auch etwas Pech beim Testfeld. Aber solche Probleme sind real und das Risiko, ihnen zu begegnen, ist keineswegs gering. Wer sie herunterspielt, darf sich nicht wundern, wenn Windows-Anwender sich nach einer missratenen Linux-Installation auf ihrem Notebooks frustriert abwenden und jahrelang über Linux schimpfen. Den Notebook-Herstellern die Schuld in die Schuhe zu schieben löst das Problem auch nicht.

Mitarbeit beim Finden und Beseitigen von Fehlern hingegen verbessert die Situation langfristig. Durch das Schreiben von Webseiten oder Blog- und Foren-Einträgen mit Erfahrungsberichten können sich Linux-Anwender zudem gegenseitig helfen. Denn nur, wenn die Entwickler, Experten und Interessenvereinigungen rund um Linux helfen, die Situation zu verbessern, werden wir irgendwann den Punkt erreichen, wo einfach alles geht. (thl) (thl)