Streifzug durch Ubuntu 17.04
Snap
Auch wenn Ubuntu die Eigenentwicklungen Unity und Mir eingestellt hat, soll es mit Snap, dem alternativen Paketformat, das Anwendungen in distributionsunabhängige Anwendungs-Container packt, weitergehen. Snap macht es möglich, fast alle Arten von Software zu paketieren. Der Aufwand für die Paketerstellung ist überschaubar und in der Regel geringer als bei DEB-Paketen, denn bis auf eine YAML-Datei, die das Paket und seine Erzeugung beschreibt, gibt es keine Vorschriften, was ein Snap-Paket zu enthalten hat. Umfangreiche Dokumentation und Beispiele findet man auf Snapcraft.io, im FAQ und im Github-Repositorium.
Snap-Pakete werden von Root installiert und stehen dann allen Benutzern zur Verfügung. Sie enthalten Anwendungen mitsamt dem größten Teil ihrer Abhängigkeiten, was ihre Aktualisierung unabhängig vom Rest des Systems ermöglicht. Um zu verhindern, dass jedes Snap-Paket eine große Menge duplizierten Codes (Bibliotheken usw.) mitbringt, gibt es Abhängigkeiten zwischen den Paketen (die automatisch aufgelöst werden), und auf der untersten Ebene gibt es definierte Laufzeitumgebungen, z.B. das 75 MB große Snap-Paket »core«, das früher »ubuntu-core« hieß. Trotz der Namensänderung, die mehr Distributionsunabhängigkeit signalisieren soll, handelt es sich dabei natürlich um Ubuntu. Enthalten ist ein Basissystem (natürlich ohne Kernel) mit den wichtigsten Bibliotheken, Werkzeugen und Shells, das auf Ubuntu 16.04 LTS beruht und damit für Stabilität sorgt. Verwirrenderweise gibt es auch das Paket »ubuntu-core« noch, und zwar mit neuerer Versionsnummer als »core«. Die Beschreibung liefert keinen Aufschluss, was die Unterschiede sind.
Snap wird über das gleichnamige Kommandozeilenprogramm benutzt, das mit dem permanent im Hintergrund laufenden Daemon snapd kommuniziert. Jedes Snap-Paket ist versioniert und kann aktualisiert werden. Eine Aktualisierung kann durch ein Zurücksetzen auf eine frühere Version rückgängig gemacht werden. Ein einmal erstelltes Snap-Paket sollte auf allen Systemen laufen, die Snap unterstützen. Anwendungen sind so weit wie möglich voneinander isoliert. Sie sind außerdem vor Änderungen geschützt - technisch ist das so realisiert, dass die Snap-Pakete per Loopback in ein Unterverzeichnis von /snap gemountet werden. Es gibt auch Verzeichnisse, in denen die Snap-Pakete Dateien ablegen dürfen, Konfigurationsdateien ebenso wie andere Daten.
Da Snaps fast immer mit anderen Anwendungen oder dem System kommunizieren müssen, gibt es eine laufend erweiterte Liste von Schnittstellen, die solche Verbindungen schaffen. Snap-Pakete müssen deklarieren, welche Schnittstellen sie benötigen oder anbieten, und das System lässt nur die deklarierten Zugriffe zu. Damit kann die Sicherheit des Systems garantiert werden, außer bei X11-Anwendungen. Der Grund ist der, dass X11 nicht darauf ausgelegt ist, Anwendungen voneinander zu isolieren, es bietet einfach nicht die Möglichkeiten dafür. Mit Wayland wird das voraussichtlich ganz anders aussehen. Insgesamt erinnert Snap also schon stark an das App-Ökosystem von Android, das sicherlich in vielerlei Hinsicht Ideengeber war.
Nach wie vor gibt es nur ein einziges, nicht konfigurierbares Repositorium für Snaps. In diesem findet man bescheidene 101 Pakete, keine nennenswerte Änderung gegenüber letztem Jahr. Von diesen lassen sich noch nicht einmal alle nutzen. So fehlte nach der Installation von Konversation eine Bibliothek, so dass das Programm nicht startete. Und Chronoburn, ein Programm, das die erweiterte Laufzeitumgebung »ubuntu-app-platform« (installiert fast 700 MB) benötigt, ließ sich nicht zum Start bewegen.
Auch die von Canonical beschworene Plattformunabhängigkeit ist nicht einmal ansatzweise realisiert. Zwar soll Snap jetzt offiziell unter Fedora laufen, ebenso auf einigen anderen Distributionen, in der Realität gibt es jedoch nur eine Distribution, unter der Snaps uneingeschränkt funktionsfähig sind, nämlich Ubuntu (und vielleicht noch Debian Unstable). Vor einem halben Jahr wurde Snap noch ein erheblicher Vorsprung vor Flatpak bescheinigt, dabei wurde Snap aber stark überschätzt.
Die Ähnlichkeit von Flatpak und Snap ist klar. Beide verpacken Anwendungen mit ggf. zusätzlich benötigten Bibliotheken in ein Paket, das isoliert vom System und isoliert von anderen Anwendungen in einer Sandbox läuft. Damit die Pakete keine endlose Zahl von Bibliotheken mitbringen müssen, können sie von einer Laufzeitumgebung abhängen, die ebenfalls als Paket vorliegt. Verschiedene Versionen von Laufzeitumgebungen und Anwendungen können parallel installiert sein, und die Pakete können mit einem Kommando aktualisiert werden. Beide Systeme sind außerdem distributions- und Desktop-unabhängig. Unterschiede sind unter anderem, dass Snap ein zentrales, von Canonical kontrolliertes Repositorium fest eingebaut hat, während Flatpak beliebige Repositorien einbinden kann (was ähnlich wie bei YUM/DNF oder APT manuell konfiguriert werden muss).
Ein weiterer Unterschied zwischen Flatpak und Snap ist, dass Flatpaks nur für Desktop-Anwendungen gedacht sind, während Snaps universell sind und das bisherige Paketsystem vielleicht sogar einmal ganz ersetzen können. Ein kleiner Vorteil von Flatpak ist wiederum, dass man auch als Nicht-Root-Benutzer Pakete installieren kann, während Snaps komplett von Root verwaltet werden.
Gemeinsam wiederum ist beiden, dass sie nicht ausgereift, ja noch nicht einmal vollständig sind. Als Nichtentwickler sollte man absolut die Finger von beiden lassen. Meiner Meinung nach sollte man sogar beide so lange boykottieren, bis sich die beiden Lager zusammengerauft und unter einem neuen Projekt eine allgemeingültige Lösung präsentieren. Das wäre das beste für Linux, da ansonsten die Container-Landschaft von Linux mit zwei neuen, sich in der Zielsetzung ähnelnden, aber nicht kompatiblen Formaten unnötig weiter zersplittert wird.
