Debian hat einige Probleme und es entsteht der Eindruck, dass das Projekt nicht willens oder nicht fähig ist, auf diese Probleme angemessen zu reagieren. Ein paar Nachträge zum letzten Blogartikel.
Kürzlich hatte ich über Debians Probleme mit Firefox berichtet und das zum Anlass für eine relativ pauschale Kritik genommen. Das war vermutlich ein wenig verkürzt, deshalb möchte ich hier einen zweiten Teil hinterher schieben.
Zustandsbeschreibung
Debian hat ein Problem mit der Sicherheit seiner Distribution. Das ist nicht erst seit den Problemen mit Firefox so. Chromium hat man schon vor Längerem aufgegeben und viele andere Pakete auch – aber ohne sie aus der Distribution zu entfernen. Es ist sowieso schon erstaunlich, wie lange dieser Missstand unkommentiert hingenommen wurde. Wer also darauf vertraut, dass alles, was er über die Paketquellen installiert, sicher ist, der irrt. Meiner Meinung nach kann es nicht der Anspruch an den Anwender sein, dass er bei jedem Programm erst mal eine intensive Zustandsprüfung vornehmen muss.
Vermutlich sind die bekannten Probleme rund um die Browser nur die Spitze des Eisbergs. Die Debian-Paketquellen sind, was ihren Umfang betrifft, unerreicht im Linux-Universum. Bereits seit Längerem mutmaßen viele, dass es durch Debians Updatepolitik Probleme z. B. im Qt-Stack geben könnte, weil man hier bewusst nicht auf LTS-Varianten gesetzt hat und Updates nicht einfach weiterreicht. Die Probleme betreffen aber nicht nur den Desktop. Debian liefert auch viele Serveranwendungen aus. Enthalten z. B. die Versionen von WordPress in Stable (5.7.1) oder Oldstable (5.0.14) wirklich alle danach erfolgten Sicherheitspatches? Zweifel sind wohl erlaubt.
Auf Veränderungen nicht reagiert
Debians Richtlinien zur Softwarepaketierung haben sich seit vermutlich 20 Jahren kaum grundsätzlich verändert. Im Laufe einer Testingphase werden Pakete in die Quellen aufgenommen und während des Freeze stabilisiert. Danach gilt das Primat der Versionsstabilität und es sind lediglich Patches erlaubt, die einzelne Probleme adressieren. Meist sind diese sicherheitsrelevant, es können aber auch ordinäre Bugs auf diese Weise behoben werden, wenn sie gravierend genug sind.
Die Softwareentwicklung hat sich in den letzten 20 Jahren aber verändert. Es gibt nicht mehr alle paar Jahre eine neue Programmversion, sondern die Zyklen umfassen meist nur wenige Monate oder gar Wochen. Manche Software gibt es gar nur noch als sogenannten Entwicklungsschnappschuss. Die Upstream-Entwicklung ist durch das Tempo der Entwicklung nicht unbedingt besser dokumentiert. Welche Änderungen genau vorgenommen wurden, was welche Probleme behebt und was sicherheitsrelevant ist, bleibt oft intransparent. Selbst KDE ist mit wirklicher LTS-Pflege überfordert, wie Nate Graham kürzlich schrieb. Ich bin sicherlich der Letzte, der das gut findet, mein Faible für LTS-Versionen habe ich schon oft erklärt, aber es ist die Realität, mit der alle im Linux-Umfeld arbeiten müssen.
Um hier wenigstens die sicherheitsrelevanten Probleme zu adressieren und in die Debian-Versionsstände zurück zu portieren, braucht es viel Zeit und die notwendigen Fähigkeiten. Hier kann man die Debian-Paketquellen sicher nicht über einen Kamm scheren. Manche Maintainer haben mehr Zeit oder werden sogar dafür bezahlt, andere machen es nur in ihrer Freizeit. Manche Upstream-Projekte lassen sich auch leichter pflegen als andere. In der Summe hat Debian aber Probleme genug aktive Paketbetreuer mit den notwendigen Fähigkeiten zu gewinnen. Das ist eine alles andere als geheime oder neue Erkenntnis.
Debian ist nicht alleine
Das Problem betrifft nicht nur Debian, sondern alle stabilen Distributionen, denn im Gegensatz zu Rolling Release-Distributionen, können sie nicht einfach die Upstream-Versionen durchreichen. Besonders betroffen sind jene Distributionen mit besonders langen Supportversprechen, was gemeinhin mit LTS oder Enterprise umschrieben wird und bei Debian einfach Stable heißt.
Ubuntu hat deshalb schon immer sein Supportversprechen auf den Teil der Pakete in main beschränkt. Inzwischen arbeitet man an einer Kooperation mit Mozilla, um die aufwendige Firefox-Pflege an die eigentlichen Entwickler auszulagern. Das hat sicher andere Probleme zur Folge, aber es ist der Versuch ein Problem zu lösen, vor dem die Distrubution steht. Möglicherweise steuert man hier auch noch mal nach, Irrtümer und Lernprozesse sind schließlich erlaubt.
Jenseits der Debian-Abkömmlinge ist man im LTS-Segment andere Wege gegangen. Das finanzstarke Red Hat unterstützt für sein RHEL nur einen einzigen Desktop und einen kleinen Paketpool für den Desktop. Das openSUSE-Projekt hat für seine stabile Variante die Kooperation mit SUSE gesucht und pflegt nur noch die Differenz zwischen SUSE Linux Enterprise und openSUSE Leap, also jene Pakete, die nur in openSUSE und nicht in SLE enthalten sind.
Alle hier genannten Distributionen sind dabei weniger dogmatisch. Vielen Debian-Nutzern ist das nicht bewusst, weil sie selten über den Tellerrand schauen, aber Paketupdates bedeuten nicht gleich den Zusammenbruch des Systems.
Bei SLE/openSUSE Leap werden durchaus in einem gewissen Rahmen Updates vorgenommen, wenn der Nutzen das Risiko übersteigt. So hat man z. B. Samba von 4.13.4 auf 4.13.13 angehoben oder systemd von 246.13 auf 246.16. Nur um ein paar Kernbeispiele zu zeigen. Ein mal pro Jahr macht man mit den Servicepacks (SLE) bzw. Minorversinen (RHEL, openSUSE Leap) sogar noch größere Sprünge, um das Qualitätsversprechen zu erfüllen.
RHEL und SLE sind und bleiben trotzdem Enterprise-Distributionen, für die viele Unternehmen erhebliche Beträge bezahlen. Warum klappt dort, was Debian partout nicht machen möchte?
Nichts tun ist keine Lösung
Es gibt kein Patentrezept, aber nichts tun ist keine Lösung für eine renommierte Distribution mit dem Selbstanspruch, eine sichere und stabile Basis für die Anwender bereitzustellen.
Für Außenstehende entsteht manchmal der Eindruck, dass bei Debian mehr um ideologische Fragen wie systemd gestritten wird als um wirklich kritische Sachverhalte.
Das Problem in den Release Notes zu verstecken, wie man es jahrelang mit den Browsern machte, keine Kommunikation wie bei Firefox aufzunehmen und einfach weiter zu machen – das kann aber nicht die Lösung sein. Vermutlich wird aber exakt das passieren.
Ein Teilaspekt des Problems ist aber auch die Namensgebung der Zweige stable, testing und unstable.
Würde Debian stable in “core” oder “base” umbenennen und mit reduzierter Paketauswahl ausliefern, wäre da viel gewonnen. Ähnlich wie bei RHEL, aber tatsächlich mit gar keinem Desktop Environment. Dazu diese Distribution dann als LTS- und Server-Ding platzieren.
Dazu dann noch die Namen “testing” und “unstable” in das ändern, was sie wirklich sind: “slow rolling” und “bleeding edge”. Meinetwegen noch Update Packs, ähnlich wie Ubuntus Point Releases dazu. Hier fällt mir adhoc kein passender Name ein – aber ich denke, meine Denkrichtung wird schon klar.
Damit würde nicht mehr ein völlig falsches Versprechen transportiert werden bzw. keine entsprechende Erwartungen impliziert.
Ja, das wäre ebenfalls eine Lösung.
Ich denke es ist oben hinreichend deutlich geworden, dass ich nicht behaupte sagen zu können, dies oder jenes sei der Weg für Debian. Aber so müssen irgendetwas tun, ansonsten verlieren sie das Vertrauen. Und hier nicht nur meines, die Berichterstattung über das Firefox-Problem ist ja nicht auf dieses kleine Blog hier beschränkt.
Rezept ist einfach, möchte man aktuelle Software, nimmt man eine Distribution mit aktueller Software. Da hilft das Heulen auch keinem weiter.
Ja, Arch und Gentoo liefern aktuellere Software. Ja, Debian wird teils von freiwilligen programmiert, und für die Debian-nutzung zahle ich nichts. Trotzdem denke ich, dass konstruktive Kritik für den Fortschritt wichtig ist und daher geäußert werden kann. Und ich empfinde den Blogartikel als konstruktiv.
Es geht nicht um aktuell oder nicht, das Versprechen bei Debian stable ist, das es sich um gepflegte Softwarepakete handelt, bei denen zumindest kritische Sichheitslücken zeitnah geschlossen werden. Das ist auch der Unterschied zu Ubuntus Universe, wo klar ist, das man damit nicht rechnen kann.
Wenn es bei Debian auch nur Glück ist, ob ein Paketmaintainer das leisten kann, ist dass ein sehr berechtigter Kritikpunkt. Schließlich ist Debian auch ein sehr verbreitetes Serversystem, und wer Debian auf dem Desktop nutzt, tut es meist auch weil er ein sicheres System möchte. Mindestens müsste auf den ersten Blick erkennbar sein, welche Pakete supportet werden und welche nicht, und natürlich muss es auch möglich sein, wenigstens eine sinnvolle Basiskonfiguration zu nutzen, ohne sich damit ungepflegte Pakete einzuhandeln.
Debian hat sich in meinen Augen aufgrund dieser “Trägheit” auch mehr und mehr von einem OS – was früher vor allem im Serverbereich eine feste Größe war – hin zu einem reinen Paketlieferanten für andere Distributionen rückentwickelt.
Egal ob in Azure oder AWS, Privatanwender oder Unternehmen….fast nur noch Ubuntu und Kohorten. Anwendungsfälle für RHEL lasse ich hier außen vor.
Es wird sich in hohem Maße an Debian bedient um daraus ein für den Kunden/Nutzer brauchbares Produkt zu generieren, während bei diesen selbst das Interesse stetig mehr schwindet überhaupt noch konkret auf Debian zu setzen.