Was mir an GNU/Linux-Systemen nicht gefällt

Heute ein Thema, das ich aufgrund meiner sonst so überschwenglichen Befürwortung zur Verwendung von GNU/Linux-Systemen seltener anspreche: »Was mir an GNU/Linux nicht so gut gefällt«. Ich fand, das wäre auch mal ganz interessant. Sogar GNU/Linux hat trotz seiner durch das Prinzip des freien Quellcodes verankerten Überlegenheit auch einige negative … – ups, da habe ich schon wieder etwas geschwärmt :)

Zum Thema.

Am Herz des freien Betriebssystems habe ich grundsätzlich nichts auszusetzen. Allein seine gewaltige Treiberunterstützung beeindruckt mich immer wieder. Umso weniger kann ich gutheißen, daß in letzter Zeit der Kernel »abgespeckt« wurde, d.h. die Unterstützung für ältere Prozessoren aus neueren Kernel-Versionen entfernt wurde (z.B. diese Quelle).

Begründet wird dieser Schritt damit, daß der entsprechende Code »Schwierigkeiten beim Umbau« mache. Ich selbst habe nie am Kernel programmiert und kann mich gewiß nicht mit den aktiven Entwicklern messen. Aber ist das wirklich ein so gewaltiges Problem, ein paar Code-Schnipsel integriert zu halten, um damit eine möglichst breite Palette von Prozessoren auch weiterhin zu unterstützen, notfalls bis in alle Ewigkeit? (Ein Jammer, da der entsprechende Code wahrscheinlich allein durch sein Alter weitgehend fehlerfrei war.) Denn das ist es ja, was den Linux-Kernel vom abgeleiteten Mac-System oder Windows unterscheidet: Daß er auch auf uralten Rechnern zum Einsatz kommen kann, gerade weil er diese umfassende Unterstützung bietet! Den aktuellen Mac- oder Windows-Kernel auf einem uralten Rechner zum Laufen kriegen? Ausgeschlossen, meine ich. An diesem Punkt war immer Linux zur Stelle und man konnte sich darauf verlassen. Nun aber wird man bald sagen müssen: 386er-Prozessor? Leider nicht mal mit Linux!

Nur um mich richtig zu verstehen: Auch ich sehe ein, daß »Forking« die Welt der freien Software am Laufen hält und ihr erst Leben einflößt. Daß dies der Schritt ist, um die in dieser Hinsicht bei der Arbeit mit einem Computer erwartete Freiheit wirklich zu leben! Aber man kann es eben auch übertreiben, wie ich an einigen populären Beispielen zeigen will:

• GNU/Linux-Distributionen: Mageia und RazorQT
• Vektorzeichensoftware: Krita und Inkscape
• Büro-Software: OpenOffice, LibreOffice, Calligra…
• Web-Browser: Firefox, Epiphany, Midori, rekonq…
• Chat-Clients: Pidgin, Empathy, Gajim…

Alle diese aufgezählten Programme decken innerhalb ihrer Kategorie zumeist einen weitgehend identischen Funktionsumfang ab. Warum ich mich nun so sehr darüber aufrege? Was der Schaden ist, den das ständige Forken anrichtet? Das naheliegende ist die offensichtliche Verwirrung beim Nutzer: Das beginnt bei der Wahl der GNU/Linux-Distribution, wovon jede für sich behauptet, die beste und anwenderfreundlichste zu sein. Greift man zu einer bekannten Distri und ignoriert die anderen einfach? Warum auch sollte ich – wenn ich mich für Kubuntu entscheide – zu Mageia oder RazorQT greifen, die mir eine identische Oberfläche bieten und sich nur in spitzfindigen Details unterscheiden? Kommt mir da als unbedarfter Nutzer nicht sofort die Frage in den Sinn, wieso man die Kapazitäten der Entwickler nicht bündelt und damit bewirkt, daß ein allumfassendes Endprodukt entsteht? Eine KDE unterstützende Distri, die man nicht auswählen muß, sondern ausschließlich nimmt, wenn man KDE zu nutzen gedenkt?

Einen ähnlichen Vergleich läßt die Kategorie der Web-Browser zu: Mit einem Funken Bedauern schaue ich mir hin und wieder an, wie sich die Entwicklung wenig verbreiteter Browser wie Midori, rekonq oder Epiphany voranschleppt und daß für deren Entwicklung überhaupt Ressourcen bereitgestellt werden, wo es doch die »großen« Brüder wie Firefox gibt, in denen seit Jahren jene Funktionen implementiert sind, die man bei den kleineren Browsern nun erst nach und nach integriert. Was sollte mich dazu treiben, einen so unerträglich abgespeckten Browser wie Epiphany zu nutzen, wenn mir doch Firefox doppelt so viele Funktionen und Stabilität bietet? (Das hier soll keine Werbung für Firefox sein, sondern nur das Prinzip erläutern!)

Daß eine Parallelentwicklung ein- und derselben Funktionssoftware stattfindet, wird häufig mit der Integration in bestimmte Desktopoberflächen begründet: Es stimmt, daß sich rekonq in eine KDE-Oberfläche besser integriert als beispielsweise Epiphany. Aber sind im Jahr 2013 wirklich inkompatible Bibliotheken das unüberwindbare Problem?

Ein anderer Grund, den ich durchaus nachvollziehen kann, ist das Forken eines Projekts für den Zweck, eine weniger systemressourcenlastige Anwendung zu schreiben, die auch problemlos auf älteren PCs ausgeführt wird. Das ist im übrigen eine Schiene, für die sich die Konkurrenz Windows oder Mac seit Urzeiten nicht interessieren: PC zu alt? Kauf einen Neuen! Dann läuft auch dort die aktuelle Software! Jedenfalls wäre das einer der wenigen Gründe fürs Forken, die ich verstehen kann. (Aber wieso dann nur um alles in der Welt ein Projekt wie Calligra, das eine große Büro-Suite für moderate (und nicht altersschwache) Systeme sein will, aber so unerträglich verbuggt ist, daß man keine 10 Minuten damit arbeiten kann? Was nur hält mich davon ab, nicht sofort zu LibreOffice zu greifen, wo der Code stabil läuft (vom Funktionsvergleich abgesehen)? Ist das nicht ein wenig Zeitvergeudung für die Entwickler des Calligra-Projekts?

Eine weitere Begründung ist häufig ein Problem mit der Open-Source-Lizenz, wie das OpenOffice/LibreOffice-Beispiel schön zeigt: Gerät ein Projekt die OpenOffice durch Vererbung in falsche Hände (gewinnorientiertes Firmengeschäft), ist es durchaus sinnvoll, das Projekt durch Forken der Gemeinschaft zurückzugeben! Ich als Nutzer freier Software und jemand, der diesen freien Gedanken mit seiner Philosophie in allen Einzelheiten ausleben möchte, käme im Folgenden doch nie auf die Idee, zum restriktiven OpenOffice zu greifen! Stets würde ich LibreOffice bevorzugen! Wieso dann also Entwickler an OpenOffice arbeiten lassen?

Welche zwei großen Folgen ergeben sich nun durch das ständige Parallel-Betreiben von Software-Projekten?

1. Letztlich will der Anwender für eine einzige Arbeit nicht verschiedene Programme nutzen: Wer will schon eine Zeichnung in der einen Vektorzeichen-Software anlegen und sie in einer anderen öffnen müssen, weil dort der PDF-Export-Filter mehr Einstellungen zuläßt? Wer will mit LibreOffice Calc eine Zahlentabelle anlegen, um in einer anderen Tabellenkalkulation daraus ein Diagramm zu erstellen, weil es den gewünschten Diagramm-Typ im ersteren Programm nicht gibt? Forking wird demnach immer dazu führen, daß nützliche Funktionen verteilt werden, anstatt sie in einem einzigen Programm zusammenzuführen. Man erhielte theoretisch alle Vorzüge, aber keine Nachteile.
2. Dadurch, daß verschiedene Entwicklergruppen aus häufig nur ein paar Mitgliedern sozusagen parallel am gleichen Projekt arbeiten, wird Potential verschenkt, und zwar die Chance, einen möglichst fehlerfreien Code zu erzeugen. Würden sich dagegen die Bemühungen der Entwickler auf ein Projekt fokussieren, könnten auch Wartungsarbeiten am Code schneller durchgeführt werden und Fehler würden rascher gefunden werden. Dies erhöht freilich auch die Sicherheit des ganzen Projekts, v.a., wenn man sicherheitsrelevante Software wie Web-Browser entwickelt.

Der Dualismus eines einzigen Programms, sowohl mit als auch ohne graphische Oberfläche bedienbar zu sein, ergibt dagegen Sinn: Damit kann es auch auf älteren oder reparaturbedürftigen PCs, auf welchen (aus welchem Grund auch immer) der Betrieb eines X.Server behindert ist, ausgeführt werden.

Ein anderer Kritikpunkt ist, daß weitverbreitete GNU/Linux-Distributionen mit ihren Oberflächen wie Unity, KDE Plasma oder GNOME immer mehr dem aktuellen Trend nacheifern. Dazu gehören blinkende, transparente, animationsreiche Schnulli-Ästhetik, die im übrigen mit jedem neuen Eye-Catcher neue potentielle Baustellen für Fehler im Code bringen und nach und nach wieder ausgebügelt werden müssen. Außerdem benötigt man für derartige Oberfläche immer häufiger eine erzwungene 3D-Unterstützung seitens der Graphikkarte und eine generell erhöhte Beanspruchung der Systemressourcen. (Oberflächen wie Xfce beweisen dagegen, daß auch ohne aufwendige Animationen ein Desktop schick und funktional sein kann.)

Über den damit einhergehenden Trend, manchen Programmen den Funktionsumfang unter dem Vorwand der Vereinfachung für den Endnutzer zu entziehen, lasse ich mich im nächsten Punkt aus.

Ich gebe zu, diesen Kritikpunkt noch nicht bei sehr vielen Programmen gesehen zu haben. Normalerweise gibt es das ungeschriebene Gesetz, daß jede Software mit steigender Versionszahl an neuen Funktionen dazugewinnt, umfangreicher und stabiler wird.

Doch es gibt Ausnahmen, die mit der im vorherigen Punkt angesprochenen »Modernisierung« des Desktops einhergehen. Ein Beispiel ist der eigentlich weit entwickelte Dateimanager Nautilus, der zum Beispiel auf der Gnome- oder Unity-Desktop-Oberfläche zum Einsatz kommt. Vor einiger Zeit entschieden sich die Entwickler dazu, zwecks Vereinfachung auf Funktionsumfang zu verzichten; schwupps wurden z.B. das außerordentlich nützliche Umschalten auf eine gesplittete Ansicht (Verzeichnis neben Verzeichnis) oder erweiterte Konfigurationsmöglichkeiten entfernt (Details siehe hier). Eine Funktion, die ich über die Jahre unter Gnome 2 kennengelernt und geschätzt hatte, wurde nun entfernt, sodaß kein Grund mehr bestand, Nautilus weiterhin zu nutzen. Eine ältere (und funktionsreichere) Version von Nautilus wurde übrigens als »Nemo« geforkt und kommt nun unter anderem im Cinnamon-Desktop der Distribution »Linux Mint« zum Einsatz.

Eine andere Geschichte ist der komplette und weitgehend verhaßte Umbau der Gnome 2-Oberfläche zu Version 3, der Gnome Shell. Ich sehe ein, daß Oberflächen, die eine völlige Umgewöhnung abfordern, ungern gesehen werden. Zumindest in der Software-Welt dürfte es nicht zu viel verlangt sein, dem Endanwender eine Möglichkeit zu offerieren, auch weiterhin eine vertraute Oberfläche nutzen zu können. Unter Gnome 2 beliebte Systemteile wie die höchst anpaßbare Panelleiste fielen der revolutionierten Gnome Shell zum Opfer; sie werden derzeit mit Version 3.8 wieder integriert und als neue Features verkauft. Wie ich es verachte, als Computernutzer wie ein Kleinkind behandelt zu werden…

Die meisten großen Distributionen haben ein festgelegtes Veröffentlichungsdatum, zu dem die neue Version der Distri erscheinen soll. Canonical beispielsweise bringt zweimal jährlich, im April und Oktober, eine neue Version seiner Distribution Ubuntu heraus. Ob nun das oder das Rolling-Release-Modell das bessere ist, will ich hier nicht diskutieren und ist für mich eigentlich auch egal.

Ein Problem ist allerdings, daß durch die festen Veröffentlichungstermine ein erschreckender Zwang entsteht, neue Funktionen vorzustellen: Wer will schon gerne eine neue Version präsentieren, die sich inhaltlich zur Vorherigen nicht verändert hat? (Häufig entspricht eine neue Distri-Version ohnehin nur einer Ansammlung ihrer aktualisierten Programm-Bestandteile und ein paar neuer Wallpaper.) Andere knobeln wochenlang, welche ach-so-neuen Funktionen implementiert werden könnten, anstatt das Augenmerk auf wichtigere Dinge zu legen: Beispielsweise bringt die derzeit aktuelle Gnome Shell 3.8 eine Art Uhren-App mit, obwohl man stattdessen dafür sorgen sollte, daß der Code möglichst fehlerfrei läuft. Hier wird das Wesentliche falsch fokussiert.

Vielleicht sollte man sich bei der ganzen Sache am Debian-Modell orientieren. Dessen Maxime »It’s done when it’s done.« ist gar nicht mal so verkehrt. Dann käme eben nur alle paar Jahre eine neue große Version heraus, die dann dafür aber weitgehend getestete Neuerungen enthält. Oder man vertraut doch auf das Rolling-Release-Prinzip und veröffentlicht Aktualisierungen, wenn sie da sind. Permanent. Dann braucht man wahrscheinlich noch seltener neue Distri-Versionen.

Dieser Kritikpunkt wurmt mich vermutlich am meisten, vielleicht, weil ich das Betreffende so sehr aus der Windows-Welt geliebt habe. Es geht darum, Installationspakete für jedwede Software autonom speichern zu können und damit bei Bedarf weniger vom Internet abhängig zu sein. Denn eines ist klar: GNU/Linux ohne Internet ist echt Mist. Windows ohne Internet ist weniger Mist, weil man sich vorher alle benutzte Software als unabhängige .exe-Setup-Pakete gespeichert hat und ganz nach Belieben einspielen konnte. Internet war dafür größtenteils nicht erforderlich (im Ausnahmefall für Registrierung). Es mußten keine abhängigen Pakete nachgeladen werden, alles war enthalten. (Mittlerweile ändert sich dieser Trend aber immer mehr zu Net-Installern, die einen genauso vom Internet abhängig machen wie Software für GNU/Linux.

Das ist eben bei der meisten GNU/Linux-Software anders: Es gibt – natürlich – immer den Quellcode als gepackte Datei zum Download. Theoretisch könnte man die sich offline speichern und bei Bedarf kompilieren. Aber sicher sein, daß beim Kompilieren nicht doch irgendeine winzige unbekannte Bibliothek fehlt und der Installationsfortgang deshalb verweigert wird? Darauf kann man sich nie verlassen.

Dann gibt's da noch vorkompilierte Pakete z.B. im .deb und .rpm-Format. Die sind schon so ähnlich wie .exe-Dateien, können also per Knopfdruck installiert werden. Häufig werden beim Installieren aber trotzdem noch ein paar fehlende Bibliotheken verlangt, die man im Notfall natürlich gerade nicht zur Hand hat. Ja, so muß ich es zugeben, da war ich mit offline gespeicherten .exe-Dateien immer auf der sicheren Seite und hatte meine Lieblingssoftware schnell zur Hand und genauso fix installiert.

Keine Frage: Wer Internet an seinem Rechner hat, hat sein GNU/Linux wahrscheinlich schneller mit neuer Software versorgt. Aber wehe, die Internetverbindung ist mal nicht aufrufbar…