Datenschutz im digitalen Alltag

Damit Privates privat bleibt

Symbolbild "Paket"

Snaps und Flatpaks - Das zu Grunde liegende Problem

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:

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.


Bilder:
Einleitungs- und Beitragsbild von harshahars via pixabay

"

Tags: Linux, Paketierung, Flatpaks, Snaps

Ergänzungen zum Artikel

Weitere Informationen können den Nutzungsbedingungen entnommen werden.

ener
Was ist mit AppImages? Wie sind diese dazu im Verhältnis zu bewerten?
Gerrit
AppImages waren keine schlechte Idee, aber sie kommen meines Erachtens durch die Fokusverlagerung (Canonical -> Snaps / Red Hat -> Flatpak) unter die Räder. Außerdem fehlt ihnen der Distributionsmechanismus (snapcraft, flathub).
noisefloor
Ich sehe da noch eine dritten Grund (der z.T. in den Punkten 1+2 enthalten ist): der Zeitgeist.
Vom Smartphone ist man es gewohnt, dass mir einem Touch ein Programm / ein App installiert, ohne sich mit Abhängigkeiten, Versionskonflikten etc. herumschlagen zu müssen. Genau das bieten snap und Flatpak auch.
Klar sind apt & Co extrem leistungsfähig - aber apt & co sind mit Sicherheit nicht selbsterklärend für die breite Masse. Das können snap & flatpak besser.

Gerrit
Ja sicherlich auch. Anwender verstehen nicht warum das gleiche Tool für Betriebssystem und "Apps" zum Einsatz kommt und letztere wegen ersteren nicht aktualisiert werden können. Das funktioniert schließlich auf jeder anderen Plattform getrennt.

Aber ich glaube die Schwierigkeit aktuelle Programmversionen zum Endanwender zu bringen überwiegt. Das nervt sowohl die Entwickler, als auch die Anwender. Dadurch erreicht man ein kritisches Gewicht, dem sich die Distributoren ein Stück weit beugen müssen.

Abbc
Meiner Meinung nach macht Slackware mit SlackBuilds, https://slackbuilds.org, schon vieles richtig, aber für den Endanwender ist es immer noch zu kompliziert. Da es keinen PM wie Apt, Yum oder Zypper gibt, baut man sich über Bash-Skripte automatisch seine Software. Wer sich in Linux Paketbau etwas auskennt, kann sich seine Pakete selber bauen. So wird das nun Uralte Slackware 14.2 auch mit frischer Software versorgt. Ähnlich wie bei Windows.

Es hat sich bisher niemand gefunden, der dieses System erweiterte und zum Beispiel in ein "App-Store" gebaut hat. Ich denke das diese Idee wirklich Potential hat.

Seitdem ich mich als Co-Maintainer für ein Paket im Fedora-Projekt versucht hatte, um dieses für EPEL 7 zu paketieren, glaube ich, ein wenig mitreden zu können und behaupte: "Nicht mal Raketentechnik ist so kompliziert wie Software für unterschiedliche Distributionen zu paketieren!"

Darüber hinaus habe ich schon enige Vorträge zum Open Suse Build Service gehört und mich wiederholt gefragt: "Wer tut sich das freiwilllig an? Selbst wenn man dafür bezahlt wird, ist es wohl eher Schmerzensgeld als Lohn."

Daher stimme ich diesem Artikel zu, dass Snap, Flatpak und AppImage für den Desktop eine Lösung für das elementare Verteilungsproblem bieten. Aus Entwicklersicht, möchte ich meine Software einer möglichst großen Nutzergruppe zur Verfügung stellen und mir nicht für jede Distribution erneut die Finger brechen.

Ich persönlich sehe Linux noch immer als ein Betriebssystem für technisch interessierte Nutzer und weniger für die breite Masse. Daher finde ich auch die Idee, sich die benötigte Software einfach selbst zu kompilieren grundsätzlich ganz charmant. Doch leider lässt die Dokumentation einiger Software-Projekte arg zu wünschen übrig, so dass es fast so schrecklich ist ein Kompilat zu erstellen, wie ein Paket zu bauen. ;-)

Ich bin gespannt, wie sich die neuen Paketformate im Wettbewerb mit den Containern schlagen. Gefühlt wird immer mehr Software in einen Container verpackt und als solcher ausgeliefert. Leider finden sich darin nicht selten hoffnungslos veraltete Bibliotheken und Interpreter. Ich hoffe, dass hier von Seiten der Kunden/Nutzer zukünftig mehr Wert auf Qualität und gepflegte Software gelegt wird.

5000 Buchstaben übrig


  • 1

Über [Mer]Curius

Immer größere Teile unseres Lebens haben sich in den vergangenen Jahren digitalisiert. Es gibt heute unzählige Dienste und jeder Mensch hinterlässt permanent Spuren. Die Datensätze, die hier entstehen wecken viele Begehrlichkeiten. Es besteht aber auch die Möglichkeit durch gezielte Maßnahmen die eigene Datenspur zu minimieren und Daten effektiv und sicher zu schützen. Damit entgeht man zwar nicht jeder Überwachungsmaßnahme, erlangt aber zumindest teilweise die Kontrolle über die eigenen Daten zurück.

→ Mehr über [Mer]Curius