Universalpakete
Flatpak und Snap sollen App-Installationen unter Linux revolutionieren
Linux-Distributoren versorgen ihre Anwender mit einer umfassenden Software-Ausstattung. Immer mal wieder fehlen aber Programme oder sind schrecklich veraltet. Flatpak und Snap versprechen dieses Manko mit Distributions-übergreifenden Paketen aus der Welt zu schaffen. Das soll Linux auch attraktiver für Entwickler machen.
Anwendungen unter Linux einzurichten kann kinderleicht sein: Software-Verwaltung öffnen, Programm installieren und starten – fertig. Aber wehe, dem eingesetzten Linux fehlt die gesuchte Anwendung, dann wird es schnell kompliziert. Dasselbe gilt, wenn die Paket-Repositories eine veraltete Version des Programms enthalten, man aber eine neuere braucht.
Flatpak und Snap versprechen, solche Probleme aus der Welt zu schaffen, indem sie Software mit allem zusammenpacken, was diese zur Ausführung benötigt. Die resultierenden Pakete laufen so unter verschiedenen Distributionen. Das soll auch Entwickler anlocken: Sie können quelloffene oder proprietäre Linux-Programme jetzt selbst verteilen, ohne Pakete für Dutzende von Distributionen bauen zu müssen. Darüber hinaus versprechen die neuen Paketformate mehr Sicherheit, da sie Programme besser vom Betriebssystem und anderen Anwendungen abschotten.
Noch ist aber ungewiss, ob Flatpak oder Snap zum universellen Standard für „Linux Apps“ werden, wie es sich die Entwickler der beiden Ansätze vorstellen. Ohnehin unterscheiden sich die Herangehensweisen in wichtigen Punkten. Das ist einer von mehreren Gründen, warum womöglich beide einen Platz finden. Die zwei werden DEB- und RPM-Pakete allenfalls zurückdrängen, aber keineswegs ablösen.
Die wichtigsten Eigenschaften und Unterschiede der beiden Ansätze in Kurzform: Anders als DEB- und RPM-Pakete enthalten Flatpak- und Snap-Pakete nahezu alle zum Ausführen der Anwendung erforderlichen Bibliotheken, Interpreter und Daten. Flatpak ist speziell für Desktop-Apps gedacht, Snap hat auch Kommandozeilenprogramme und Server-Apps im Visier. Snaps werden immer systemweit installiert; das geht auch mit Flatpaks, allerdings können Anwender diese auch in ihrem Home-Verzeichnis einrichten, was dann sogar ohne Root-Rechte gelingt.
Ähnlich wie bei Smartphone-Apps kommt man mit Flatpaks oder Snaps normalerweise nicht als Datei in Kontakt: Flatpaks werden meist über Repositories auf beliebigen Webservern verteilt und aktualisiert, Snaps hingegen über einen zentralen App-Store im Internet, wie man es von Android und iOS kennt. Beide Ansätze ermöglichen ein schnelles Downgrade auf ältere Versionen, falls eine neue Paketversion Probleme macht. Beide führen Anwendungen isoliert aus, arbeiten aber noch darauf hin, eine mit Android vergleichbare Isolation zu bieten.
Flatpak wird maßgeblich aus der Red-Hat-/Fedora-Welt vorangetrieben, Snap von Canonical dominiert. Beide wurden nach mehreren Entwicklungsjahren in den vergangenen Monaten zur allgemeinen Verwendung freigegeben; das aus Snappy hervorgegangene Snap kam ein wenig überraschend, wohingegen die Einsatzreife des bis vor Kurzem noch Xdg-Apps genannten Flatpak schon länger absehbar war.
Schnellstart Flatpak
Der Name Flatpak spielt auf den englischen Begriff „Flat Pack Furniture“ an, der für Möbel von IKEA & Co. steht. Auch Flatpak arbeitet mit Fertigbausteinen, die es auf dem lokalen System zusammensetzt. Die Kommandozeilenprogramme zum Einrichten und Betreiben von Flatpaks sind unter anderem in Fedora 24 zu finden. Erst im Herbst mit Version 25 soll die grafische Paketverwaltung eine umfassende Flatpak-Unterstützung erhalten.
Die Installation eines Flatpaks erfordert einen Satz komplexer Kommandos, die der Screenshot unten zeigt. Der erste Befehl lädt einen öffentlichen GPG-Key herunter, der die Interaktion mit den Repositories gegen Manipulation durch Angreifer absichert. Die nächsten drei Kommandos binden ein vom Gnome-Projekt betriebenes Flatpak-Repository lokal als „gnome“ ein, um daraus die Flatpak-Runtime „org.gnome.Platform 3.20“ samt der zugehörigen Unterstützung für nicht-englische Sprachen zu installieren. Diese Runtime stellt eine Basisumgebung bereit, die von Gnome-3.20-Anwendungen typischerweise verwendete Bibliotheken (Glibc, OpenSSL, GTK+ …) und Interpreter (JavaScript, Python …) enthält. Die nächsten drei Kommandos binden ein weiteres Repository als „gnome-apps“ ein, um daraus das Flatpak mit der Wetter-App des Gnome-Projekts zu installieren und über das Flatpak-Run-Kommando zu starten.
Die Komponenten eines Flatpaks sind auf mehrere Dateien verstreut, die im Repository liegen. Neben dem Online-Installationsweg beherrschen die Flatpak-Werkzeuge auch die Software-Einrichtung über „Bundles“, wo alles zur Installation des Flatpaks in einer einzelnen Datei steckt. Diesen Weg nutzen die LibreOffice-Macher, die eine Vorabversion von LibreOffice 5.2 als Flatpak-Bundle anbieten. Das baut allerdings auf der erwähnten Gnome-3.20-Runtime auf. Diese muss man daher wie im Screenshot gezeigt installieren, um das Bundle einrichten und starten zu können:
wget https://download.:
.documentfoundation.org/libreoffice/:
.flatpak/latest/LibreOffice.flatpak
flatpak install --user :
.--bundle LibreOffice.flatpak
flatpak run org.libreoffice.LibreOffice
Das Bundle enthält neben einem GPG-Key auch Informationen, wo im Web das zugehörige Flatpak-Repository liegt. Sobald die LibreOffice-Entwickler ein Update dorthin laden, aktualisiert ein flatpak update die Software.
Schnellstart Snap
Snap ist eine direkte Weiterentwicklung von „Snappy“, mit dem sich Anwendungen beim Cloud-/IoT-Betriebssystem „Snappy Ubuntu Core“ nachinstallieren ließen. Durch seine Abstammung wird die Snap-Infrastruktur häufig als Snappy bezeichnet und Snaps manchmal als Snappy Apps, obwohl das Hauptprogramm zur Snap-Handhabung jetzt snap heißt und einige Interna verändert wurden. Das Werkzeug zum Paketbauen heißt wie schon immer snapcraft.
Ein erstes Snap lässt sich mit nur einem Kommando installieren:
sudo snap install krita
Das Snap-Werkzeug lädt das Zeichenprogramm dann aus dem Snap Store herunter und richtet es ein, sodass es sich via krita starten lässt – im Unterschied zu Flatpak also genauso, wie eine über Apt installierte Version des Programms.
Snaps gibt es nicht nur im Snap Store, sie lassen sich auch als Datei weitergeben, um sie lokal installieren zu können. Das Snap-Werkzeug kann eine so eingerichtete Software aber nicht aktualisieren; das klappt nur mit Snaps, die es selbst aus dem Snap Store geholt hat.
Zentrale Abhängigkeit
Schon diese ersten Schritte zeigen entscheidende Unterschiede zwischen den beiden Ansätzen. Flatpak erfordert derzeit viele komplexe Kommandos. Snap hingegen ist schnell am Start. Das ist unter anderem dem Snap Store von Canonical zu verdanken. Das Unternehmen betreibt ihn als zentralen Marktplatz mit einer proprietären Software im Web. Das führte zu Kritik aus der Open-Source-Szene. Ein Entwickler hat daraufhin eine einfache Web-App veröffentlicht, mit der jedermann einen rudimentären Store für Snaps einrichten kann. Der Open-Source-Code soll laut einem Canonical-Mitarbeiter in das Snap-Paketbau-Tool Snapcraft einfließen. Bislang kann Snap aber nicht mehrere Snap Stores parallel handhaben. Man muss daher jedes Mal mühsam umkonfigurieren, um neben alternativen Snap Stores auch den von Canonical zu verwenden.
Die ersten Schritte mit Snap sind auch einfacher, weil man bei Snaps keine Runtime wählen muss, wie es bei Flatpaks der Fall ist. Eine solche Grundausstattung gibt es aber auch bei Snaps: das automatisch eingerichtete „OS Snap“ namens „Ubuntu Core“. Dieses liefert Standard-C-Library, OpenSSL-Bibliothek und andere Kern-Komponenten, die Linux-Anwendungen in aller Regel verwenden. Auf Wunsch können Entwickler aber auch neuere Versionen dieser Bibliotheken in ihre Snaps integrieren. Alternative, selbst gebaute OS Snaps, sind theoretisch denkbar, aber mit dem offiziellen Snap Store keine Option: Der einer Publikation im Store vorgeschaltete und von Canonical durchgeführte Prüfprozess sieht vor, dass dort vertriebene Anwendungen auf OS Snap von Ubuntu aufbauen.
Ein Snap bietet erst in Kombination mit dem OS Snap alles, was die enthaltene Anwendung braucht, um unter modernen Distributionen zu laufen. Ähnlich gilt das für Flatpak und Flatpak Runtime, wobei auch Flatpaks möglich sind, die ohne Runtime funktionieren.
Anwendungen im Bundle mit der von ihnen benötigten Umgebung auszuliefern lässt bei Linux-Experten die Alarmglocken schrillen: Leicht landen Bibliotheken wie GTK+, Libxml2 und Qt mit Flatpaks und Snaps mehrfach auf der Platte; das Gleiche gilt für Interpreter von Programmiersprachen wie Java, JavaScript und Python. Manchem stößt das schon wegen des Verbrauchs von Internetbandbreite und Plattenplatz sauer auf. Das viel größere Problem sind Sicherheitslücken in Bibliotheken oder Laufzeitumgebungen: Wenn GTK+ oder Python in mehreren Flatpaks und Snaps steckt, müssen Lücken bei jedem von ihnen gestopft werden.
Dies ist ein prinzipbedingter Nachteil der zwei neuen Paketformate, der allerdings die Distributionsunabhängigkeit erst möglich macht und daher in Kauf genommen werden muss. Die Flatpak-Macher versuchen die Problematik ein wenig zu entschärfen, indem sie die Verwendung verschiedener Runtimes erlauben. Die im obigen Beispiel verwendete Runtime des Gnome-Projekts nutzen nicht nur Gnome-Anwendungen, sondern auch das LibreOffice-Flatpak. GTK+ steckt daher nur in der Runtime und muss auch nur dort korrigiert werden, wenn eine Sicherheitslücke auftaucht. Bei Snaps hingegen klappt das nicht: Snaps bringen immer ein eigenes GTK+ mit, weil es kein Bestandteil des OS Snap ist. Letzteres ist dadurch viel kleiner als die Gnome-Runtime. Der Flatpak-Ansatz wird allerdings umso effizienter, je mehr Flatpaks dieselbe Runtime verwenden.
Passend zu seiner Flatpak Runtime bietet das Gnome-Projekt ein Software Development Kit als Runtime an, mit dem Paketbauer eine Anwendung für die Gnome-Runtime kompilieren können. Darüber hinaus bietet das Gnome-Projekt auch mehrere Versionen einer „org.freedesktop.Platform“ genannten Runtime an, die deutlich schlanker ist und als Ausgangsbasis für die Gnome-Runtime dient. Das KDE-Projekt schraubt noch an einer Flatpak-Runtime; auch einige Distributionen erwägen, Laufzeitumgebungen anzubieten.
Die Flatpak-Werkzeuge aktualisieren Flatpaks und deren Runtime mit Hilfe von Delta-Updates, damit beim Update nur die Unterschiede zwischen alter und neuer Version durch die Leitung müssen. Snap dagegen lädt aktualisierte Snaps in Gänze aus dem Internet, was bei schwergewichtigen Anwendungen wie LibreOffice jedes Mal einen Download von zirka dreihundert Megabyte bedeutet. An Delta-Updates wird bereits gearbeitet; Snappy beherrschte sie bereits. Die Funktion ging mit Snap aber verloren, weil mit dem Namenswechsel auch das Image-Format verändert wurde.
Heim- und Auswärtsspiele
Flatpaks und Snaps mögen auf den ersten Blick Distributions-unabhängig wirken. Das stimmt aber nur bedingt, denn um solche Pakete installieren zu können, braucht man die zum Paketformat gehörenden Werkzeuge. Die finden sich bislang nur bei wenigen Distributionen.
Canonical hat im Juni eine Furore machende Mitteilung veröffentlicht, die bei flüchtigem Lesen den Eindruck erweckt, wichtige Distributionen stünden hinter Snap und würden Snap-Unterstützung bald standardmäßig einrichten. Davon ist Snap aber noch weit entfernt; zudem ist Flatpak bei der Unterstützung durch Distributoren keineswegs schlechter aufgestellt, sondern minimal besser. Snap steckt bislang in Arch Linux, Ubuntu 16.04 und dem Entwicklerzweig von Debian (Unstable/„Sid“). Flatpak hingegen findet sich in Arch Linux, Fedora 23 & 24 sowie den Entwicklerzweigen von Debian und Mageia („Cauldron“). Zudem hat Endless Computers angekündigt, Flatpak als alleiniges App-Format seines für Entwicklungsländer gemachten Computers zu nutzen.
Man kann die Flatpak- und Snap-Werkzeuge auch unter anderen Distributionen zum Laufen bringen. Die Flatpak-Macher bieten etwa ein Paket-Repository an, über das man Flatpak-Unterstützung schnell bei Ubuntu 16.04 nachrüsten kann. Ebenso leicht lässt sich Snap über Add-On-Repositories von Canonical-Mitarbeitern bei Fedora oder Mageia einrichten. Bislang kommen sich die Paketwerkzeuge dabei nicht in die Quere; daher kann man Flatpaks und Snaps auf einem System parallel verwenden. Theoretisch ist es auch denkbar, Flatpaks in Snaps beziehungsweise Snaps in Flatpaks zu verwandeln; bislang hat aber niemand solch einen Konverter geschrieben.
Abschirmen
Die Inhalte von Flatpaks oder Snaps landen in eigenen Verzeichnissen, um Konflikte mit den Anwendungen und Bestandteilen der Linux-Installation zu vermeiden. Snaps sind Squashfs-Images, die schreibgeschützt in /var/lib/snapd/snaps/ landen und beim Start der Anwendung unter /snaps/ gemountet werden. Flatpak-Inhalte liegen in /var/lib/flatpak/ für systemweit installierte Anwendungen und in ~/.local/share/flatpak/ bei nutzerspezifisch installierten Paketen.
Snap führt Anwendungen direkt aus und setzt dabei Suchpfade wie LD_LIBRARY_PATH, damit das Programm im Snap nicht Bibliotheken und Interpreter des Betriebssystems nutzt, sondern die des OS Snap. Um die Sicherheit zu steigern, unterbindet Snap mit Hilfe der Kernel-Funktion Seccomp den Zugriff auf einige Systemfunktionen (Syscalls), die Anwendungen typischerweise nicht brauchen. Die Sicherheitstechnik AppArmor blockiert Zugriffe auf Verzeichnisse wie /usr/, /etc/ oder /var/. Dieser Schutz funktioniert aber nur bei Ubuntu und davon abgeleiteten Distributionen so richtig, denn Snap realisiert ihn mit AppArmor-Erweiterungen im Ubuntu-Kernel, die Canonical nicht in den offiziellen Linux-Kernel eingebracht hat; sie fehlen daher in den meisten Distributionen und lassen sich dort auch nicht mal eben schnell nachrüsten.
Ein zweiter Grund, warum der AppArmor-Einsatz für die Distributions-Unabhängigkeit problematisch ist: Fedora und eine ganze Reihe weiterer Distributionen unterstützen die Sicherheitstechnik nicht. Snap nutzt in solchen Fällen keine Verzeichnisabschirmung, sodass sich via Snap installierte Anwendungen ganz normal im Root-Dateisystem umsehen können. Und nicht nur das: Damit Snap unter Fedora überhaupt läuft, muss man die dort standardmäßig aktive Sicherheitstechnik SELinux systemweit deaktivieren. Selbst wenn die Snap-Entwickler dieses Problem lösen, ist das nur die halbe Miete, denn AppArmor und SELinux lassen sich nicht gleichzeitig verwenden.
Anders als Snap setzt Flatpak aus Runtime und Paket ein Verzeichnis mit einer Userland-Umgebung zusammen, in der es die Anwendung ausführt. Wie bei Docker-Containern nutzt Flatpak dabei Namespaces und Chroot, damit das Programm nur die aufgesetzte Umgebung sieht und nicht die des Betriebssystems.
Sowohl Snap- als auch Flatpak-Werkzeuge gewähren einem ausgeführten Programm Zugriff auf einige Dateien der Linux-Installation, damit die ausgeführte Software beispielsweise an den richtigen 3D-Treiber herankommt. Wenn gewünscht, können die Paketwerkzeuge auch andere Dinge verfügbar machen. Typischerweise gehört dazu das Home-Verzeichnis, damit per Flatpak oder Snap ausgeführte Anwendungen dort schreiben oder lesen können.
Trotz der speziellen Installationsorte kann man per Snap eingerichtete Software auf der Kommandozeile aufrufen, denn die Snap-Werkzeuge legen Skripte zum Programmstart in /snaps/bin/ ab, das bei der Snap-Installation in den Suchpfad aufgenommen wird; bei Flatpaks ist das nicht der Fall, daher ist flatpak run nötig.
Damit grafische Anwendungen in der Programmauswahl der Bedienoberfläche auftauchen, legen Flatpak- und Snap-Werkzeuge passende Starterdateien an den relevanten Stellen ab. Dadurch tauchen Anwendungen aber mehrfach in der Programmauswahl auf, wenn man sie über die Paket-Repositories der Distribution und parallel auch via Flatpak oder Snap einrichtet.
Marktangebot
Im standardmäßig verwendeten „Stable“-Channel des Snap Store standen Mitte Juli rund hundert Snaps zur Installation bereit. Darunter sind ein paar simple, zum Experimentieren gedachte Snaps und einige Pakete mit Kommandozeilenprogrammen. Bekannte Server-Anwendungen waren spärlich gesät, aber immerhin war der OwnCloud-Ableger Nextcloud zu finden. Desktop-Anwendungen gab es etwas mehr, darunter Blender, Krita, den Text-Editor Atom und ein Snap mit dem aktuellen Entwicklungsstand von VLC 3.0. LibreOffice gab es nicht im Store, ein Snap-Entwickler hat aber ein Snap mit einer Beta von 5.2 geschnürt, das er im Web zum Download anbietet. Die Firefox-Entwickler haben angekündigt, ein Snap mit ihrem Browser anbieten zu wollen.
Bei zwei der Snaps im Store zeigte snap in der Spalte „Notes“ einen Preis an. Sie ließen sich aber nicht installieren, weil Ubuntu 16.04 zum Testzeitpunkt noch eine Snap-Version ohne Kauffunktion enthielt. Die hat Snap 2.10 nachgerüstet, das während der Artikelentstehung als Update für Ubuntu 16.04 freigegeben wurde; aber auch damit hat die Installation nicht funktioniert.
Mangels zentralem Marktplatz lässt sich nicht sagen, wie viele Flatpaks zirkulieren. Die Flatpak-Homepage erwähnt nur rund 17 Pakete mit Gnome-3.20-Programmen, das Flatpak-Bundle mit der LibreOffice-5.2-Beta und ein Repository, das Entwicklerversionen von Gimp, Inkscape, MyPaint und Scribus enthält.
Flatpak- und Snap-Pakete zeigen derzeit oft Kinderkrankheiten. Teilweise ist das die Schuld der neuen Paketformate, manchmal aber auch die von Entwicklern, die beim Paketbau noch Fehler machen. Dem LibreOffice-Flatpak fehlt beispielsweise ein Java Runtime Environment (JRE), daher laufen darauf angewiesene Funktionen nicht; dazu zählt LibreOffice Base oder die Grammatikprüf-Extension LanguageTool.
Auch in der Snap-Welt läuft noch nicht alles rund. Dem Snap mit Krita fehlen die Sprachdateien, daher sind die Menüs alle in Englisch. Außerdem liefen Krita und andere auf 3D-Beschleunigung angewiesene Anwendungen nicht, wenn die eingesetzte Linux-Distribution Nvidias proprietären Grafiktreiber verwendet. Die erwähnte Snap-Version 2.10 verspricht, dieses Manko aus der Welt zu schaffen.
Bei beiden Lösungen ist die Anwendungsisolation noch nicht ausgereift. So passiert nichts, wenn man in den derzeit verteilten Flatpaks oder Snaps mit LibreOffice beispielsweise einen Hyperlink anklickt oder die Online-Hilfe anfordert. LibreOffice kann nämlich den Browser der Linux-Installation nicht erreichen. Um solche Funktionen zu ermöglichen, müssen Löcher in die Abschirmung gebohrt werden, die die Anwendungen dann auch ausnutzen müssen.
Die Entwickler beider Lösungen arbeiten zudem darauf hin, die Abschottung noch zu verbessern, um mittelfristig eine mit Android vergleichbare Isolation zu bieten. Bei Flatpak soll es dadurch möglich werden, dass Anwendungen nicht mehr überall im Home-Verzeichnis lesen und schreiben können, sondern nur noch dort, wo der Nutzer es über den Datei-Öffnen/Speichern-Dialog erlaubt hat. Ferner sind Mir und Wayland wichtig, denn erst mit diesen neuen Ansätzen zur Ausgabe von Linux-Desktops lassen sich grafische Anwendung ordentlich abschotten. Mit dem bislang verwendeten Xserver und seinem X11-Protokoll ist das nicht effizient möglich. Auch via Flatpak oder Snap ausgeführte X11-Programme können daher derzeit PINs, TANs und Kontostände abgreifen, wenn der Anwender in einem parallel laufenden Browser seine Bankgeschäfte erledigt.
Reviere
Zum Kasten: Linus Torvalds setzt auf AppImage
Flatpak und Snap werden DEB- und RPM-Repositories und die darin befindlichen Pakete nicht verdrängen. Die neuen Paketformate sind nämlich nicht zum Schnüren von Paketen geeignet, aus denen man dann Distributionen und deren Installationsimages zusammensetzt. Die etablierten Paketformate sind auch um Längen besser geeignet, größere Rechnerparks in Firmen oder Bildungseinrichtungen mit einer einheitlichen Software-Ausstattung zu versorgen. Auch zum Bau von Flatpaks, Flatpak Runtimes, OS Snaps und Snaps können DEBs und RPMs nützlich sein, damit man beim Paketbau nicht bei null anfangen muss.
Aber: Einige Fedora-Entwickler haben bereits offen darüber nachgedacht, exotische Desktop-Anwendungen aus den Repositories der Distribution zu entfernen, falls es die Programme auch als Flatpak gibt. Auch bei Ubuntu deutet einiges darauf hin, dass es so laufen wird. Auf jeden Fall will Canonical das Debian-Format für kommerzielle Anwendungen aufgeben; solche Programme, die für alte Ubuntu-Versionen als DEB-Paket im Ubuntu Software Center zu kaufen waren, sollen ab Herbst ausschließlich als Snaps verteilt werden.
Die Flatpak-Entwickler zielen mit ihrem Ansatz explizit auf Desktop-Anwendungen. Das Feld von Kommandozeilen- und Server-Anwendungen überlassen sie bewusst DEB und RPM sowie Container-Lösungen wie Docker, die auf dieses Einsatzgebiet zugeschnitten sind. Snap hingegen bedient die ganze Einsatzpalette, denn Canonical will es zur Installation von Software auf PCs, Servern, IoT-Hardware, Smartphones und Tablets nutzen.
Rückhalt
Inwieweit oder wo sich Flatpaks und Snaps etablieren, hängt maßgeblich davon ab, wie weit Software- und Distributions-Entwickler sowie Nutzer die ein oder andere Lösung annehmen.
Für kommerzielle Software-Hersteller dürfte Snap attraktiver sein, schließlich ist Ubuntu die populärste Linux-Distribution. Snap ist auch wegen des Stores attraktiv: Software-Entwickler bekommen mit ihm eine Vertriebsplattform frei Haus, die auch gleich den Geldfluss regelt; für diese Arbeit will Canonical offenbar einen Obolus nehmen, wie es Apple und Google beim Apple Store oder Play Store machen. Ähnlich wie dort verleiht der Store seinem Betreiber auch Macht, denn Canonical lässt in den Standard-Channel seines Stores nur Snaps, die das Unternehmen für gut befunden hat.
Bei den Linux-Distributoren und ihren Entwicklern scheint Flatpak bessere Karten zu haben. Die sehr starke Abhängigkeit vom Snap Store stellt für Entwickler einiger Distributionen ein Problem dar – gerade für Red Hat und Suse: Die beiden Schwergewichte dürften wenig Interesse daran haben, eine Snap-Unterstützung in die eigenen Enterprise- und Community-Distributionen zu integrieren, wenn das einem Konkurrenten zu einer Schlüsselposition verhilft, mit der er Einnahmen generieren kann. Aus eben diesem Grund dürfte Flatpak auch attraktiver für Spiele-Marktplatz-Betreiber wie GOG.com oder die hinter Steam stehende Firma Valve sein.
Auch die erwähnten AppArmor-Probleme dürften bei manchen Distributoren gegen Snap sprechen. Eine weitere Schwierigkeit ist das Contributor License Agreement (CLA). Dabei handelt es sich um einen Vertrag, den Programmierer eingehen müssen, um Änderungen zu Snap beitragen zu können. Auch das ist einigen Distributions-Entwicklern ein Dorn im Auge. Eine richtige Hürde ist es für Programmierer, deren Arbeitgeber die Zustimmung verweigert, weil das CLA dem Ubuntu-Macher eine vorteilhafte Position verschafft. Ein Fork von Snap könnte das lösen; ein solcher erfordert aber viel Ressourcen, daher wagt das niemand so schnell. Über das Für und Wider von CLAs lässt sich noch viel mehr sagen [1]. Fakt ist: CLAs wie das von Canonical waren schon bei mehreren Open-Source-Projekten (darunter OpenOffice oder Upstart) ein Faktor, der externe Entwickler abgeschreckt hat und so zum Scheitern von Projekten beigetragen hat.
Für Nutzer wiederum sind Snaps derzeit attraktiver, weil ihre Handhabung einfacher und das Paketangebot ein klein wenig größer ist. Zudem gibt es nicht nur Desktop-Apps als Snap, sondern auch Kommandozeilen-Werkzeuge und Server-Applikationen.
Fazit
Flatpaks und Snaps lösen ein Problem, das Neu-Linuxer abschreckt und plagt: Software installieren, die der Distribution fehlt. Alte Linux-Hasen nehmen das kaum noch als Problem wahr, weil sie sich daran gewöhnt haben, Anwendungen selbst zu packen oder über Pakete aus Entwicklerzweigen und Add-on-Repositories zu beschaffen. Die neuen Paketformate machen die Linux-Welt einfacher. Zusammen mit der Attraktivität für Entwickler und Firmen deutet daher einiges darauf hin, dass eines oder beide neuen Paketformate sich etablieren werden.
Beide Lösungen funktionieren schon ganz ordentlich, brauchen aber noch Feinschliff. Snap etwas mehr, denn bei unseren Gehversuchen stolperten wir mehrfach über Bereiche, an denen die Entwickler noch schrauben. Flatpak hinterließ einen reiferen Eindruck; was vor allem fehlt, ist ein grafisches Werkzeug, um die umständliche Handhabung von Flatpaks zu vereinfachen.
Wer will, kann die neuen Paketformate auf absehbare Zeit einfach links liegen lassen: Mit DEB- und RPM-Paketen geht vorerst alles weiter wie bisher. So kann man den Wettstreit der zwei locker aussitzen und abwarten, ob eine Lösung das Rennen macht oder sich beide irgendwo etablieren. (thl@ct.de)