CleanPress

Schlagwort: Flatpak

  • Ubuntu Snaps – das Sandbox-Modell

    Ubuntu Snaps
    Bild: Sandbox | Quelle: Simon Law Lizenz: CC BY-SA 2.0

     

     

    Canonical hat mit Ubuntu Snaps ein Paketformat entwickelt, das seine Vorteile hauptsächlich im Internet der Dinge und in eingebetteten Systemen ausspielen soll, aber auch auf dem Desktop zunehmend Verbreitung findet. Durch seine plattform-unabhängige Eigenständigkeit erlaubt es beispielsweise das Testen von aktuellen Versionen von Software, die unter der verwendeten Distribution noch nicht verfügbar sind. Entwickler können damit ihre Software in ein Paket stecken, das auf allen Plattformen lauffähig ist, die das Snap-Format unterstützen.

    Ubuntu Snaps im Sandkasten

    Aus Sicherheitsgründen arbeiten Snaps, wie auch das alternative Flatpak-Format in sogenannten Sandboxen. Das bedeutet, die Anwendung ist eingesperrt und erhält nur die notwendigen Zugriffe auf das Gast-System. Aus Entwicklersicht gibt es drei Stufen der Beschränkung, die mit Devmode, Classic und Strict betitelt sind. Was der Endanwender erhält, wenn er ein Snap aus der Abteilung Stable des Ubuntu-Snap-Store installiert, entspricht immer Strict.

    Strict-Mode

    Snaps, die nach dem Strict-Mode erstellt wurden können ohne manuelle Überprüfung in den Store hochgeladen werden. Das Strict-Modell beschränkt eine Applikation mittels Sicherheitsfunktionen des Kernels. Werden hier keine Ausnahmen definiert, hat die App keinerlei Zugriff auf das System. Diese Ausnahmen heißen Interfaces und stellen Schnittstellen für den Zugriff der App auf definierte Bereiche des Gast-Systems dar.

    Devmode

    Um funktionierende Ubuntu Snaps zu erstellen, in denen diese Schnittstellen der kasernierten App die nötigen Zugriffe erlauben, steht Entwicklern der Devmode zur Verfügung. Mit dieser Einstellung erstellte Snaps sind zunächst nicht in ihrem Zugriff beschnitten, der Entwickler kann also beim Testen Schnittstellen suchen, die den nötigen Zugriff erlauben und den Rest einschränken. Wird eine noch nicht definierte Schnittstelle benötigt, kann der Entwickler diese per Bugreport anregen. Snaps im Devmode können lediglich in den Kanälen Edge und Beta veröffentlicht werden und stehen somit zur Durchsicht und Qualitätssicherung bereit.

    Classic-Mode

    Das Modell Classic bietet der Anwendung in einem Snap alle Zugriffe auf das System, die auch eine Anwendung ohne Snap-Beschränkung hat. Dieser Modus bietet Entwicklern die Möglichkeit, Anwendungen als Snap auszuliefern, die noch nicht als Schnittstelle definierte Zugriffe benötigen. Stehen diese Schnittstellen später zur Verfügung, kann der Entwickler auf Strict wechseln.

    Snaps nach dem Classic-Modell werden manuell überprüft bevor sie im Stable-Channel des Ubuntu-Snap-Store veröffentlicht werden. Sie dürfen allerdings keine Verwendung im Ubuntu-Core finden. Anwender haben bei der Installation eines Snap die Möglichkeit, das vom Entwickler vorgegebene Level an Beschränkung zu übergehen, indem sie etwa den Schalter -classic verwenden. Das ist allerdings nicht ratsam, denn es entfernt alle definierten Interfaces und erlaubt der Anwendung ungehinderten Zugriff.

    Mehr zu diesem Thema vermitteln ein Blogeintrag von Alan Pope, nochmals vertieft in der Snapcraft-Dokumentation.

     

  • Flatpak strebt Version 1.0 an

    Flatpack 1.0
    Quelle: NeONBRAND auf Unsplash

    Das im Umfeld von Fedora und GNOME entwickelte alternative Paketsystem Flatpak strebt die Version Flatpak 1.0 an, die gemeinhin die Reife für den produktiven Einsatz signalisiert. Dazu hat Hauptentwickler Alex Larsson nun Flatpak 0.99.1 als ersten Release-Kandidaten zu 1.0 veröffentlicht. Bis zur Veröffentlichung der stabilen 1.0 sollen nur noch Fehler beseitigt, aber keine neuen Funktionen mehr hinzugefügt werden. In den Archiven der Distributionen befindet sich noch eine ältere stabile Version, meist 0.11.8.

    P2P als Update-Option

    Die neue Version 0.99.1 setzt Ostree 2018.6 voraus, womit P2P als alternative Update-Option für Flatpak standardmäßig aktiv und nicht mehr, wie bisher,  optional ist. Die Befehle install, update und uninstall listen nun zunächst alle auszuführenden Operationen auf, bevor sie die Erlaubnis zum Start abfragen. Durch weniger fsync-Aufrufe sollen systemweite Installationen schneller als bisher ablaufen.

    Für Anwender und Entwickler

    Flatpak ist neben Ubuntus Snap ein alternatives Paketsystem, das Anwender in die Lage versetzt, mit wenigen Mausklicks aktuelle Software in Versionen zu installieren, die in den Distributionen noch nicht verfügbar ist. Dabei können zusätzlich zu einer per Paketmanagement installierten Version nebeneinander mehrere Versionen der Software installiert werden. Davon profitieren unter anderem auch Entwickler, die mehrere Versionen einer Software testen möchten. Zudem sind die Pakete über die Grenzen von Distributionen hinaus einsetzbar.

    Vor- und Nachteile

    Den neuen Formaten werden aber auch negative Punkte angelastet. So sind die neuen Pakete wesentlich größer als die Anwendung selbst, die sie ausliefern. Das kommt durch die im Paket enthaltenen Bibliotheken und weitere zur Ausführung benötigte Dateien. Diese werden bei mehreren installierten Paketen auch schon mal multipliziert. Bei den heutigen Kapazitäten von Festplatten und fetten Internetleitungen liegt hier das Problem eher in der duplizierten Datenhaltung. Nicht zu vergessen ist dabei die Aktualisierung dieser Pakete mitsamt ihren Abhängigkeiten. Ist eine grundlegende Bibliothek kaputt, muss sie in allen Paketen, in denen sie enthalten ist, aktualisiert werden.

     

  • Flathub-Webseite im neuen Gewand

     

    Flathub-Webseite
    Quelle: NeONBRAND auf Unsplash

     

    Vor einem halben Jahr haben wir die Flathub-Webseite als zentrale Stelle zum Sammeln von Flatpaks verschiedener Herkunft vorgestellt. Flatpak ist ein Paketformat ähnlich wie Snap bei Ubuntu, das sich unter allen Distributionen installieren lässt. Flathub dient dabei sozusagen als Flatpak-App-Store. Allerdings ließ im September das Design der Seite noch sehr zu wünschen übrig. Das hat sich nun mit einem durchgehehenden Neudesign grundlegend geändert.

    Neue Flathub-Webseite

    Das Suchen und Stöbern, das Installieren oder das Hochladen eigener Flatpaks ist dank des neuen übersichtlichen Designs wesentlich intuitiver und einfacher geworden. Eine Leiste am linken Rand der Seite unterteilt den Bestand an Apps in Kategorien. Zuoberst lädt eine Unterteilung in die Sparten Popular, New & Updated, Editor’s Choice und Editor’s Choice Games zum Entdecken ein.

    1-Klick-Installation

    Darunter lädt eine Einteilung in zehn Kategorien zum gezielteren Suchen ein. Soll festgestellt werden, ob sich eine bestimmte Anwendung bereits im Flatpak-Format im Shop findet, steht oben rechts das Suchfeld zur Verfügung. Ist eine interessante App ausgemacht, so führt ein Klick darauf zu einer ausführlichen Beschreibung des Objekts der Begierde. Ein Install-Button lädt dann zur 1-Klick-Installation ein.

    [su_slider source=“media: 4770,4771″ link=“image“ width=“700″ height=“460″ mousewheel=“no“ autoplay=“0″ speed=“0″]
    Als Voraussetzung, damit das gelingt,  muss die Flatpak-Software auf dem Rechner installiert sein. Diese ist zumindest bei Fedora, Arch, Mageia und OpenSUSE bereits vorinstalliert. Bei Debian und Ubuntu muss noch ein wenig nachgeholfen werden. Bei Debian reicht ein beherztes apt install flatpak aus. Unter Ubuntu lautet der Befehl apt install flatpak gnome-software-plugin-flatpak. Dabei wird auch gleich Unterstützung für Flatpak in der Anwendung Gnome-Software installiert. In beiden Fällen muss Flathub dem System als Quell-Repository bekannt gemacht werden. Dafür sorgt der Befehl
    flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo

    Unter Ubuntu 17.10 funktioniert die Installation per Klick von der Flathub-Webseite nicht, hier kann die Anwendung GNOME-Software oder die Kommandozeile benutzt werden. So installiert etwa als User der Befehl

    flatpak install com.spotify.Client.flatpakref


    den Spotify-Client. Selbst erstellte Flatpaks können ebenfalls recht einfach auf Flathub hochgeladen werden. Hinter dem Button Publish findet sich eine ausführliche Anleitung. Nähere Informationen zum Flatpak-Paketformat bietet dieser Artikel.

  • Multimedia-Framework PipeWire auf gutem Weg

    Multimedia-Framework PipeWire
    Bild: Fedora

     

    Fedora 27 lieferte erstmals das neue Multimedia-Framework PipeWire aus. Die Anwendung soll für Audio und Video das leisten, was heute PulseAudio heute für Audio zu bieten hat. Darüber hinaus sollen auch professionelle Szenarien unter Einbeziehung des Soundservers Jack abgedeckt werden, die über die Funktionalität von PulseAudio hinausgehen. Begonnen hat die Entwicklung bereits vor einigen Jahren.

    GStreamer als Vorbild

    Entwickler Wim Taymans, der für Red Hat arbeitet, hatte bereits bei der Entwicklung von GStreamer federführend mitgearbeitet. Mit dem Aufkommen des alternativen Paketmodells Flatpak suchte er nach einer Möglichkeit, diesen Desktop-Containern – denn nichts anderes ist Flatpak – die Soundausgabe per PulseAudio zu ermöglichen. Im Anschluss begann er die Arbeit an PulseVideo, um das Gleiche auch für Bewegtbilder umzusetzen.

    Im Endeffekt fiel die Entscheidung, Audio und Video in einem Framework zu bündeln, das den Namen PipeWire erhielt. Jetzt hat Red-Hat-Kollege Christian Schaller die gerade stattfindende Fedora-Entwicklerkonferenz DevConf 2018 im tschechischen Brno zum Anlass genommen, anlässlich eines Gesprächs mit Wim Taymans über die Fortschritte bei PipeWire in seinem Blog zu berichten.

    Flatpak und Wayland profitieren

    Mittlerweile sind es nicht nur mehr Flatpak oder Container im Allgemeinen, die auf ein modernes Framework angewiesen sind, um den Zwängen einer Sandbox gerecht zu werden und containerisierten Anwendungen die Ausgabe von Audio und Video über den Host trotzt Restriktionen zu ermöglichen. Auch Wayland braucht im Bereich Multimedia neue Lösungen, will es die Funktionalität von Xorg besser abdecken.

    Das Anzeige-Protokoll Wayland ist mit mehr Augenmerk auf Sicherheit konzipiert als das rund 30 Jahre alte Netzwerkprotokoll X11. Aus diesem Grund wurde auch standardmäßig keine Netzwerktransparenz implementiert. Das bedeutet, dass das Wayland-Protokoll von Hause aus heute selbstverständliche Dinge wie Screensharing und -recording oder Remote Desktop per RDP oder VNC nicht unterstützt. Es gibt Anstrengungen,  auch für Oberflächen von Wayland-Anwendungen die Verwendung über das Netzwerk zu realisieren. Eine davon nennt sich Waltham und wird bei Collabora entwickelt. Hier geht es aber in erster Linie vorerst nicht um den Desktop, sondern um den Automobilbereich.

    Screensharing und Remote Desktop

    Eine weitere Entwicklung in diese Richtung, die wiederum PipeWire ins Spiel bringt, wird von Red Hats Jonas Ådahl vorangetrieben und soll diese Funktionalität für GNOME zurückbringen. Da die Funktion im Compositor verankert ist, wird sie auch von anderen Desktop-Umgebungen nutzbar sein, die Wayland einsetzen. Das ist zwar alles noch im experimentellen Stadium, aber PipeWire beherrscht bereits rudimentär das Teilen von Geräten, wie Entwickler Taymans am Beispiel der Videoanwendung Cheese und PipeWire im Terminal demonstrierte. Zwei Anwendungen teilen sich dabei eine Webcam ohne sich gegenseitig zu stören. Dabei kommt ein PipeWire-GStreamer-Plugin zum Einsatz, was die Anpassung an die jeweilige Anwendung übernimmt.

    Als Nächstes soll PipeWire zeitnah an Firefox und Chrome angepasst werden um Konferenzsoftware damit unter Wayland lauffähig zu bekommen. Der Sound-Server Jack für professionelle Ansprüche wie etwa geringe Latenzen wurde mittlerweile als Protokoll auf PipeWire draufgesetzt, sodass kein extra Jack-Server mehr vonnöten ist. Auf der Cosumer-Seite ist Bluetooth-Untzerstützung gegeben, wobei ein PipeWire-Bluetooth-Modul sich direkt mit dem  Bluez-Bluetooth-Framework verbindet.

    Aussichten

    PulseAudio-Applikationen sollen nach den Plänen der Entwickler zunächst Sound über PipeWire ausgeben. Für GStreamer-Apps stellt sich die Frage nicht, da sie nativ PipeWire nutzen. Für Apps, die noch ALSA verlangen, soll es ein PipeWire-ALSA-Layer geben so wie es jetzt ein PulseAudio-ALSA-Layer gibt. PulseAudio soll im späteren Verlauf einmal überflüssig werden, was jedoch einige Jahre dauern wird. Für das im Mai anstehende Fedora 28 soll zumindest der Video-Part ausgeliefert werden, weitere Schritte sollen mit den nächsten Veröffentlichungen folgen.

     

  • Flatpak von innen

    Installation per Flatpak-Hub
    Screenshot: FThommes

    Flatpak ist grundsätzlich ein Bündelungssystem, und als solches hat es im Vergleich zu anderen Paketsystemen den Nachteil des prinzipbedingt größeren Umfangs. Nach Meinung von GNOME- und Flatpak-Entwickler Alexander Larsson kompensieren die Vorteile der Bündelung aber die Nachteile. In einem Blogpost erklärt er, was in der Entwicklung gegen das Aufblähen getan wird.

    Maßnahmen gegen Bloat

    Bereits das Grundgerüst der Flatpak-Infrastruktur versucht, Bloat zu vermeiden. Das geschieht durch die Aufteilung in Laufzeitumgebung und Anwendungen. Das bedeutet, dass Anwendungen nicht alles bündeln müssen und dass gemeinsame Abhängigkeiten zwischen verschiedenen Anwendungen geteilt werden.

    Bei der Konzeption von Flatpak war die Eindämmung von Bloat allerdings nicht das Hauptargument für den Einsatz von Laufzeitumgebungen. Dabei ging es vordergründig um Dinge wie Wartung, gemeinsame Eigentümerschaft und darum, Kernfunktionalitäten separat veröffentlichen zu können. Hier stehen  beispielsweise Sicherheitsaktualisierungen im Fokus, die Anwendungsautoren weder beherrschen noch Interesse daran haben.

    OSTree ist mit Git vergleichbar

    Für die Anwendungsspeicherung nutzt Flatpak ein System namens OSTree, welches durch Deduplikation auf Dateiebene bereits eine Doppelung von Daten verhindert. Larsson versucht OSTree zu erklären, wenn er sagt:  »Es ist wie Git, aber für Verzeichnisse mit großen Binärdateien«. Für Flatpak bedeutet das, dass jede Runtime (es können mehrere installiert sein) und jede Anwendung einen Zweig in einem OSTree-Repository darstellen, der einem Git-Branch entspricht. Dabei sind alle Verzeichnisse und Dateien, vereinfacht dargestellt, mit IDs versehen. Alle identischen Dateien werden so erkannt und dabei zwischen den Anwendungen geteilt. Das entlastet nicht nur RAM und Plattenplatz sondern spart Bandbreite beim  Download.

    Effektive Einsparung

    Dass das effektiv funktioniert, zeigt das Beispiel der beiden Laufzeitumgebungen von GNOME und freedesktop.org. Letztere hat eine Größe von 435 MByte, die von GNOME wirft 665 MByte in die Waagschale. Dabei ist die GNOME-Runtime eine Kopie der Runtime von freedesktop.org mit einigen entfernten und einigen hinzugekommenen Dateien.

    Wird die GNOME-Runtime zusätzlich zu der von freedesktop.org installiert, werden lediglich 18 MByte mehr belegt anstatt 230 MByte. Das gleiche gilt für die KDE-Runtime und weitere, unter Umständen auch selbst erstellte Laufzeitumgebungen. Auch die Installation von x86-64- und i386-Builds der GNOME-Laufzeitumgebung spart 220 MByte ein.

     

  • Ubuntu Snappy für Android vorbereitet

    Ubuntu-Snaps
    Bild: Canonical

    Ubuntu veröffentlicht in kurzen Zeitabständen neue Versionen des Daemons Snapd, der eine REST-Api zum Management von Snaps darstellt. Snaps sind, ähnlich wie Flatpak ein neues Paketformat, das unabhängig von Distributionen, seine benötigten Abhängigkeiten mit sich führt. Jetzt wurde snapd 2.27 veröffentlicht und bringt Unterstützung für den Android-Bootvorgang.

    Unterstützung für Android-Bootsequenz

    Das eröffnet für Ubuntu und Snappy die Möglichkeit neuer Geräte, die ihre Software als Snaps mitführen und transaktionale Updates des Betriebssystems und des Kernels sowie bei Problemen automatisches Rollback auf die vorherige Version bieten. Diese Funktionalität prädestinierte Snaps bisher bereits für das Internet der Dinge. Geräte wie Router, Switches und Apps für Heimautomation wie der intelligente Kühlschrank, die oft in ihrer gesamten Lebenszeit nie ein Update erfahren, können so mit aktueller Firmware versorgt und auf neue Bedrohungen vorbereitet werden. 

    Dynamische Dateisystem-Aktualisierung

    Eine weitere Neuerung, an der die Entwickler seit fast einem Jahr arbeiten, ist die Unterstützung von Dateisystem-Updates mit dem snap-update-ns-Werkzeug. So können dynamisch Änderungen am Dateisystem der eingehängten Dateisysteme, die ein Prozess sehen kann, vorgenommen werden. Die neuen Hooks install und remove rufen das snapctl-Tool auf, das während der Installation oder des  Entfernens eines Snap dessen Kommunikation mit snapd abwickelt.

    Neue Schnittstellen

    Viele Schnittstellen in snapd sind aktualisiert und einige neue hinzugekommen. Dazu zählen broadcom-asic-control, greengrass-support und password-manager-service. Das search-Kommando wurde als Alias für den Befehl snap find angelegt und soll damit eine Entsprechung zu apt search bieten. Der Befehl snap change wurde umbenannt in tasks, um Verwechslung mit dem Befehl snap changes zu vermeiden. Während Letzterer aktuelle Änderungen im System anzeigt, listet snap change Funktionen innerhalb einer Änderung auf.  Alle weiteren Änderungen zu snapd 2.27 können der Release-Note entnommen werden.

  • Installation von Flatpaks durch den Flatpak-Hub vereinfacht

    Installation per Flatpak-Hub

    Flatpak, das alternative Paketformat, das bei Fedora entwickelt wird, steht in weiten Teilen in Konkurrenz zu Ubuntus Snap-Format, wenngleich dessen Ausrichtung etwas weiter gefasst ist. Flatpak konzentriert sich auf den Desktop, während Snaps eigentlich für das Internet der Dinge entwickelt wurden, aber auch auf dem Desktop funktionieren. Sogar so gut, dass Canonical eine Distribution rein auf der Basis von Snaps vorschwebt.

    Flatpak-Hub aufgewertet

    Erst kürzlich hat Fedora den Flatpak-Builder als eigenständige Anwendung ausgegliedert. Jetzt wurde der Flatpak-Hub, eine zentrale Webseite zum Sammeln von Flatpaks verschiedener Herkunft zum Shop aufgewertet, der auch gleich eine einfache Installationsmöglichkeit bietet. Als Voraussetzung muss lediglich die Flatpak-Software auf dem Rechner installiert sein. Diese ist bei Fedora, Arch, Mageia und OpenSUSE bereits vorinstalliert.

    Bei Debian und Ubuntu muss noch ein wenig nachgeholfen werden. Reicht bei Debian ein apt install flatpak, so sollte bei Ubuntu derzeit noch auf ein Flatpak-PPA zurückgegriffen werden, das von Flatpak-Entwickler Alexander Larsson selbst erstellt wurde. Flatpak ist zwar in den Ubuntu-Repositories vorhanden, aber nicht in einer aktuellen Version. Diese sollte man aber bei Software wie Flatpak, die unter stetiger Entwicklung steht, unbedingt bevorzugen.

    Installation per Software-Store oder Konsole

    Danach ist die Installation von Flatpaks vom Flatpak-Hub nur noch einen Klick entfernt. Dazu klickt man auf dem Flatpak-Hub unter dem Reiter Applications auf das gewünschte Paket. Daraufhin wird, je nach Distribution ein Paket mit der Endung flatpakref entweder heruntergeladen oder im jeweiligen Software-Store geöffnet.

    Ist kein Store vorhanden, hilft die Kommandozeile weiter. Der Befehl flatpak install com.spotify.Client.flatpakref als User installiert etwa den Spotify-Client. Dabei wird zuvor, falls noch nicht vorhanden, die benötigte Runtime installiert.

    Die Anwendung findet sich zum Starten hinterher im entsprechenden Menü. Falls nicht, reicht auch ein flatpak run com.spotify.Client als normaler User in der Konsole zum Starten der App. Bei Distributionen ohne Software-Shop kann man aber auch gleich die Kommandozeile zur Installation verwenden. Der entsprechende Befehl lautet dann im Fall von Spotify ebenfalls als User:
    flatpak install --from https://flathub.org/repo/appstream/com.spotify.Client.flatpakref
    Vermutlich wird die Handhabung von Flatpak im Verlauf der weiteren Entwicklung noch vereinfacht werden. Jedoch ist der Flatpak-Hub in seiner jetzigen Form ein guter Schritt in die richtige Richtung und wird künftig noch mehr Flatpaks auf einfache Weise verfügbar machen. Jeder, der ein Flatpak erstellt hat, dass gewisse Regeln einhält, kann dies zum Review für die Aufnahme in den Flatpak-Hub anmelden.

  • Flatpak-Builder als eigene Anwendung ausgegliedert

    Flatpak
    By: Matthias Clasen – CC BY-SA 4.0

    Flatpaks sind neben Ubuntu Snaps und AppImage derzeit eine Möglichkeit, Anwendungen für die Verwendung in mehreren verschiedenen Plattformen zu paketieren. Das bei Fedora und GNOME entwickelte Format gliedert mit Version 0.9.9 das Flatpak-Builder-Kommando zur Erstellung von Flatpaks aus dem Quelltext, als eigenständige Anwendung aus. 

     

    Bessere Verbreitung angestrebt

    Die neue Anwendung hat eine eigene GitHub-Seite erhalten, von der das Werkzeug heruntergeladen werden kann. Dort findet sich auch eine Anleitung, wie das Tool mit dem typischen Dreisatz – configure && make && make install – aus einem AutoGen-Script gebaut werden kann. Als Grundlage muss Flatpak bereits installiert sein. Die Befehle, die zu Flatpak gehören und wie sie angewendet werden, ist in der Flatpak Command Reference zusammengefasst. Mit der Ausgliederung als alleinstehende Anwendung soll die Verbreitung des Paketformats in anderen Distributionen weiter vorangetrieben werden.

    Flatpak setzt auf Container-Techniken

    Flatpaks, die zu Beginn ihrer Entwicklung noch XDG-Apps hießen, zeichnen sich, wie auch Snap und AppImage dadurch aus, dass sie die benötigten Bibliotheken im Paket mitbringen und so auf verschiedenen Distributionen einsetzbar ist. Auch verschiedene Versionen einer Software sind in der gleichen Umgebung möglich, ohne Verrenkungen nötig zu machen. Die Flatpaks setzen dabei auf eine Laufzeitumgebung auf, die grundlegende Bibliotheken mitbringt, sodass diese nicht in jedem Flatpak erneut ausgeliefert werden. Das neue Paketformat nutzt Kernel-Techniken wie Control Groups und Namespaces. Es setzt auf Techniken wie OSTree auf und nutzt Bubblewrap für das Sandboxing.

    Nicht nur Vorteile

    Die weiteren Vorteile von Flatpak sind erhöhte Sicherheit der Isolierung durch Sandboxen. Entwickler können mit Flatpaks ein Paket ihrer Software für alle Distributionen selbst erstellen. Hier setzt in der Diskussion auch Kritik an, da hier die Rolle des Paketmaintainers bei den einzelnen Distributionen in Frage gestellt wird. Diese sind nicht nur für die Paketpflege zuständig sondern pflegen auch Eigenheiten der jeweiligen Distribution ein. Zudem bilden sie das moderierende Verbindungsglied oder – je nach Auffassung – den Puffer zwischen Entwicklern und Anwendern.