Wer hätte gedacht, dass eine Software-Paketierungssoftware einen solchen Trubel verursachen würde? Das ist zumindest bei Snap der Fall. Entwickelt von Canonical als schnellere und einfachere Möglichkeit, die neuesten Versionen der Software auf Ubuntu-Systemen zu installieren, hat die Software am Ende eine feurige Debatte in der größeren Linux-Community ausgelöst. Für die meisten Linux-Anwender ist Snap nur eine Möglichkeit, die gewünschte Software so schnell wie möglich zu erhalten. Aber für Anwender, die sich mit der Ideologie freier und Open-Source-Software befassen, wird es als ein gefährlicher Schritt in Richtung proprietärer Software gesehen, die Manche besonders unter Linux als Gefahr sehen.
Mit dem abspielen des Videos stimmst du den Datenschutzrichtlinien (siehe Datenschutz) von Youtube zu.
Der vielleicht lautstärkste Gegner von Snap und sicherlich derjenige, der die meiste Aufmerksamkeit in den Medien hat, ist Linux Mint. In einem Beitrag vom 1. Juni 2020 auf dem offiziellen Blog der Distribution machte Mint-Gründer Clement Lefebvre sehr deutlich, dass das Ubuntu-Spin-off das neue Paketformat nicht billigt und es nicht in Basisinstallationen aufnehmen würde. Darüber hinaus kündigte er an, dass Mint 20 Benutzer aktiv daran hindern würde, das Snap-Framework über den Paketmanager zu installieren. Es kann immer noch manuell installiert werden, aber dieser Schritt wird als eine Möglichkeit angesehen, zu verhindern, dass es ohne die ausdrückliche Zustimmung des Benutzers zum System hinzugefügt wird.
Die Kurzversion von Clements Beschwerde ist, dass der Snap-Paketmanager aus einer proprietären Canonical-spezifischen Quelle installiert wird. Wenn du Snaps verteilen möchtest, musst du ein Konto bei Canonical einrichten und dort hosten. Während die zugrunde liegende Software immer noch Open Source ist, bricht der Snap-Paketmanager mit der langen Tradition, dass die Verteilung der Software auch offen und frei ist. Dies macht die Installation zweifellos für Anwender einfach und für die Software-Entwickler einfacher zu warten, aber es nimmt auch die Wahlfreiheit und Vielfalt der Paketquellen.
Ein Paket, für alle
Um die Situation zu verstehen, sollten wir wahrscheinlich einen Schritt zurücktreten und uns ansehen, was Snaps tatsächlich sind. Einfach ausgedrückt, sind sie containerisierte Softwarepakete, die Bibliotheken enthalten, die das angegebene Programm ausführen muss. Die Idee ist, dass Entwickler einen einzigen Snap veröffentlichen könnten, der im Wesentlichen auf jedem modernen Linux-System funktionieren würde, anstatt distributionsspezifische Pakete erstellen zu müssen. Theoretisch spart dies Zeit und Mühe seitens des Entwicklers und stellt sicher, dass auch Benutzer von Nischendistributionen Zugriff auf die gewünschte Software erhalten.
Natürlich hat die Verteilung solcher Software Nachteile. Zum einen ist ein Snap-Paket immer größer als ein traditionelles Paket für dasselbe Programm, da alle Abhängigkeiten damit versendet werden müssen. Da viele Programme natürlich die gleichen Abhängigkeiten haben, bedeutet dies, dass ein System mit vielen installierten Schnappschüssen unnötig Speicherplatz für redundante Daten verschwendet. Obwohl, wenn selbst Einstiegssysteme jetzt Terabyte-Festplatten enthalten, dies vielleicht nicht so besorgniserregend ist wie in den vergangenen Jahren.
Gemountete Snap-Pakete bei einer Standardinstallation von Ubuntu 20.04 LTS und 22.04 LTS
Snap-Pakete neigen auch dazu, langsamer zu laufen, zum Teil, weil es sich tatsächlich um komprimierte Dateisystem-Images handelt, die gemountet werden müssen, bevor sie ausgeführt werden können. Einige Benutzer finden dieses Element aus Sicht der Systemwartung besonders ärgerlich, da jedes Snap-Paket, das man installiert, tatsächlich als gemountetes Dateisystem angezeigt wird.
Seit Ubuntu 22.04 wurde tatsächlich eine Möglichkeit geschaffen, gemounteten Snap-Paketen ein spezielles Flag hinzuzufügen, damit gängige Tools wie mount oder lsblk sie nicht anzeigen. Schließlich ist es sinnvoll, festzustellen, wie viel Speicherplatz sie belegen.
Schauen wir uns zum Beispiel an, wie das Snap-Paket für ein gängiges Tool im Vergleich zur direkten Installation abschneidet:
Der Unterschied ist teilweise erheblich. Wenn wir die Software youtube-dl direkt von der Website des Entwicklers herunterladen, belegt das Skript nur 1,8 MB auf der Festplatte. Aber das Snap-Paket des gleichen Programms wiegt samt den ganzen Bibliotheken ganze 93 MB. Es scheint klar, wie sich dieses Problem drastisch verschlimmern würde, wenn mehr Snaps installiert werden.
ABER: Würde ich nun youtube-dl ohne Snap verwenden wollen, fehlen mir eine ganze Menge Pakete, unter anderem handelt es sich hierbei um ein Python Script, das einige Erweiterungen auch benötigt. Installiere ich nun youtube-dl mittels apt Paketen, sieht die Sache schon ganz anders aus und belegt 651 MB zusätzlichen Speicherplatz. Die Pakete lassen sich dann natürlich auch für andere Applikationen und Skripte verwenden. Jedoch sieht man hier der Einfachheit den Vorteil des Snap-Paketes an. Zudem hatte das youtube-dl snap paket lediglich 4 Sekunden zum Installieren benötigt, hingegen um die ganzen Pakete über APT zu laden und zu installieren, jedoch mehrere Minuten.
Davon abgesehen gibt es zweifellos eine Nachfrage nach dieser Art von "universellem" Linux-Paket. Genug, dass es mindestens zwei andere konkurrierende Ansätze gibt, die nach ähnlichen Prinzipien funktionieren, Flatpak und AppImage.
Das CHROME-DEBAKEL
Aus Sicht der Systemressourcen sind containerisierte Pakete eindeutig nicht ideal. Auf der anderen Seite würden viele mehr als glücklich sein, den Leistungseinbußen in Kauf zu nehmen, wenn es bedeuten würde, dass sie Zugriff auf die neuesten Versionen beliebter Programme hätten, ohne warten zu müssen, bis sie im nativen Paket-Repository ihrer Distribution ankommen. Den Benutzern sollte es frei stehen, selbst zu entscheiden, welchen Weg sie basierend auf ihren persönlichen Bedürfnissen einschlagen möchten.
Das macht den Umgang von Canonical mit z.B. dem Chromium-Paket in Ubuntu so beunruhigend. Schauen wir uns genauer an, was passiert, wenn man versucht, Chromium über apt zu installieren:
Während wir das System angewiesen haben, das native Paket zu installieren, erhalten wir jedoch den Snap. Der Benutzer hat keine Wahl und keine vorherige Warnung bekommen. Wenn man nicht genau aufpasst, würde man nicht einmal erkennen, was passiert ist. Auf die Gefahr hin, übermäßig dramatisch zu klingen.
Natürlich gibt es triftige Gründe, warum Canonical Chromium als Snap verteilen möchte. Anstatt Versionen für jede unterstützte Version von Ubuntu zu erstellen, können sie einen einzigen Snap veröffentlichen, der auf allen funktioniert. Dies gilt insbesondere für ältere LTS (Long Term Support) Ubuntu-Versionen, die sonst aufgrund veralteter Systembibliotheken auf einer älteren Version des Browsers stecken bleiben könnten.
Durch die Verwendung dieser Installationsmethode für den Chromium-Snap kann man sicherstellen, dass der Prozess für Benutzer so problemlos wie möglich ist. Tatsächlich würde die Mehrheit wahrscheinlich nicht einmal bemerken, dass die Umstellung stattgefunden hat.
Aber für diejenigen, die es bemerkt haben, ist es eine große Sache. Manche Anwender wechselten von proprietären Betriebssystemen speziell, um von dieser Art von Verhalten der Hersteller wegzukommen. Dies sind die Benutzer, die Clement Lefebvre im Sinn hatte, als er versprach, dass zukünftige Versionen von Mint niemals Snap-Pakete ohne vorherige Zustimmung installieren würden.
Verbesserte Geschwindigkeit dank neuem LZO-Algorithmus
Im Laufe der Jahre hat das Snap-Entwicklungsteam große Anstrengungen unternommen, um Snaps für die Benutzer zugänglicher zu machen. Einer der Schwerpunkte war die Startleistung von Anwendungen. Insbesondere Verbesserungen bei der Verwendung des Komprimierungsalgorithmus für Snaps, haben zu einer Steigerung der Startzeiten um 30-60% geführt. Entwickler haben begonnen, den neuen LZO-Algorithmus in ihre Arbeitsabläufe aufzunehmen, mit positiven Ergebnissen und Feedback der Benutzer.
Der Nachteil der Verwendung des LZO-Algorithmus ist die Größe des Snaps selbst. Am Beispiel des KDE Frameworks: KBlocks wiegt 4 MB komprimiert mit XZ, 6 MB mit LZO. GCompris liegt bei 159 und 194 MB, während das KDE-Framework aufgrund des Algorithmuswechsels von 337 MB auf 443 MB steigt. Der Verlust von Speicherplatz ist jedoch proportional niedriger als die Geschwindigkeitsvorteile. Details und Testergebnisse im Blogartikel von Snapcraft.
Mit SNAP in die Zukunft
Während Canonical kein Unbekannter ist, wenn es darum geht, auf unpopuläre Entscheidungen zurückzugehen, sind Snap-Pakete mit ziemlicher Sicherheit hier, um zu bleiben. Die logistischen Vorteile von containerisierten Paketen sind einfach zu groß, wenn ein gesamtes Unternehmen darauf ausgerichtet ist, Unterstützung für mehrere Versionen einer Linux-Distribution bereitzustellen. Canonical hat Snaps entwickelt, um als Lösung für die Herausforderungen der Wartung einer riesigen und facettenreichen Distribution wie Ubuntu zu sein, und es funktioniert genau wie es soll.
Derzeit scheint es jedoch unwahrscheinlich, dass Snap-Pakete von der größeren Linux-Community in breiterer Masse angenommen werden. Derzeit ist das Snap Repository proprietär. Auch wenn Canonical es Unternehmen ermöglicht, "Markenversionen" des Snap Stores zu erstellen, ist es nur eine kosmetische Änderung und ermöglicht es dir, deinen eigenen Server zu betreiben. Selbst wenn sich eine andere Distribution wie Mint für das Snap-Paketformat entscheiden würde, müssten sie sich auf Canonical verlassen, um die Infrastruktur für die Verteilung der Pakete an ihre Benutzer bereitzustellen. Dieser Single Point of Failure führt zwangsläufig zu einem Streitpunkt für die Akzeptanz außerhalb von Ubuntu-Distributionen.
Nicht jede Software ist als Snap-App verfügbar. Einige Entwickler bevorzugen Flatpak, wieder andere das Format Appimage. Flatpak-Container funktionieren jedoch ähnlich wie Snaps. Flatpak-Apps findest du über https://flathub.org/apps . Auch Linux Mint hat diese implementiert über die „Anwendungsverwaltung“ in der Kategorie „Flatpak“. Bei Appimage hingegen handelt es sich um eine portable App für Linux. Eigene Software für die Verwaltung von AppImage ist nicht notwendig. Die geladene AppImage-Datei enthält alles Nötige in einem Paket.
Quellen
Snap Performancesteigerung im KDE Frameworks
Askubuntu "Are snap packages safe?"
PC-Welt (älterer Artikel, basiert nicht auf die aktuelle Snap Versionen)
Michelfranken - Die Wahrheit über Ubuntu Linux
DerStandard - Offener Konflikt: Linux Mint wirft Ubuntu vor, "Hintertür" einzuschmuggeln
