1. Linux-Distributionen – Welche Bedeutung haben sie in Zukunft?
  2. Zersplitterung – Wie sich Linux mobil ins Abseits stellt
  3. Linux-Distributionen – Überholte Infrastruktur?

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.

Moin, meine Name ist Gerrit und ich betreibe diesen Blog seit 2014. Der Schutz der digitalen Identität, die einen immer größeren Raum unseres Ichs einnimmt ist mir ein Herzensanliegen, das ich versuche tagtäglich im Spannungsfeld digitaler Teilhabe und Sicherheit umzusetzen. Die Tipps, Anleitungen, Kommentare und Gedanken hier entspringen den alltäglichen Erfahrungen.

13 Ergänzungen

    • Dem stimme ich zu. Tatsächlich habe ich mir meine erste Linux-Distribution unter anderem wegen der Community ausgesucht. Und da dies die die erste Distribution wurde, die ich intensiv genutzt habe, haben wir diese auch in dem Unternehmen verwendet, wo unser Team erstmals ernsthaften Betrieb auf Linux gemacht hat.

      Heute grenzen sich die Distributionen in meinen Augen vor allem durch ihre Paketmanager, Lebens-Zyklen und die Werkzeuge zur Systemverwaltung voneinander ab. Ich finde es gut, dass man hier die Wahl hat. Mir persönlich gefällt seit einigen Jahren RHEL ziemlich gut. Ich bin jedoch überzeugt, dass wir genauso gut oder schlecht SLES betreiben können.

      Heute wähle ich eine Distribution unter dem Gesichtspunkt aus, welche meine persönlichen Anwendungsfälle, oder die meiner Dienststelle, mit möglichst geringem Aufwand meinerseits erfüllt/unterstützt.

      Aktuell sind dies privat Debian stable und im Dienst RHEL. Zumindest ersteres kann sich aber auch jederzeit nach Lust und Laune mal wieder ändern.

      • Kurios wird diese Community-Bildung über die Distributionen wenn man ins Detail guckt. Ich bin ja bekanntermaßen primär auf ubuntuusers.de unterwegs. Einerseits legt man dort ganz viel Wert auf den Ubuntu-Bezug (siehe Mint etc. in „Fremde Systeme“), andererseits verrate ich keine Geheimnisse, wenn ich sage, dass die Mehrheit der Teammitglieder selbst kein Ubuntu im (primären) Einsatz hat.

        Ich finde es oft ein bisschen schade, dass es kaum übergreifende Sammlungspunkte gibt und diese Abgrenzung so übertrieben wird. Denn abgesehen von ein paar Grundsatzentscheidungen (Zertifizierung oder nicht; RR oder nicht) ist doch alles ziemlich ähnlich.

        • Leider neigen viele Mitglieder der verschiedenen Communities dazu, sehr schnell in „Ditributions-Bashing“ zu verfallen, wenn man versucht sich distributionsübergreifend auszutauschen. Dies ist teilweise so ansteckend, dass ich mich nichtmal selbst davon freisprechen kann, ihm ab und zu nachzugeben.

          Zwar gibt es viele Gemeinsamkeiten, doch auch viele Unterschiede. Zu nennen sind da die verschiedenen Kernelversionen, unterschiedliche beim Paketbau verwendete Optionen, etc. pp. Doch sind diese vermutlich leichter zu überbrücken, als die Rudelbildung und Abrenzung zu bzw. Ausgrenzung von anderen Communities.

  1. Hi,

    tatsächlich sehe ich das ähnlich. Einer der Unterschiede steckt immernoch in den Menschen/Firmen/Strukturen hinter der Distribution.

    Ich würde es auch begrüßen, wenn wir aus den unzähligen eine kleine zählbare Menge Distributionen (seien es 100 – also immer noch „bunt“) und dafür den Menpower pro distribution erhöhen würden.

    Gilt übrigens für alle OpenSource Projekte 😉
    Grüße
    Thoys

  2. Es kommt auch auf die Definition einer „Distibution“ an. Auf hunderte Distributionen kommt man nur, wen man jedes Hobbyprojekt, das nur das Wallpaper getauscht hat, als eigen Distribution zählt, wie es z.B. Distrowatch macht.

    Zählt man nur die, die auch wirklich komplett eigene Pakte aus Upstream zur Verfügung stellen, wird es schnell übersichtlich.

    Und da gibt es dann meist auch doch substanzielle Unterschiede, sei es der Fokus auf möglichst 100% OpenSource, auf Sicherheit, auf lange Supportzeiträume und eine stabile Basis für Server oder möglichst aktuelle Software und testen von neuen Funktionen.

    Natürlich gibt es da auch Schnittmengen und Konkurrenz um den selben Kuchen, wie zwischen RHEL und Suse Enterpreise, aber ein Monopol will man grade in diesem Bereich auch nicht, weswegen es absolut zu begrüßen ist, wenn es da weiterhin mehrere Player gibt.

    Der Streit ob nun Linux Mint oder elementary OS das bessere System sei, gehört nicht in diese Kategorie, das ist wirklich nur die Frage nach dem berühmten Wallpaper.

    • „Zählt man nur die, die auch wirklich komplett eigene Pakte aus Upstream zur Verfügung stellen, wird es schnell übersichtlich.“

      Ich habe es gerade nur mal im Knopf überschlagen und selbst wenn man nur die Distributionen zählt, bei denen alle Pakete selbst gebaut werden kommt man vermutlich locker auf 40-50 Distributionen. Eher mehr.

      „Und da gibt es dann meist auch doch substanzielle Unterschiede, sei es der Fokus auf möglichst 100% OpenSource, auf Sicherheit, auf lange Supportzeiträume und eine stabile Basis für Server oder möglichst aktuelle Software und testen von neuen Funktionen.“

      Das ist die Frage. RHEL und SLE haben Zertifizierungen, das hebt sie sicher ab, aber sonst. Was unterscheidet Ubuntu von Debian, openSUSE von Ubuntu oder Mageia? Das könnte man jetzt endlos so weiter machen.

      Ich will niemandem sein Spielzeug wegnehmen. Das gleich vorweg, bevor hier wieder jemand in diese Richtung denkt. Ich behaupte nur die „Spielzeuge“ sind gänzlich austauschbar und verhalten sich alle so ähnlich, dass es längst ein Linux OS gibt. Der ganze Distributions-Dschungel ist nur noch Folklore für die Community und erinnert an frühere – vermeintlich bessere – Zeiten.

  3. Ein entscheidender Faktor ist für mich immer noch die Stabilität: wenn man jahrelang Debian im Rechenzentrum genutzt hat, und im Rahmen von „Modernisierungsmaßnahmen“ plötzlich gezwungen wird neue Systeme mit Ubuntu aufzusetzen im Rechenzentrum, fällt der Unterschied zwischen „gut abgehangen und stabil“ gegenüber „modern, aber weder stabil noch sauber portierte Fixes“ doch ganz deutlich ins Gewicht. Ähnliche Werkzeuge zur Systemverwaltung, aber massive Unterschiede im Betrieb. Weil es bei Debian vermeintlich keinen Support gibt wird man gezwungen auf Ubuntu zu wechseln. D.h. ein System wo der vermeintlich nicht existierende Support nicht nötig war wird durch eines wo man den vermeintlich existierenden Support regelmäßig braucht ersetzt. Natürlich klingt das hart, und ist vielleicht auch etwas unfair, aber die Möglichkeit zwischen modernem hippen Kram und Langlebigkeit wie ägyptischen Pyramiden zu wählen möchte ich nicht mehr missen.

      • Es ist nur Erfahrung aus Nachtschicht, Wochenendarbeit, und dem manuellen einspielen von Debian Paketen unter Ubuntu, um den Produktivbetrieb wie herstellen zu können. Wissenschaftliche Evaluierung war leider aufgrund der Dringlichkeit dieser Ausfälle bislang nicht wirklich möglich (geschweige denn, dass diese im Projektmanagement auf Gegenliebe stoßen würde, da die Ausfälle Zeitplanung und Budget sowieso schon gesprengt haben, und „wer braucht so einen akademischen ***“ um ein Zitat aus der Praxis zubringen…. 🙁 )

        • Warum gleich so persönliche angegriffen? Man muss nicht gleich „wissenschaftlich“ arbeiten um ein Problem sauber zu prüfen. Es sei denn man ist natürlich der Typ „trial-and-error“-Admin. Alleine schon wenn ich lese, dass du Debian-Pakete in Ubuntu eingespielt hast…

          Wenn man so ein Problem hat, prüft man doch wenigstens ob das Problem in irgendwelchen Ubuntu-Spezifika (Konfigurationsdetails, schlechte QS bei Updates etc. pp.) bestand oder vielleicht nur eine ungünstige Verkettung von Umständen war.

          So sind wir nur wieder bei Folklore und Identitätsbildung. Das ist das gleiche Niveau wenn unter irgendwelchen Heise-Artikeln zu openSUSE Leute auftauchen und von überschriebenen Konfigurationsdateien im letzten Jahrtausend schreiben.

          • Sorry wenn das nach persönlich angegriffen klingt.
            Trial and Error ist bei uns nicht das Vorgehen das wir normal nutzen. Die Konfiguration haben wir vor solchen Maßnahmen immer als Team untersucht. Der letzte Fall war derart gelagert, dass es ein Fehler im Ubuntu Paket war (upstream bereits gefixt für die Apache Version, im Debian Paket gefixed, im Ubuntu Paket als Regression wieder drin). Reproduzierbar war das Verhalten durch manuelles kompilieren ebenfalls.

Schreiben Sie eine Ergänzung

Ergänzungen dienen der Diskussion über die Inhalte des Artikels. Nachfragen, Anmerkungen und Ergänzungen sind dezidiert erwünscht. Ergänzungen werden vor der Veröffentlichung moderiert. Wir behalten uns vor Kommentare ohne inhaltlichen Bezug oder abseitige Diskussionen nicht zu veröffentlichen.

Bitte geben Sie Ihre Ergänzung ein!
Bitte geben Sie hier Ihren Namen ein