Distributionen als Scharnier – Eine Rolle, die auch gefüllt werden will

Linux-Distributionen sind etwas fast einzigartiges. Bei keinem anderen Betriebssystem schieben sich zwischen Endanwender und Entwickler so zahlreiche und gleichzeitig mächtige Zwischenhändler. Kritik an diesem System wird von Verteidigern oft begegnet mit dem Einwand, die Distributionen würden einen wichtigen Prüfauftrag erfüllen. Wirklich?

Natürlich kann es bei Linux nicht wie bei macOS oder Windows lediglich einen Anbieter geben, der gleichermaßen Entwickler wie Verteiler ist, wobei auch andere freie Software wie z. B. die diversen BSD andere Systeme etabliert haben. Die Situation mit zahlreichen Distributoren, die alles vom Kernel bis zum Browser kontrollieren und im Extremfall in ein eigenes Betriebssystem „branden“ ist einzigartig. Es ist zudem nicht nur einzigartig, sondern auch umstritten und bereits seit vielen Jahren Ziel der Kritik, nicht zuletzt von den eigenen Softwareentwicklern, die den Distributoren vorwerfen, ein zu enger Flaschenhals im System zu sein.

Der vielfältigen Kritik begegnen die Distributoren und ihre Unterstützer mit dem umfassenden „Auftrag“ der Distribution. Dem Selbstverständnis nach bilden sie das Scharnier, das Entwickler und Endanwender verbindet und die unterschiedlichen Bedarfe vermittelt. In der Theorie prüfen die Distributoren schließlich den von den Entwicklern (Upstream) stammenden Code, verpacken ihn und stimmen die einzelnen Bestandteile des modularen Linux-Ökosystems aufeinander ab, verändern den von Upstream stammenden Code meist noch durch verschiedene Patches, ergänzen zudem noch eigene Tools und liefern es an den Endnutzer aus. Hinzu kommen ggf. weitere Prüfaufträge wie bei Debian z. B. die Konformität zu den DFSG.

In der Praxis können die Distributoren diesem Auftrag eigentlich nicht wirklich gerecht werden und sie tun es faktisch auch nicht. Dazu reicht Logik und Beobachtung.

Beginnen wir bei der Logik. Wir sind nicht mehr im Jahr 1995. Anfang der 1990er enthielt selbst der Linux-Kernel „nur“ einige Tausend Teilen Code. Heute sind es Millionen und von einer Version zur nächsten ändern sich gut und gerne mal Hunderttausende Zeilen. Der Kernel ist ein extremes Beispiel, aber große und wichtige Softwareprojekte wie systemd, Firefox oder die großen Desktopumgebungen sind da nicht viel besser. Die Schlagzahl ist bei nahezu allen Softwareprojekten rasant gestiegen. Die Zeiten, wo es mehrere Jahre infolge höchstens Minorversionen gab, sind schon lange vorüber. Heute kommen wichtige Veröffentlichungen gerne im Monatstakt. Ebenso gestiegen ist die Erwartungshaltung der Anwender. Nicht nur bei Rolling Release-Distributionen soll bestenfalls am Release-Tag die neue Version verfügbar sein, auch bei stabilen Varianten gibt es Backports und alle 1-2 Jahre neue Funktionsreleases. Gleichzeitig ist die Zahl derjenigen, die sich als Entwickler an den Distributionen beteiligen, tendenziell eher rückläufig. Eine nicht anlassbezogene und systematische Prüfung des kompletten Paketbestandes ist faktisch unmöglich.

Es scheitert aber nicht nur am „Mengenproblem“, sondern auch am Willen, den Prüfauftrag konsequent zu erfüllen. Das kann man seit vielen Jahren beobachten. Dazu gehört nämlich auch die Bereitschaft, qualitativ schlechte Software nicht an den Anwender auszuliefern, selbst wenn dadurch Lücken im Portfolio entstehen. Vorgänge, wie man sie z. B. im openSUSE Bugzilla am Beispiel des KDE Partition Manager / kpmcore nachlesen kann, wo wegen massiver Mängel Versionen zurückgehalten und Upstream Änderungen eingefordert werden, sind meiner Beobachtung nach extrem selten. Das kann man beispielsweise auch daran sehen, wie viele Distributionen immer noch bedenkenlos encfs ausliefern, obwohl das seit bald einem Jahrzehnt als gebrochen gilt oder ihre Anwender dem gefährliche Fingerprint-Authentfizierungssystem fprint aussetzen.

Innerhalb der Distributionen können weiterhin auch Inkonsistenzen vorherrschen. So entfernt Debian bei Firefox zahlreiche Telemetriefunktionen von Mozilla, verändert aber z. B. Chromium nicht. Es gibt somit keine konsistente Anti-Tracking-Policy, sondern es hängt an der Meinung des Maintainers und seiner Bereitschaft, etwas zu tun.

Dieser Zustand ist auch ein Grund weshalb ich neuen Softwareverteilungsformen offen gegenüberstehe und davor warne das alles überragende Distributorenmodell des Linux Server/Desktop-Ökosystems, das sich letztlich nur aus den Pfadabhängigkeit in der Entwicklung von Infrastruktur erklären lässt, auch auf moderne Bereiche wie mobile Systeme zu übertragen. Leider passiert momentan genau das. Weshalb wir für eine Handvoll Hardware zig Distributionen haben, die alle den gleichen nicht-alltagstauglichen Zustand paketieren, sich gegenseitig kannibalisieren und Geld kosten, das anderswo besser investiert wäre. Oder weshalb neue Konzepte wie Flatpak verunstaltet werden, bis alle sie alle Kennzeichen der bisherigen Distributorenlogik auch erfüllen und ihre Vorteile einbüßen, siehe Fedoras eigene Flatpak-Quelle. Da kommt halt ein weiterer Teil von Infrastrukturlogik zum Tragen: Das System versucht sich krampfhaft selbst zu erhalten und bremst die Entwicklung bis zur Blockade, weil bei neu aufkommender Infrastruktur Verlierer entstehen

Kurzum, die Distributionen erliegen an der Aufgabe, sind größtenteils auch nicht bereit, ihre selbst zugeschriebene Rolle konsequent zu erfüllen und dort, wo sie es tun, erledigen sie es inkonsequent. Die Position als verbindendes Scharnier zwischen Entwickler und Anwender und ihre Bedeutung sollte man also nicht zu hoch hängen. Viele Upstream-Projekte sind heute so professionell, dass sie durchaus ihre Software direkt auf den Anwender loslassen könnten, ohne dass es zu einem allgemeinen Qualitätsverfall kommen würde. Nichtsdestotrotz werden uns Distributionen in der aktuellen Form wohl erhalten bleiben, weil zu viele von dem System profitieren, die ansonsten keine Rolle spielen würden.

4 Kommentare

  1. Mir scheint, der Satz ist unvollständig: „Gleichzeitig ist die Zahl derjenigen, die sich als Entwickler an den Distributionen beteiligen.“ Fehlt da ein „gesunken“ oder ein „in etwa gleich geblieben“? Oder ein „lang nicht so stark angestiegen“?

  2. Ich fange mal am Ende (oder Anfang) an. Als Endanwender möchte ich ein funktionierendes System auf meinen Rechner nutzen. Ob das nun Windows, MacOS oder Linux oder was auch immer ist. Dazu will ich Anwendungen nutzen. Ich will gerne das System auch auf aktuellen Stand halten. Ob das nun eine neue Anwendungen ist, ein Funktionsupdate oder ein Sicherheitsupdate. Das möglichst über eine zentrale Stelle. Also derzeit Linux Like über die Repository. Alternativ nutze ich die anderen Möglichkeiten, wie Flatpack, Appimage, usw. Wenn ich wieder an mehreren Stellschrauben drehen muss um mein System auf aktuellen Stand zu bringen werde ich mal eine Stellschraube vergessen. Oder drei von vier Stellschrauben haben ein Update bereit gestellt. Der oder die vierte kommen nicht in die Gänge.

    So, welche Weg gibt es um mir als Anwender es möglichst einfach zu machen und es anderseits Entwicklern von z.b EncFS und fprint zu ermöglichen gute Software abzuliefern.
    Obwohl ich nicht davon überzeugt bin wenn Software auf direkten Weg vom Entwickler zum Anwender kommt besser wird.
    War wäre denn für dich ein Weg Software zu verteilen?

    • Den Desktop- und Serverbereich habe ich aufgegeben. Mir würde es schon genügen, wenn sich diese überholte Infrastruktur nicht neue Felder wie die mobilen Systeme suchen würde und uns dort dieselben Probleme beschert.

Kommentarfunktion ist geschlossen.

Mehr aus dem Blog

Ubuntu – Zurückgehaltene Pakete und „Phased Updates“

In letzter Zeit gibt es mehr Berichte über Probleme mit zurückgehaltenen Paketen bei Ubuntu. Dahinter stecken aber meist gar keine zu lösenden Probleme, sondern...

(K)Ubuntu 22.04 – Eine kleine persönliche Bilanz

Eigentlich wollte ich Kubuntu 22.04 dieses Frühjahr gegen openSUSE austauschen. Das habe ich dann doch nicht gemacht, weil ich die betroffenen Anwender nicht kurz...

TrackerControl für Android – Apps im Blick behalten

Open Source Apps von F-Droid oder anderen Repositorien sind meist vertrauenswürdig, aber die wenigsten kommen gänzlich ohne proprietäre Apps aus. Hier hat man gerne...

Staubsaugerroboter – Abwägungsfragen im Datenschutz

Ich wollte einen Staubsaugerroboter. Meine Wohnung ist zu groß, ich betrachte Putzen nicht als Hobby und der Boden ist ideal für einen Staubsaugerroboter geeignet....