© Feelart, 123RF

Die neuen Paketformate Flatpak und Snap wollen den alteingesessenen Linux-Paketmanagern RPM und Dpkg an den Kragen. Doch hält die Technik dahinter, was das Marketing verspricht?

Linux-Distributionen unterliegen einem steten Wandel – Admins und Anwender haben sich daran weitestgehend gewöhnt. Zu den letzten Opfern dieser permanenten Selbsterneuerung gehört auf vielen Linux-Systemen das klassische Initsystem, welches Systemd flächendeckend ersetzt hat.

Ein zentraler Mechanismus, den praktisch jede aktuelle Linux-Installation im Gepäck hat, steckt aber so tief im System, dass er scheinbar gegen jede Form radikalen Wandels immun ist: Die Rede ist von den Paketmanagements – also RPM [1] bei Red Hat und Suse sowie Dpkg [2] bei Debian und Ubuntu.

Zwar profitierten beide Standards in den vergangenen Jahren immer wieder mal von punktuellen Änderungen und Verbesserungen. Doch die Idee, eines der Paketsysteme komplett durch etwas anderes zu ersetzen, zogen weder die eine noch die andere Fraktion jemals ernsthaft als Option in Erwägung. Wahrscheinlich auch deshalb, weil eine echte Konkurrenz fehlte: RPM oder Dpkg durch die jeweils andere Lösung zu ersetzen, bringt praktisch keine Vorteile. Beide Systeme begegnen sich überall auf Augenhöhe. Am Ende stünde also viel Arbeit für wenig Lohn. Nun allerdings gibt es erstmals zwei Alternativen.

Im Doppelpack

Flatpak [3] und Snap [4] reisen im Fahrwasser der Container-Flotten. Ihre Grundidee folgt der Überlegung, dass ein Paket im Grunde ein kleines Linux-System sein kann. Es könne alle Programme und Bibliotheken enthalten, die die jeweilige Applikation braucht. Der Ansatz reduziert das Linux auf dem Hostsystem auf einen reinen Container-Hypervisor. Der beheimatet zwar noch Container, betreibt aber selbst keine Programme mehr. Stellt sich die Frage, ob das verrückt oder ein sinnvoller Ansatz ist.

Dieser Artikel geht zunächst auf die Schwierigkeiten klassischer Paketmanager ein. Danach erklärt er, wie Flatpak und Snap diese Probleme angehen – und prüft schließlich anhand zweier konkreter Beispiele, wie Maintainer Programme in Flatpaks oder Snaps verpacken und welcher Aufwand dabei entsteht.

Was soll das?

Es gibt durchaus Gründe, aus denen es Admins und Entwickler für sinnvoll erachten, die bestehenden Paketmanager abzulösen. Denn so praktisch RPM und Dpkg im Alltag sein mögen, sie sorgen bei Autoren von Software und Admins regelmäßig für graue Haare. Admins sehen sich zum Beispiel mit einem Paketsystem konfrontiert, das eher gemächlich arbeitet, selbst wenn dessen Datenbank auf flinken SSDs liegt.

Außerdem kennt praktisch jeder Admin das Problem der Dependency Hell, also der Abhängigkeiten-Hölle: Wer etwa eine LTS-Distribution nutzt, aber ein einzelnes Programm in einer neueren Version benötigt, kann nicht einfach das entsprechende Paket der nachfolgenden Distributionsversion installieren. Vielmehr muss er so genannte Backports verschiedener Bibliotheken und Pakete anlegen und diese gesammelt installieren. Das verursacht einen ziemlichen Aufwand, den auch die von den Herstellern angebotenen Backport-Verzeichnisse nur bedingt lindern.

Auch aus Sicht eines Entwicklers sind RPM und Dpkg kaum besser: Wer ein Werkzeug zugleich für Suse, Red Hat, Debian und Ubuntu anbieten möchte, muss vier einzelne Pakete herstellen und sie separat und dem jeweiligen Zyklus der Distribution folgend aktuell halten. Das ist einer der Gründe, warum viele Entwickler von vornherein nur den Quelltext ihres Programms freigeben und darauf hoffen, dass die jeweiligen Linux-Distributoren selbst ein geeignetes Paket daraus herstellen.

Passiert das nicht, sind die Admins die Leidtragenden: Sie müssen sich ein passendes Paket im schlimmsten Falle selber bauen oder das Programm aus den Quellen direkt auf dem Server übersetzen. Das jedoch war schon vor 15 Jahren verpönt, heutige Enterprise-Systeme schließen dies meist durch Richtlinien aus.

Licht am Ende des Tunnels?

Flatpak und Snap sind sehr junge Ansätze, um den typischen Problemen von RPM und Dpkg beizukommen. Wie bereits erwähnt, gehört der Container-Hype zu ihren Geburtshelfern. Mit Docker, LXC & Co. haben zwar weder Flatpak noch Snap direkt etwas zu tun, beide Lösungen setzen aber auf verschiedene Funktionen des Linux-Kernels, die auch bei Docker & Co. im Einsatz sind. Eine strikte Trennung von Gast- und Hostsystem erreichen sie etwa über Cgroups [5] und Namespaces [6].

Die Paketformate, die bei Flatpak und Snap so wie das Paketsystem heißen, bringen ihr eigenes Userland mit. In ihm siedeln nicht nur das Programm selbst, sondern auch sämtliche Bibliotheken und Hilfswerkzeuge, die das Programm zum reibungslosen Einsatz benötigt. Die Trennung von Host und Gast ist elementar: Andernfalls kämen Bibliotheken des Hostsystems möglicherweise denen auf dem Gastsystem ins Gehege, sodass das Programm nicht liefe.

Flatpak und Snap liefern jeweils ein eigenes Steuerprogramm mit, das auf dem physischen Host läuft und eine Art Brückenfunktion übernimmt. Zwar agieren die in Snaps oder Flatpaks verpackten Programme grundsätzlich separat vom Rest des Systems, aber Zugriff auf diverse Hostdateien brauchen sie dennoch. Sie müssen zum Beispiel die eigene Konfigurationsdatei auslesen, die meist in »/etc« oder im Home des ausführenden Nutzers liegt. Sowohl Snap als auch Flatpak definieren deshalb interne Schnittstellen, über die der Zugriff auf externe Ressourcen gelingt.

In der Theorie klingen die Ansätze von Flatpak und Snap gut – aber wie sieht der Alltag mit den Werkzeugen aus? Zwei einfache Beispiele beschreiben, wie ein Entwickler oder Admin ein Snap sowie ein Flatpak erzeugt und anschließend an die Nutzer verteilt.

Flatpak: Die wichtigsten Begriffe

Wer seine Applikation in eine Flatpak-Datei verpacken möchte, sollte zunächst die zentralen Begriffe kennen, die im Flatpak-Universum zu Hause sind. Da gibt es zunächst die Runtime: Sie ist nicht Teil eines Flatpak, sondern eine externe Komponente, die Flatpak einbindet. De facto handelt es sich also um ein Grundsystem mit den wichtigsten Dateien und Bibliotheken, das der Hersteller zentral wartet und das beliebig viele Flatpaks nutzen (Abbildung 1).

Abbildung 1: Bei Flatpaks kommen alle generischen Daten aus der Runtime – das Flatpak selbst enthält nur die App und notwendige Bibliotheken.

Sandbox, also Sandkasten, heißt der Container, in dem die Flatpak-App läuft. Die Entwickler vermeiden Container als Begriff, weil er Vergleiche mit Docker [7] oder LXC [8] nahelegt. Von ihnen grenzt sich Flatpak aber bewusst ab. Das ändert nichts daran, dass die Sandbox die virtuelle Umgebung ist, die auf dem Hypervisor läuft und innerhalb derer die Applikation werkelt. Die Sandbox trennt sie dabei von den anderen Flatpaks oder dem Hauptsystem.

Gebündelte Bibliotheken (bundled Libraries) sind Teil der Sandbox. Die Applikation im Flatpak braucht sie zwar, dennoch stecken auch sie nicht in der Runtime. Vielmehr muss sie der Flatpak-Autor beisteuern, indem er sie in das Flatpak integriert.

Zentral ist auch der Begriff des SDK: Das ist im Flatpak-Sprech praktisch das Gleiche wie eine Runtime, jedoch enthält das Software Development Kit die Entwicklungsdateien. Der Entwickler baut das Flatpak also gegen eine bestimmte SDK-Version, und diese läuft später zuverlässig mit der Runtime, die zu genau jenem SDK gehört. Wer Apps in Flatpaks verteilen möchte, muss also das richtige SDK festlegen.

Los geht’s

Flatpak eignet sich insbesondere für Desktop-Applikationen, etwa weil es auf zentrale Funktionen wie D-Bus für die Kommunikation mit der Außenwelt setzt. Im Beispiel kommt deshalb eine Variante von “Hello World” zum Einsatz, die das bekannte Programmierbeispiel per D-Bus absetzt [9].

Dafür braucht der Tester zunächst Flatpak: Arch-Linux und Fedora kommen ab Werk mit einem entsprechenden Paket. Das spielt er auf der Kommandozeile ohne weitere Vorarbeit ein. Auch Debian Testing bringt ein »flatpak«-Paket mit, ein entsprechender Backport für Debian Jessie steht ebenfalls bereit [10]. Auch für Open Suse Tumbleweed warten Pakete des Herstellers [11] auf die Nutzer.

Wer Ubuntu verwendet, findet die Pakete in einem PPA des wesentlichen Flatpak-Autors auf Ubuntus Codeplattform Launchpad und bindet sie über die folgenden drei Befehle ein:

sudo add-apt-repository ppa:alexlarsson/flatpak
sudo apt update
sudo apt install flatpak

Sind Flatpak installiert und das »flatpack«-Programm verfügbar, legt der Entwickler ein nacktes Verzeichnis für ein neues Flatpak an:

flatpak build-init helloworld org.example.HelloWorld org.gnome.Sdk org.gnome.Platform 3.22

Die einzelnen Parameter hinter »build-init« haben jeweils eine eigene Bedeutung: »helloworld« gibt den Verzeichnisnamen an, innerhalb dessen das Flatpak entsteht, »org.example.HelloWorld« definiert den D-Bus-Namen, den das Flatpak später für die Kommunikation mit D-Bus verwendet. Das SDK und die Runtime, die das Flatpak nutzt, legen »org.gnome.Sdk« sowie »org.gnome.Platform« fest, während »3.22« deren Versionsnummer bezeichnet.

Wer Flatpaks für andere Programme baut, passt die entsprechenden Werte an – es empfiehlt sich anfangs jedoch, auf das SDK und die Runtime von Gnome zurückzugreifen, denn die sind ausgiebig getestet und reichen für die meisten alltäglichen Anwendungen völlig aus.

Das eigentliche Programm

Der nächste Schritt ergänzt das Flatpak um sein eigenes Programm. Dabei kommt der Befehl »flatpak build« sehr gelegen, mit ihm führt der Paketbauer in der Flatpak-Buildumgebung beliebige Befehle aus. Ein

flatpak build helloworld touch /app/test

etwa legt eine Datei »test« im App-Verzeichnis des Flatpak an. Auf die gleiche Weise lässt sich im Flatpak auch ein Programm kompilieren. Zunächst lädt der Entwickler die Quellen von [9] herunter und entpackt sie. Dann wechselt er über »cd« in den Ordner mit entpackten Quellen und gibt dort die Befehle

flatpak build Flatpak-Ordner gcc $(pkg-config --cflags dbus-1 glib-2.0) -o send-hello dbus-send-hello.c $(pkg-config --libs dbus-1 glib-2.0)

ein. Hinter »Flatpak-Ordner« verbirgt sich der relative Pfad zum eben per »flatpak build-init« angelegten Verzeichnis.

Im nächsten Schritt legt der Paketbauer das Flatpak an:

flatpak build-finish helloworld --socket=x11 --share=network --command=send-hello --socket=system-bus --socket=session-bus

Die Parameter »–socket=x11« und »–share=network« ermöglichen der Flatpak-App den Zugriff auf X11 und das Netzwerk, was im konkreten Beispiel zwar nicht nötig ist, bei den meisten anderen Applikationen allerdings schon. Im nächsten Schritt führt der Baumeister Flatpak mit Hilfe der Befehle aus Listing 1 schließlich aus.

01 flatpak build-export repo helloworld
02 flatpak --user remote-add --no-gpg-verify --if-not-exists example-repo repo
03 flatpak --user install example-repo org.example.HelloWorld
04 flatpak run org.example.HelloWorld

Die vier Befehle legen ein Flatpak-Repo auf Basis des lokalen Flatpak an, fügen es in die Flatpak-Repository-Konfiguration ein, installieren das Flatpak aus dem Repo und führen es schließlich aus. Der Mühe Lohn ist eine Hello-World-Meldung im D-Bus-Logfile des Hostsystems.

Mächtiges Werkzeug

Das vorgestellte Beispiel demonstriert nur das Minimum des Möglichen. Wie das Paketsystem weitaus komplexere Applikationen in einem Flatpak verstaut, zeigt mit mehreren Beispielen anschaulich die Flatpak-Website [12]. Bemerkenswert ist, wie fein die Entwickler die Rechtevergabe granuliert haben: Pro Flatpak legt der Paketmacher fest, ob seine Software Zugriff auf X11, Wayland, D-Bus oder einzelne Ordner innerhalb des Host-Dateisystems wünscht oder nicht. Auch den Zugriff auf Audiogeräte steuert er so präzise.

Wer sich mit Flatpak an komplexere Beispiele heranwagt, stößt auch auf »flatpak-builder«: Trotz der Namensähnlichkeit zum erwähnten »flatpak build« handelt es sich um ein separates Werkzeug. Denn »flatpak-builder« greift die Informationen aus einer Json-Datei auf, die der Admin zuvor angelegt hat, und baut ein Flatpak auf deren Basis komplett automatisch.

In der Json-Datei hinterlässt der Autor im Wesentlichen die gleichen Informationen, die er zuvor auf der Kommandozeile an »flatpak build« übergeben hat. Das Tool erweitert das Prinzip also um eine Art Batchmodus, der sich in der Praxis als sehr nützlich erweist (Abbildung 2).

Abbildung 2: Anstelle des komplizierten Kommandozeilen-Limbos lässt sich alternativ ein Flatpak auch aus einer Json-Datei herstellen.

Detail-Differenzen: Snap

Anders als Flatpak richtet sich Snap nicht vorrangig an Desktop-Nutzer. Mit dem Werkzeug möchte Canonical eher den Weg, den Enterprise-Applikationen auf die Server der Admins zurücklegen, revolutionieren. Wie Flatpak setzt auch Snap auf die verschiedenen Isolationstechniken des Kernels und kombiniert sie so miteinander, dass die Applikationen in eigenen, virtuellen Umgebungen laufen.

Der Aufbau eines Snap unterscheidet sich nicht fundamental von dem eines Flatpak – lediglich die Begriffe tragen einen anderen Namen. Anstelle einer Runtime ist bei Snap von einem Framework die Rede. Gemeint ist letztlich aber auch hier ein grundlegender Satz an Bibliotheken, auf denen Snap aufbauen kann. Der Rest kommt – wie bei Flatpak – dem Admin als Arbeit zu.

Anders als Flatpack richtet sich Snap aber nicht so sehr an General-Purpose-Systeme. Canonical entwickelt parallel zu Snap ein auf den Namen Snappy Ubuntu Core [13] getauftes Basissystem, das verschiedene Frameworks anbietet und darüber hinaus eine Linux-Basisdistribution ist – letztlich also so etwas wie ein Micro-Linux (Abbildung 3).

Abbildung 3: Das Design von Snap ähnelt dem von Flatpak grundsätzlich, wobei Snaps vornehmlich auf Systemen mit Snappy Ubuntu Core zum Einsatz kommen dürften.

Yaml-Dateien als Grundlage

Flatpak bietet per »flatpak-builder« die Möglichkeit, ein Pak auf Basis einer Json-Datei zu erstellen. Snap ermöglicht diese Option auch, hier ist aber das Yaml-Format Standard. In einer Yaml-Datei definiert der Admin diverse Keywords und Absätze und verfüttert die Datei an Snapcraft [14], das aus den Informationen ein fertiges Snap baut.

Snapcraft ist ziemlich schlau: Wer ein Programm aus den Quellen übersetzen will, das die GNU Autotools nutzt, findet ein entsprechendes Snap-Plugin für Autotools vor. Über die eingebaute Plugin-Schnittstelle rüstet der Admin diverse Funktionalität nach, die im Kern von Snap fehlt. Das Autotools-Plugin sorgt etwa dafür, dass beim Übersetzen eines Quelltextes in Binärcode der bekannte Dreischritt »./configure«, »make« und »make install« funktioniert. Es übergibt an »configure« auch die richtigen Parameter, sodass die Applikation später innerhalb des Snap problemlos läuft.

Über weitere Schlüsselwörter wie »name«, »version« und »summary« legt der Snap-Erzeuger fest, unter welchem Namen das Snap später im System erscheint und um welche Version es sich handelt. Von besonderer Bedeutung ist das Schlüsselwort »confinement«: Zur Wahl stehen hier »strict« oder »devmode«, das erste ist der Standardwert und trennt das Snap strikt vom Rest des Systems. Für produktive Snaps ist »confinement: strict« quasi vorgeschrieben. Ein fertiges Yaml-File für ein »Hello World«-Snap könnte also wie in Listing 2 aussehen.

01 name: hello
02 version: "2.10"
03 summary: GNU Hello, the "hello world" snap
04 description: GNU Hello prints a friendly greeting
05 confinement: strict
06
07 apps:
08   hello:
09     command: hello
10
11 parts:
12   gnu-hello:
13     plugin: autotools
14     source: http://ftp.gnu.org/gnu/hello/hello-2.10.tar.gz

Wer Snaps von komplexeren Programmen baut, erweitert den Abschnitt »parts«: Braucht das Programm etwa Abhängigkeiten in Form von Bibliotheken, trägt der Admin diese in entsprechender Reihenfolge in das Yaml-File ein.

Das Snap bauen

Die angelegte Datei sollte unter dem Namen »snapcraft.yaml« in einem für diesen Zweck angelegten Verzeichnis liegen. Um das Snap zu bauen, gibt der Admin innerhalb des Verzeichnisses den Befehl »snapcraft« ein. Das passende Paket »snapcraft« sollte er zuvor installiert haben. Auf Ubuntu-Systemen findet er es im offiziellen Archiv, für andere Distributionen warten unter [15] Anweisungen zur Installation. Snapcraft gibt es für Fedora wie auch für Open Suse.

Im Anschluss an den Snapcraft-Aufruf findet sich im Arbeitsverzeichnis eine Datei, deren Namen auf ».snap« endet. Um das Snap auf einem System auszuführen, braucht das System den Snap-Daemon Snapd. Dessen Installation beschreibt ebenfalls [15]. Läuft Snapd, installiert der Admin das Snap über:

sudo snap install *.snap --dangerous

Kritische Zeitgenossen stoßen sich womöglich an dem Parameter »–dangerous«. Keine Panik: Damit weist der Admin Snap nur an, die eingebaute Signatur-Überprüfung zu umgehen. Die stellt ansonsten sicher, dass nur Snaps aus Quellen auf dem System landen, denen der Admin ausdrücklich vertraut.

Das vorgestellte Beispiel kratzt nur an der Oberfläche dessen, was mit Snap möglich ist. Auf der Website des Programms [16] wartet eine äußerst ausführliche Dokumentation, die Licht auf die Möglichkeiten und Optionen wirft. Wer sich mit Snaps und dem Bauen eigener Snaps intensiver befassen möchte, findet hier einen guten Einstieg.

Das Interfaces-System

Wie Flatpak steht auch Snap vor der Herausforderung, dass eine komplett vom Rest des Systems abgeriegelte Container-App nur bedingt nützlich ist. Um sich in den normalen Workflow einzufügen, braucht sie mindestens Zugriff auf das persönliche Verzeichnis eines Nutzers. Freilich hat Snap auch für dieses Problem eine Lösung: die so genannten Interfaces. Diese kommen auf Ebene von Snapd zum Einsatz und bieten standardisierte Schnittstellen für verschiedene Arten von Diensten.

Über das »home«-Interface bekommt ein Snap etwa Zugriff auf die Ordner von Nutzern. Das »dbus«-Interface ermöglicht Zugang zum D-Bus auf dem Hostsystem. In der Riege der Interfaces finden sich auch manche Exoten: Etwa »camera«, über das ein Snap auf eine angeschlossene Kamera zugreift. Oder »tpm«, über das sich ein TPM-Modul ansteuern lässt. Eine aktuelle Liste der verfügbaren Interfaces finden Admins unter [17].

Nachgedacht haben die Snap-Entwickler überdies über die Kommunikation von Snaps untereinander. Eine Applikation, die einen Service anbietet, kann in ihrer Yaml-Definition einen »Slot« festlegen – etwa eine MySQL-Datenbank. Ein anderes Snap kann wiederum ein »Plug« definieren, das sich schließlich mit dem zuvor festgelegten »Slot« verbindet (Abbildung 4).

Abbildung 4: Die Kommunikation zwischen Snaps findet über Plugs und Slots statt, die die Snaps jeweils in ihrer Yaml-Definition benennen.

Der große Unterschied: Ein fertiges Online-Repository

Der markanteste Unterschied zwischen Flatpak und Snap besteht gegenwärtig darin, dass Canonical für Snap bereits einen Online-Marktplatz für fertige Snaps betreibt (Abbildung 5). Unter [18] finden sich Snaps, die Administratoren und Entwickler zu ganz verschiedenen Themen gebaut und in den Canonical-Store hochgeladen haben.

Abbildung 5: Im Snap-Store finden sich schon heute diverse fertige Snaps, die Nutzer per Mausklick installieren können.

Dass sich Snaps dabei nicht auf Serverapplikationen beschränken, zeigen so prominente Beispiele wie etwa der Videospieler VLC. Das erklärt auch die zuvor bereits erwähnte Signaturfunktion: Sämtliche Snaps, die in Canonicals Snap-Store landen, signiert der Ubuntu-Anbieter digital – der Benutzer darf sich also sicher sein, dass er seine Snaps aus einer sicheren Quelle bezieht. Ein entsprechendes Pendant ist bei Flatpak aktuell nicht zu sehen.

Fazit

Flatpak und Snap rütteln am Prinzip des Paketsystems und damit an einer der Grundfesten sämtlicher aktuellen Linux-Distributionnen. Auf den ersten Blick klingt die Idee dahinter auch uneingeschränkt sinnvoll: Wer ständig mit Backports hantiert oder schon einmal händisch Paketabhängigkeiten auflösen musste, findet die Vorstellung von eigenständigen Containern mit einer Applikation sicher reizvoll.

Bei genauerem Hinsehen stellt sich aber heraus, dass das Prinzip manch scharfe Kante hat. So verfolgen Snap und Flatpak ähnliche Ziele und sind im Grunde konkurrierende Ansätze. Zwar besteht Fedora als treibende Kraft hinter Flatpak darauf, dass das Paketsystem eher auf Desktops zu Hause sei, während Canonical als Snap-Erfinder auf die Vorteile von Snaps auf Servern anpreist.

De facto wiederholt sich bei Snap und Flatpak genau jene Spaltung, die sich mit RPM und Dpkg seit Jahrzehnten quer durch die Linux-Welt zieht. Sinnvoller wäre es, sich auf einen gemeinsamen Ansatz zu einigen und diesen zu verfolgen. Das aber scheint aussichtslos.

Ebenfalls problematisch ist, dass der flächendeckende Einsatz von Snap oder Flatpak die Art und Weise ändern würde, in der Admins Linux nutzen. Denn das Hostsystem wäre dann kaum viel mehr als ein Container-Host, auf dem der Admin nach Belieben Apps in Containern ausrollt. Dafür braucht es keine ausgewachsene Server-Distribution wie SLES, RHEL oder Ubuntu. Stattdessen schlägt in solchen Setups die Stunde der Mikro-Linux-Distributionen – Core OS & Co. lassen grüßen.

Zugleich geht implizit aber auch ein gehöriger Teil der Verantwortung auf die Bauer von App-Containern über, der bisher bei den Linux-Distributoren lag: Beziehen Admins ihre Apps direkt von verschiedenen Herstellern, kann etwa der Linux-Distributor kaum sinnvoll Sicherheitsupdates ausrollen. Ein Bug in einer zentralen Bibliothek wie SSL würde dazu führen, dass die Anbieter diverser Applikationen so schnell wie möglich ihre App-Container aktualisieren und zum Download anbieten müssen.

Ob sich Flatpak oder Snap oder zumindest das den beiden immanente Prinzip der Applikation als Container durchsetzt, hängt also auch davon ab, wie gut die Anbieter solcher Apps ihre Hausaufgaben machen. Die Erfahrungen der jüngeren Vergangenheit lassen nichts Gutes vermuten: Einer der größten und immer wieder vorgebrachten Kritikpunkte an Docker ist ja, dass die über diverse Kanäle angebotenen Container aus Admin-Sicht Blackboxes sind, über deren Inhalt keine verlässliche Aussage möglich ist – die sich also bei Bedarf auch nicht einfach reproduzieren lassen. Bis das geklärt ist, wird aber noch eine ganze Zeit vergehen. Insofern schadet es sicher nicht, sich schon jetzt mit Flatpak oder Snap auseinanderzusetzen.