Wenn man sich die Kommentare in Newsmedien, Foren und auf anderen Diskussionsplattformen zu den neuen Software-Paketen Snaps und Flatpaks (und AppImages) anschaut ist es ein wirkliches Trauerspiel. Die öffentlich sichtbare Community verweigert sich so offenkundig, dass schon bloßes zusehen schmerzt. Dabei wollen die Formate ein real existierendes Problem lösen.
Mit Snaps und Flatpaks habe ich mich hier schon ein paar Mal befasst. Grundsätzlich sehe ich den Ansatz durchaus positiv. Um mich nicht selbst zu wiederholen hier die Links:
- Kommentar: Flatpaks und Snaps – Ein Schritt in die richtige Richtung
- Kommentar: Paketverwaltung vs. moderne Lösungen
- Neue Paketformate – Der Weg ist noch weit
- Snaps oder Flatpaks – Es gibt kein zurück
Natürlich haben die neuen Formate Probleme. Sicherheitslücken in enthaltenen Bibliotheken, Ressourcenverbrauch, Updateverwaltung, zentrale proprietäre Bestandteile etc. pp. Dabei handelt es sich teilweise um Kinderkrankheiten, aber teilweise auch um strukturelle Beschränkungen durch das Konzept. Es gibt deshalb Einsatzszenarien, wo sie einfach keinen Sinn machen. Der gesamte Bereich “Server” gehört dazu. Andere Probleme müssen durch sinnvolle Weiterentwicklung gelöst werden.
Die Gegner der neuen Formate ignorieren aber vollständig, dass Snaps und Flatpaks zwei real existierende Probleme lösen wollen:
1. Verschränkung des Systems
Die klassische Linux-Paketverwaltung hat ein prinzipielles Problem in der Anwendungsverwaltung. Das Paketmanagement verschränkt Kernel, grundlegendes Betriebssystem, grundlegende Werkzeuge, Desktop und grafische Endanwender-Anwedungen. Man kann letzteres nicht sinnvoll aktualisieren ohne die anderen Bestandteile anzufassen.
Die meisten BSD-Varianten haben das Problem schon vor Jahrzehnten mittels der Trennung von Basissystem und Anwendungen (Ports) gelöst. Die Linux-Community hat stattdessen die Paketverwaltung auf einen Sockel gestellt und genau das gemacht, was sie eigentlich ablehnt: Hässliche Workarounds für strukturelle Probleme geschaffen. Nichts anderes ist z. B. der Trend zur Rolling Release Distribution oder die PPA/OBS/Backports der verschiedenen Distributionen. Anwender wollen aktuelle Anwendungen und bekommen stattdessen ein Betriebssystem, das vom Kernel bis zur letzten Bibliothek ständig auf den letzten Stand gebracht wird oder müssen unsichere Drittquellen einbinden.
2. Software-Distribution
Linux Software kommt nicht direkt vom Entwickler zum Anwender (wie meist bei Windows) und auch nicht über einen zentralen Store (wie bei macOS, iOS, Android), sondern über die Distribution. Ein und dieselbe Software muss daher für jede Distribution und jede unterstützte Version einer Distribution gebaut werden. Das war schon immer arbeitsintensiv aber angesichts einer hohen zweistelligen Zahl an verbreiteten Distributionen, plus jeweils mehrere unterstützte Versionen ist das völlig ausgeufert. Distributions-Entwickler haben deshalb wahre Raketentechnik entworfen, wenn es darum geht diese Prozesse zu automatisieren. Trotzdem ist das noch viel Handarbeit und steht inzwischen einem eklatanten Missverhältnis zum Nutzen. Distributionen fungieren zudem immer häufiger als Flaschenhals bei der Softwareverteilung.
Wer also Snaps oder Flatpaks rundweg ablehnt sollte alternative Vorschläge machen, die diese beiden Probleme adressieren. Es sei denn natürlich man ist der Meinung Linux sei perfekt und ausentwickelt.
