Linux-Distributionen – Welche Bedeutung haben sie in Zukunft?

Linux ist kein Betriebssystem, sondern ein Kernel. Den Spruch kriegen Anwender seit Jahren zu hören. Das was auf den Geräten installiert wird, kommt meist in Form einer Linux-Distribution, also einer Zusammenstellung, zum Anwender. Doch welche Bedeutung haben sie nach Jahren der Nivellierung?

Wie der Name schon sagt, sorgen Distributionen für die Verteilung der Software an den Anwender. Man kann Linux nicht ohne Distribution nutzen, man kann sich höchstens selbst eine Distribution mit Linux from Scratch bauen. Dirk Deimeke hat kürzlich in seinem Blog über die zukünftige Rolle von Distributionen geschrieben. Die Perspektive auf das Problem rührte primär von den neuen Formen her Applikationen auszurollen. Seien es Container oder neue Formate. Ich denke die Ursache für den sukzessiven Bedeutungsverlust liegt noch tiefer.

Linux-Distributionen sind ein interessantes Phänomen, wenn man sich den Unterschied von Selbst- und Fremdwahrnehmung angucken möchte. In der Community sind sie identitätsstiftend und die Community formiert sich noch immer primär um die einzelnen Distributionen. Sie sind hier möglicherweise sogar noch wichtiger als die Desktopumgebungen. Das steht in einem interessanten Spannungsverhältnis zur Fremdwahrnehmung, die meist von „dem Linux“ spricht und damit oft die führenden Distributionen meint. Doch steht die Selbstwahrnehmung auch in einem Spannungsverhältnis zur Realität?

Die neuen Formate mit zentralen Verteilungsmechanismen für Applikationen – seien es Docker-Container, Flatpaks oder Snaps – beschleunigen sicher einen Trend, aber sie verursachen ihn meiner Meinung nach nicht. Linux-Distributionen sind seit Jahren einer starken Nivellierung ausgesetzt.

Um zu erklären, was ich damit meine, muss ich ein wenig in Erinnerungen schwelgen. Damals, 2007 oder so, als ich meine ersten nachhaltigen Gehversuche mit Linux machte, gab es massive Unterschiede zwischen den Distributionen. Es ging hier um so grundlegende Fragen wie das Init-System. Upstart, SysV-Init oder BSD-Like Kreationen wie bei Arch Linux. Ob eine Distribution länger an HAL festhielt oder früh auf den neuen Ansatz DeviceKit wechselte, war nichts was der Anwender bestimmen konnte. Das gleiche bei dem Gegensatz richtiger root-Account versus sudo, der Endlosdiskussionen auslöste. Konfigurationswerkzeuge konnten ganz unterschiedlich sein. Man erinnere sich an das Mandriva Control Center (MCC) oder YaST. Unter der Oberfläche waren die Unterschiede noch gewaltiger. Obwohl Linux ein unixoides System ist, regelt das nicht bis ins letzte Detail wo Systemdateien und Bibliotheken liegen müssen.

Bei der Paketverwaltung gab es himmelweite Unterschiede, die weit über den Gegensatz RPM versus DEB hinausgingen. Es machte in der praktischen Bedienung durchaus einen Unterschied, ob man das komplexe Toolkit von Debian verwenden durfte oder die quälend langsamen Routinen von openSUSE oder Fedora. Letztere konnten lange Zeit nicht mal nicht mehr benötigte Abhängigkeiten entfernen und die Abhängigkeitshölle mit totaler Blockade des Systems ist kein Märchen, sondern war traurige Realität.

Auch die Software-Auswahl war eine bewusste Entscheidung der Distributions-Entwickler. Die Beispiele entstammen jetzt dem KDE-Bereich, weil ich damit am meisten gearbeitet habe, aber sie lassen sich sicher auf andere Desktopumgebungen übertragen. Die Entscheidungen für KDE bei 3.5 zu bleiben, wie Debian sie entgegen dem allgemeinen Trend bei „Lenny“ traf, waren individuelle Entscheidung der Entwickler. Nur wenige mögen sich erinnern, aber Kubuntu lieferte bereits mit KDE 3.5 Dolphin als Dateimanager aus. Oder wenn eine Distribution eine bestimmte Software wie KDEPIM in einer anderen Version nutzte, als den Rest des Ökosystems und so den Wechsel auf Akonadi hinauszögerte. Die Wahl des Displaymanagers auf LightDM, wie sie bis vor Kurzem das Ubuntu-Universum prägte, hatte Folgen für die Anwender. Die Upstream-Entwickler haben das gehasst, weil die Wechselwirkungen unvorhersehbar waren und so manches Problem verursachten.

Der Anwender entschied sich somit nicht nur für eine Distribution als Marke, sondern kaufte damit im übertragenen Sinne auch ein Set an Werkzeugen und Systemdesign-Entscheidungen ein, die sein Anwendungserlebnis massiv prägten.

Das hat sich in den letzten Jahren sukzessive gewandelt. In einem allgemeinen Trend haben die meisten Distributionen sich für systemd und damit verbundene Dienste entschieden. Das gleiche gilt für PolicyKit, udev, upower usw. Der Trend, alles in /usr abzulegen vereinheitlicht die Dateistrukturen der Distributionen. freedesktop-Standards spielen heute eine zentrale Rolle und werden verbreitet befolgt. Heute kommen sogar Debian und Fedora mit Administratorrechten via sudo und die Distributionen, die beim klassischen root-Konzept geblieben sind, blockieren einen direkten Anwendungsstart damit. Die Entwicklung ausgereifter grafischer Konfigurationswerkzeuge für die Desktopumgebungen hat Eigenlösungen der Distributionen abgelöst (außer bei openSUSE). Software ist komplexer geworden, weshalb die meisten Distributionen upstream nur noch wie vorgesehen paketieren.

Sogar vor den Installationsroutinen hat die Nivellierung nicht halt gemacht. Sehr viele Distributionen verwenden heute Calamares als Installer. Das Spektrum reicht hier von Debian bis Manjaro. Daneben pflegen viele Distributionen zwar noch ihre Eigenentwicklungen, aber der Trend ist deutlich zu sehen.

Die Unterschiede zwischen den meisten Distributionen haben sich also stark nivelliert. Wer das nicht wahrhaben möchte, sollte mal versuchen, ein aktuelles BSD aufzusetzen. Natürlich gibt es noch die Spezialfälle wie Slackware, Vault Linux oder Devuan aber diese sind eine winzige Minderheit. Sowohl was die Nutzerzahlen betrifft, als auch gemessen an der Gesamtzahl der Distributionen. Die meisten Distributionen haben inzwischen ein stark vereinheitlichtes Ökosystem mit lediglich graduellen Unterschieden. Man kann Systeme und Arbeitsweisen meist sehr schnell auf einen neuen Unterbau umziehen.

Das gilt sogar für die Releasezyklen. Entweder es gibt keinen Zyklus und die ganze Distribution wird rollend weiter entwickelt oder es gibt fixe Zyklen mit relativ langen Supportzeiträumen. Es ist fertig, wenn es fertig ist, was z. B. lange Debian von Ubuntu abhob, gilt schon lange nicht mehr. Faktisch wird irgendwann alle zwei Jahre im Frühjahr ein Release veröffentlicht um den groben Zyklus einzuhalten.

Noch lustiger wird es, wenn man auf die Ebene der Maintainer guckt. Zwischen Debian und Ubuntu gibt es inzwischen so viele „Personalunionen“, wo der gleiche Entwickler die selben Pakete für beide Distributionen betreut, dass man schon fast Debuntu als Distribution sprechen kann.

Diese Nivellierung sehe ich überhaupt nicht negativ. Qualitativ hat Linux als System massiv vom Wechsel Quantität zu Qualität profitiert. Niemand, der beispielsweise mit openSUSE 10.2 arbeiten durfte will ernsthaft in diese Zeit zurück.

Auf diese stark vereinheitlichte Basis treffen nun neue Paketierungsformate für Desktopsysteme und der Trend zu Virtualisierung und Containern im professionellen Bereich. Der Trend zur Vereinheitlichung wird sich dadurch eher beschleunigen, da zentrale Anwendungen aus den gleichen Bezugsquellen dann einfach auf die Distributionsbasis gelegt werden.

Angesichts der Nivellierung stellt sich aber schon die Frage, warum es diesen Zoo an Distributionen gibt. Im Grunde genommen ist meiner Meinung nach vor allem Tradition und Identitätsbildung für die Community. Zusätzlich noch ein paar dicke Entwickler-Egos, denn warum sollte man gerade das eigene Projekt zugunsten der Konkurrenz einstellen.

Denn faktisch ist Linux längst ein Betriebssystem. Linux ist der Kernel plus zentrale Bestandteile, die nahezu alle Distributionen teilen und die sie von anderen freien Systemen wie BSD-Varianten oder Android abheben.