Windows kommt von Microsoft, macOS von Apple. Linux kommt von Debian, Ubuntu, Red Hat, SUSE oder weiteren hundert Anbietern. Ein kaum hinterfragter Umstand aber steckt dahinter nicht ein vollkommen überholtes Strukturelement der Softwareverteilung?
Der Artikel ist indirekt eine Weiterentwicklung des ersten Artikels der Serie. Es ist der Ansatz die Distribution als grundlegende Infrastruktur mit den systemimmanenten Eigenlogiken von Infrastruktur zu begreifen.
Grundlegende Entscheidungen
Linux wird über Distributionen an den Endverbraucher verteilt. Dieser Umstand ist für neue Nutzer immer etwas gewöhnungsbedürftig und wird von langjährigen Anwendern kaum hinterfragt. Das Ganze geht sogar so weit, dass die Verweise mancher Distribution auf die Marke Linux marginal sind. Man kann dazu beispielsweise mal nach dem Wort Linux auf der Ubuntu-Webpräsenz suchen.
Sind Distributionen noch notwendige Infrastruktur für die Software-Verteilung oder sind sie überkommene Strukturmerkmale, die sich nur noch historisch erklären lassen und heute primär Community-Folklore darstellen.
In dem Zusammenhang möchte ich auf den älteren Artikel Understanding Infrastructure verweisen, der einige Kernelemente allgemeiner Infrastruktur-Entwicklung erklärt, die hier zumindest mittelbar mit einbezogen sind. Dazu gehören vor allem folgende Punkte:
- Entscheidungen führen zu Pfadabhängigkeiten, woraus sich Entwicklungen eigener Logik ergeben.
- Hinterherhinkende Entwicklungen einzelner Bereiche können die Fortschrittsgeschwindigkeit des gesamten Systems beeinträchtigen.
- Neue Infrastrukturen werden immer in bestehende Systeme eingebunden.
- Neu aufkommende Infrastruktur und Veränderungen erzeugen Gewinner und Verlierer, weil sie u.a. zu Ressourcenumverteilung führt.
Linux in Form von Distributionen zu verteilen ist kein unumstößliches Gesetz, sondern ergab sich vor allem aus den Anforderungen der 1990er-Jahre. Wenn man sich mit den Anfängen von Linux-Distributionen befasst, landet man ziemlich schnell beim Debian-Manifest, das Ian Murdock 1994 verfasste. Schlicht, weil Debian eine der ältesten noch aktiv entwickelten Distributionen ist. Er schreibt, wozu man Distributionen braucht:
Distributionen sind essenziell für die Zukunft von Linux. Sie ersparen dem Benutzer den Aufwand, eine große Anzahl von grundlegenden Werkzeugen ausfindig zu machen, herunter zu laden, zu installieren und zu einem funktionierenden Linux-Systems zu integrieren. Die Bürde der Systemzusammenstellung wird auf den Distributions-Ersteller übertragen, dessen Arbeit von tausenden anderen Nutzern mitbenutzt werden kann. Fast alle Linux-Benutzer werden ihre erste Erfahrung durch eine Distribution machen, und die meisten Nutzer werden die Distribution aus Bequemlichkeit weiter nutzen, auch wenn sie mit dem Betriebssystem vertraut sind. Daher spielen Distributionen wirklich eine wichtige Rolle.
Anhang A. Das Debian-Manifest
Es gibt eben das Windows und das macOS, aber eben nicht das Linux. Denn Linux ist eine Zusammenstellung freier Software. Vom Kernel über viele GNU-Userspace-Werkzeuge bis hin zu Grafikstack, Desktopumgebung und Programmen. Linux-Distributionen stellen hier eine funktionierende Komposition zusammen und verteilen diese.
Das bedeutete lange Zeit eine weitere Hürde, denn schnelles Internet und Online-Updates waren lange Zeit undenkbare Distributionssysteme. Der Verteilung widmet Murdock deshalb ein paar weitere Passagen:
Debian Linux wird von der Free Software Foundation und der Debian Linux Association auch auf physischen Medien vertrieben werden. Damit ist Debian auch für Benutzer ohne Zugang zum Internet oder FTP erhältlich und ermöglicht das Angebot zusätzlicher Produkte und Dienstleistungen wie gedruckter Handbücher und technischer Unterstützung für alle Benutzer des Systems. Auf diese Art kann Debian von mehr Menschen und Organisationen benutzt werden als es anders möglich wäre.
Anhang A. Das Debian-Manifest
Diese grundlegende Entscheidung zur Distribution von freier Software hatte Folgewirkungen. Ziemlich schnell erhielten die meisten frühen Distributionen Paketierungswerkzeuge und ausgereifte Paketverwaltungen. Weil Linux keine monolithische Einheit war, sondern aus unterschiedlichen freien Softwareprodukten bestand, machte es Sinn, diese als Pakete installieren und aktualisieren zu können. Andere freie Systeme wie FreeBSD zeigen aber, dass dies keine Gesetzmäßigkeit ist.
Damit haben wir schon zwei grundlegende Strukturmerkmale. Die Distribution als zentrale Verteilungsinstanz mit einem definierten Qualitätsverständnis und Entwicklungssystem sowie die Paketorganisation zur Verwaltung von Software.
Speicherplatz war knapp und die Bandbreite im inzwischen zur Softwareverteilung etablierten Internet ebenso. Im Gegensatz zu Windows und macOS nutzten nahezu alle Linux-Distributionen die Paketverwaltung, um Software in einzelne Binärpakete zu zerlegen und Fehlerbehebungen und Sicherheitsaktualisierungen genau dort vorzunehmen, wo auch das Problem lag. Idealerweise sollte keine Bibliothek zwei Mal im System vorkommen und ein Update beschränkte sich auf die dafür notwendigen Paketaktualisierungen.
Das System produzierte Gewinner und Verlierer. Die eigentlichen Entwickler der Software blieben für den Anwender unsichtbar, die Distributoren aber sehr sichtbar. Aus Sicht vieler Anwender standen sie – und nicht die Entwickler – für die Qualität der Software. Diese zahlte sich in der öffentlichen Wahrnehmung aus, in der Distributoren eine herausragende Rolle einnahmen. Das schlug sich auch monetär nieder. Distributionen generierten Einnahmen, während Entwicklungsprojekte oft kaum Spenden erhielten. Anwendergemeinschaften formierten sich deshalb primär um die Distributionen und nicht um die Softwareprojekte.
Auflösungserscheinungen
Seit den Anfängen sind nun bald 30 Jahre vergangen. Speicherplatz und Internetbandbreite sind nicht mehr der Flaschenhals, der sie mal waren. Viele Entwickler von Endanwender-Software sind dazu übergegangen, selbst Binärpakete ihrer Software für die verschiedenen Distributionen anzubieten. Gleichzeitig beschäftigten kommerziell erfolgreiche Distributoren Entwickler für ihre Arbeit an Softwareprojekten.
Parallel ist die Zahl der Distributionen exponentiell gewachsen. Denn der Betrieb einer Distributionsinfrastruktur ist nicht mehr mit dem Aufwand und den Kosten verbunden, die noch vor 20-30 Jahren dafür notwendig waren. Murdock wollte eine Lücke schließen, als er mit Debian eine umfassende Distribution erschuf. Bei heutigen Neugründungen scheint hingegen die einzige zu schließende Lücke im Ego der Entwickler zu liegen.
Weil Infrastrukturen ihr Eigenleben haben und einmal getroffene Entscheidungen, Entwicklungen eigener Logiken nach sich ziehen, versuchen die meisten Distributionen heute alles zu sein und zu bieten. Sie bieten alle verfügbare Software und viele auch noch parallele Entwicklungszweige. LTS, RR, jede Desktopumgebung – alles unter einem Dach. Nur eine Minderheit der Distributionen hat sich wirklich auf einen Aspekt oder Schwerpunkt spezialisiert. Anstelle das Potenzial, das Distributionen als Konzept bieten, auszuschöpfen, bieten alle alles und führen damit nur zu einer gewaltigen Vergrößerung des Arbeitsaufwands.
Andere ursprüngliche Vorteile verlieren an Bedeutung. Automatisierte Buildsysteme und Verflechtungen führen zu Veränderungen im Softwareverteilprozess. Software-Verteilung ist nicht mehr so kompliziert wie um die Jahrtausendwende. Updates und Patches führen in der Praxis oft zu Aktualisierungen ganzer Paketgruppen. Der einzelne Patch für ein einzelnes Paket ist inzwischen mehr Ideal denn Realität. Immer komplexere Software führt zudem zu immer mehr Paketen ohne gemeinsamen Nenner. Eine lediglich durch ein einziges Programm benötigte Bibliothek kann aus Benutzersicht auch gleich mit dem Programm zusammen ausgeliefert werden. Die Paketverwaltung als ausgeklügeltes System der Softwareverteilung ist zwar immer noch eine Eigenheit der Linux-Welt, ihre Vorteile verlieren jedoch an Bedeutung, während alternative Konzepte wie App Stores als zentrale Verteil-Mechanismen auf anderen Systemen entstehen.
Durch die internalisierten Logiken bei der Infrastrukturbildung führen Designentscheidungen aus früheren Zeiten zu nicht intendierten Folgen in der Gegenwart. Paketverwaltung, verteilte Bibliotheken und Verflechtungen erlauben eigentlich nur zwei Modelle der Linux-Distribution. Rollende Veröffentlichungen aller Pakete und stabile Releases. Ein Gegensatz, den die Akteure im System so verinnerlicht haben, dass sie den Sinn kaum noch hinterfragen.
Der Kuratierungsaufwand nimmt dabei tendenziell ab. Die stetig weiter wachsende Zahl von Distributionen mit kleinen Teams legen davon Zeugnis ab. Auch Eigenentwicklungen der Distributionen sind zugunsten übergreifender Lösungen auf dem Rückzug. Als Beispiel kann hier die Installationsroutine Calamares herhalten. Distributionen wie Arch Linux beweisen, dass man sehr erfolgreich einfach Software so paketieren kann, wie man sie von upstream bekommt und die Releases vieler Distributionen sind eher eine Sammlung dessen, was zum anvisierten Releasezeitpunkt “auf der Straße lag”.
Gleichzeitig wächst auch innerhalb der Open Source Gemeinschaft die Kritik am Flaschenhals Distribution. Als Konsequenz werfen große Entwicklerprojekte wie KDE oder GNOME ihre eigenen Zusammenstellungen auf den Markt, während Distributoren Canonical und Red Hat der Kritik durch Veränderungen in der Software-Distriution mittels Snap und Flatpak begegnen wollen und neue distributionsübergreifende Verteilmechanismen für Software einführen.
Ausbreitung des Systems?
Die Distribution als Verteilmodell für den Desktop und Server ist durch grundlegende Entscheidungen und die selbst erhaltende Logik einer Infrastruktur nicht zu ändern und wird der Geräteklasse treu bleiben. Die Erkenntnis, dass das System kaputt ist bzw. mindestens einige Fehlentwicklungen vollzogen hat, ist nicht neu. Den Fehler sieht man aber immer bei “den Anderen”. Kein Projekt stellt sich selbst ein.
Die Distribution als wesentliches Strukturmerkmal wird Linux auf dem Desktop erhalten bleiben. Das gilt ebenso für die Paketverwaltung als zentrales Instrument zur Softwareorganisation. Neue Systeme wie Flatpaks und Snaps werden an die bestehende Infrastruktur angebunden und ersetzen diese nicht.
Das System mit seinen vielen Widersprüchen, Unzulänglichkeiten und der massiven Verschwendung von Arbeitskraft auf neue Geräteklassen zu übertragen, wäre aber fatal. Die Rahmenbedingungen sind heute gänzlich andere und dem sollte man auch Rechnung tragen.
“Bei heutigen Neugründungen scheint hingegen die einzige zu schließende Lücke im Ego der Entwickler zu liegen.”
Das würde ich so jetzt nicht stehen lassen wollen, ich befürworte es auch, lieber einem bestehendem Projekt beizusteuern statt etwas neues anzufangen, was eigentlich das gleiche Ziel verfolt, aber es gibt trotzdem gute Gründe warum man das trotzdem tun sollte.
Ich habe beispielsweise jetzt einem bestehendem Projekt sehr viel Code beigesteuert, bin jetzt aber bei der Situation angelengt, das ich unzufrieden bin weil ich den Code schwer lesbar finde und zudem habe ich eine Idee wie man es besser machen könnte, aber dafür wäre ein kompletter Rewrite notwendig. Was mache ich also jetzt? Soll ich alles komplett umschreiben und ein Pull Request machen? Dann ist die komplette Software eigentlich von mir und ich würde ein bestehendes damit komplett ersetzen? Ich würde aber auch gerne Pull Requests anderer annehmen können und einen besseren Namen für die Software habe ich auch. Da macht es wohl Sinn es unter meinem eigenen Repositiry zu machen.
Ist damit jetzt bereits genau das passiert? Statt Kräfte zu bündeln würde ich mein eigenes Ding machen. Aber möglicherweise ja auch zu einem Mehrwert, wenn die Software dadurch das Ziel besser erreicht. Ich könnte immerhin viel von dem anderen Projekt lernen aber glaube es jetzt besser zu können.
Das kann bei Distributionen doch so ähnlich sein. Jemand hat die Idee für ein neues grundlegendes Paketformat aber keine Distribution ist von der Idee überzeugt oder will weiter an ihrer Festhalten. Dann wäre es es doch legitim eine neue Distribution zu erstellen, die genau dieses Prinzip ausprobiert. Und dann stellt sich möglicherweise heraus, dass dieses Konzept tatsächlich besser funktioniert und viele Probleme löst. Was wäre hier die Lösung? Wie würde man in diesem Fall eine neue weitere Distribution vermeiden? Und ist es überhaupt sinnvoll das zu vermeiden? Hätte sich dann überhaupt herausgestellt, dass dieses neue Konzept so viel besser funktioniert?
Wie ist das denn mit den drei großen Betriebssystemen Windows, Mac und Linux? Letztendlich sind das doch auch 3 Betriebssysteme mit einem grundlegend ähnlichem Ziel aber unterschiedlichen Schwerpunkten. Sollte man deren Kräfte auch bündeln? Statt der Distributionen gäbe nur noch des Betriebssystem. Die Frage ist wo hört man auf und wir fängt man an?
Klar, nur noch ein Paketformat wäre toll, dann muss die Software nicht für tausend andere Formate gebündelt werden.
Wie sieht es mit Qt und Gtk aus? Qt war vor Gtk da, aber Qt war damals keine freie Software und will auch jetzt die neusten Versionen erst einmal nur an zahlende Kunden ausliefern. Hätte nes Gtk bei DER Linux Distribution jemals gegeben?
Wer entscheidet bei der universellen Linux-Distribution über das Look and Feel? Welches Design Ziel wird verfolgt? Wie schafft man es, dass sich alle über den richtigen Weg einig sind? Hast du dafür konkrete Vorschläge? Sollte eine Struktur ähnlich wie in einer Firma geschaffen werden?
Klar bei Windows und Mac entscheidet halt einfach der Hersteller über das Ziel und alle ziehen mit weil sie dafür bezahlt werden. Ab r nicht unbedingt weil sie auch hinter allen Entscheidungen selbst stehen.
Danke für den Artikel und den sehr interessanten Denkansatz
Nur um das Klarzustellen: Ich bin nicht grundsätzlich gegen neue Projekte oder Forks. Mir fallen viele gute Gründe ein so etwas zu machen und es gibt – um beim Beispiel Distribution zu bleiben – natürlich einen Mehrwert durch Spezialisierung.
Aber treffen diese Kriterien wirklich auf die meisten heutigen Neugründungen/Abspaltungen zu? Würde unter heutigen Vorzeichen überhaupt noch ein so großes kollaboratives Projekt wie Debian entstehen?
In dem Punkt stimme ich dir wiederum zu. Man sehe sich nur mal die ganzen Ubuntu-Forks an. Warum nicht einfach ein Metapackage anbieten welches eine gewisse Vorkonfiguration vornimmt, meinetwegen auch gerne ein vorgebautes ISO-Image um es sich direkt installieren zu können aber warum muss man daraus immer gleich eine ganze Distribution mit eigenem Namen und Logo machen? Der Nautilus Fork von Distribution XY könnte doch vllt auch für andere interessant sein oder besser lieber gleich das original verbessern. Die ganzen GNOME Forks zum Beispiel, die wenigsten wissen, dass es ein Classic-Mode offiziell von GNOME 3 gibt (bin nicht sicher ob der noch offiziell gepflegt wird oder was damit nach GNOME 40 passiert), welche das alte aussehen von GNOME 2 nach ahmt aber auf die aktuellen Technologien von GNOME 3 aufbaut. Man hätte also auch einfach helfen können den Classic-Modus weiter zu verbessern.
Vllt wäre auch ein Iso-Image Generator eine Möglichkeit. Dort könnte man die voreingestellte Oberfläche, Sprache, vorinstallierte Programme etc auswählen und bekommt dann ein individuelles Image. Am besten direkt immer mit den letzten Sicherheits-updates. Alles unter dem Namen einer Distribution und nicht für jede Desktop-Oberfläche mit seperaten Namen. Gibt es etwas vergleichbares vllt sogar schon? Ich erinnere mich das es Mal ein Tool gab mit dem man sich auf ähnliche Weise seine eigene Distribution bauen konnte
OpenSUSE hatte das soweit ich weiß. Ich habe das aber nie probiert und kenne den Status nicht.