CleanPress

Schlagwort: Flatpak

  • Ist das die Zukunft? Fedora Silverblue im Alltagstest

    Ist das die Zukunft? Fedora Silverblue im Alltagstest

    Gestern erschien Fedora 35 offiziell. Während die neuen Features überschaubar sind, nutzte ich die Chance, mit der neuen Version ein Experiment einzugehen: Der Wechsel von der klassischen Workstation-Variante auf Fedora Silverblue. Diese Ausgabe soll laut eigener Vorstellung die Zukunft von Fedora darstellen.

    Silverblue und Kinoite

    Parallel zu Silverblue gibt es seit kurzem auch Kinoite mit dem gleichen Konzept, nur die Desktopumgebung ist dann KDE statt GNOME. Das Konzept wurde auf Linuxnews auch bereits ausführlicher erklärt: Sowohl Silverblue als auch Kinoite gehören zu den unveränderbaren (immutable) Betriebssystemen. Das erklärt sich dadurch, dass ihr Root-Dateisystem nur lesbar ist. Alle Änderungen werden außerhalb des Root-Dateisystems auf einer separaten Ebene gespeichert. Updates werden als komplettes Abbild ausgeliefert und lassen sich somit zurückrollen auf einen vorherigen Stand.

    Für Software-Installationen gibt es drei Wege, der »klassische« Weg über den Paketmanager dnf entfällt dabei allerdings. Stattdessen soll die Anwendungsinstallation bevorzugt über Flatpaks stattfinden. Entwicklerwerkzeuge lassen sich über die »Toolbox« installieren, die Container-basiert ist. Über RPM/OSTree lassen sich aber schließlich auch noch klassische RPMs installieren.

    Warum der Aufwand? Auch die neuen Versionen sollen sich anfühlen und verhalten wie eine normale Distribution, aber zugleich das Betriebssystem stabil und unveränderlich machen durch die strikte Trennung zwischen System und Anwendung. Das erinnert an die mobilen Betriebssysteme. Für die kommende Zeit möchte ich diese Zukunft ausprobieren und von meinen Erfahrungen als »klassischer« Anwender berichten.

    Instalation mit Troubleshooting

    Auch für die Installation soll gelten, dass diese wie bei einer normalem Distribution aussieht und sich so verhält. Dafür wird der klassische Installationsmanager von Fedora genutzt. Allerdings unterscheidet sich die Installation bei mir in einem wesentlichen Punkt: Sie bricht bei mir mit Fehlermeldungen ab. Der Fehler ist auf EFI-Systemen bekannt, wenn weitere Betriebssysteme installiert sind. Workarounds werden angeboten, funktionieren bei mir aber nicht wirklich. Anstelle von allzu umfangreichem Troubleshooting entschließe ich mich daher, Silverblue meine ganze Platte zu geben und mein Dualboot damit aufzulösen.

    Einrichten: Viele Flatpaks

    Silverblue wird sehr spartanisch ausgeliefert, es richtet sich schließlich gegenwärtig noch an erfahrene Nutzer. Auch der Software-Store (GNOME Software) ist zu Beginn noch recht überschaubar ausgestattet. Erstaunlich ist, dass man beim Starten zwar gefragt wird, ob man auch Flathub.org als Software-Quelle hinzufügen möchte, dies aber scheinbar nur für ausgewählte Pakete für Flathub gilt. Das ist wenig transparent, letztlich lässt sich aber auf gewohntem Wege Flathub freischalten.


    Dank Flathub steigt die Auswahl an Software auch spürbar an, bislang vermisse ich keine Anwendung. So wirklich gut gelöst ist die Softwareinstallation über GNOME Software allerdings nicht. Im Gegensatz zu Fedora 34 ist das Programm für mich immerhin praktisch nutzbar, wenngleich sich mir manche Ladevorgänge noch immer nicht erschließen. Außerdem wird etwa der Firefox mit zwei separaten Einträgen in GNOME Software gelistet und mir werden insgesamt drei Installationswege angeboten: Vorinstalliert ist ein RPM, außerdem habe ich die Möglichkeit als Flatpak über Flathub oder als Flatpak über Fedora. Die konkrete Quelle herauszufinden gelingt mal auf den ersten Blick, mal nur in den tieferen Informationen beim Durchklicken. Das ist suboptimal gelöst, vor allem die Tatsache, dass Fedora ein eigenes Flatpak-Repository pflegt, statt in Flathub einzupflegen, läuft der Idee von Flatpaks ein Stückchen zu wider.


    Grundsätzlich sind Flatpaks ein Thema für sich, da gibt es unterschiedliche, aber gleichsam legitime Meinungen. Ich persönlich habe kein Problem mit Flatpaks, nur hätte ich sie gerne aus einer zentralen Quelle, die eine gute Qualitätssicherung hat. Beides ist in meinen Augen im Augenblick nicht gegeben: Weder ist es bislang zentral auf Flathub, noch ist dort besonders transparent, ob dort eine Qualitätssicherung stattfindet. Dem kann man natürlich entgegenhalten, dass dies bei klassischen Dritt-Quellen ebenfalls nicht der Fall ist und auch in den Repositorys oft veraltete Software liegt.


    Die Verwendung der Flatpak-Applikationen funktioniert im Alltag bei mir gut. Ich habe keine Latenzen. Lediglich muss einem bewusst sein, dass Flatpaks gelegentlich Restriktionen haben, beispielsweise wenn man auf Dateien abseits des Home-Verzeichnisses zurückgreifen möchte. Diese Restriktionen wurden allerdings bewusst eingefügt und lassen sich auch umkonfigurieren bei Bedarf.

    Manipulation am System möglich, aber nervig

    Allerdings gibt es auch Pakete, die keine Flatpaks sind. So waren es bei mir die Druckertreiber, Multimedia-Codecs und tlp, da bei mir die neuen Energie-Optionen aus GNOME 41 leider nicht als Alternative reichten. Was sonst alles durch die Kommandozeile fix erledigt ist, funktioniert mit Silverblue so nicht mehr. Immerhin, ist das Paket in Paketquellen hinterlegt, so funktioniert die Installation mittels rpm-ostree install. Danach ist nur noch ein Neustart erforderlich. Die Anzahl an notwendigen Neustarts kann man auch noch erhöhen: Für Multimediacodecs müssen unter Fedora Repositorys freigeschaltet werden, die ebenfalls erst nach einem Neustart funktionieren. Anschließend wird nach der Installation noch einmal ein Neustart durchgeführt.


    Nervig wird es auch, wenn man vom Hersteller ein Paket für beispielsweise Treiber bekommt. Denn dann gilt auch hier: Abhängigkeiten installieren, Neustart, Paket installieren, Neustart.
    Sicherlich, es ist ja eben Sinn und Zweck von Silverblue, Manipulationen am System so stark wie möglich zu reduzieren. Dennoch macht es in meinem Falle die Einrichtung meines Systems erst mal deutlich langwieriger, als wenn ich schnell meine eigene Checkliste abarbeite und mit Copy & Paste altbewährte Befehle nutze.

    Die Zukunft?

    Ist das nun die Zukunft? An Fedora schätze ich eigentlich, dass ich bei jedem Release ein weitestgehend rundes Paket bekomme, welches ich schnell installieren und dann nur noch kurz einrichten muss, wenn es um das Nachrüsten von Codecs, tlp und dem Druckertreiber geht. Dieser Prozess hat jetzt erst mal länger gedauert. Und auch die gesamte Installation wurde durch bekannte Bugs gestört.


    Ist man bei den alltäglichen Aufgaben, so fühlt sich Silverblue an wie jedes andere Linux-System mit GNOME. Da bin ich bislang auf keine Probleme getroffen. Die Ansätze für ein anwenderfreundlicheres Betriebssystem sind klar erkennbar: Alte Linux-Hasen nutzen gerne die Kommandozeile und das auch vollkommen zu Recht. Allerdings wird gerne mal vergessen, dass dies wenig technikaffinen Anwendern schnell zum Verhängnis wird, weil sie bei für manch ein Programm nicht umhinkommen, das Terminal zu nutzen oder bei dem Copy & Paste aus Internetanleitungen sich das System zerschießen. Ein funktionierender Software-Store, der auf Flatpaks zurückgreift und OSTree können diese Probleme lösen. Während für diese Anwender Silverblue noch aus Kinderkrankheiten herauswachsen muss, werden bei mir die kommenden Wochen zeigen, wie praktikabel das System im Alltagseinsatz sein wird und ob ich mit der »Toolbox« etwas anzufangen weiß.

  • Wie funktionieren Flatpak Portals?

    Wie funktionieren Flatpak Portals?

    Um das gleich vorwegzunehmen: Flatpak Portals ist nicht ganz die richtige Bezeichnung und wurde nur wegen der etwas griffigeren Überschrift gewählt. Richtigerweise muss es XDG Desktop Portals heißen. Und nun, da wir das aus dem Weg haben, erkläre ich mal für die, die es noch nicht kennen, was Portals sind und wozu sie im Zusammenhang mit Flatpak dienen.

    Portale für gezielte Berechtigungen

    Portals stellen eine Reihe von D-Bus-Schnittstellen bereit, die über APIs gezielt bestimmte Rechte wie unter anderem Zugriff auf Dateien oder Geräte wie Drucker, Soundkarte etc. definieren. Sie sind ein wichtiger Baustein bei Flatpak, denn sie regeln darüber die dynamischen Berechtigungen. Das ist ein Mechanismus, über den Anwendungen innerhalb einer Sandbox mit der Host-Umgebung dynamisch interagieren können, ohne dass zusätzliche Sandbox-Berechtigungen erforderlich sind. Beispiele für Funktionen, auf die über Portals zugegriffen werden kann sind das Öffnen von Dateien über einen Dateiauswahldialog, das Drucken oder das Erstellen von Screenshots.

    Desktop-spezifische Portals

    So kann etwa mit dem FileChooser-Portal Zugriff auch auf einzelne Dateien im Dateisystem gewährt werden. In letzter Zeit wurden Desktop- und Toolkit-spezifische Portals erstellt, wie etwa das GTK-Backend xdg-desktop-portal-gtk, das KDE-Backend xdg-desktop-portal-kde oder das Wayland-spezifische xdg-desktop-portal-wlr (wlroots). Generell erlauben Portals fein gegliederte Berechtigungen, die nur das eben Nötige erlauben. Einen Überblick über verfügbare Portals, deren API und Handhabung gewährt die Portal Documentation.

    Auch in Flatseal

    Portals haben kürzlich auch Einzug in das Tool Flatseal gehalten, das ich für die kommende Ausgabe des LinuxUser ausführlich beschrieben habe. Dadurch werden die in Flatseal erlaubten oder verbotenen Aktionen nicht mehr durch Portals überschrieben.

  • Flatpak 1.10 mit neuem Repository-Format

    Flatpak 1.10
    Bild: Flatpak.org

    Alex Larsson hat nach drei Beta-Versionen Flatpak 1.10 offiziell freigegeben. Wichtigste Änderung ist die Einführung eines neuen Repository-Formats, das Aktualisierungen beschleunigen und die heruntergeladene Datenmenge reduzieren soll. Das neue Format, das auch bereits in Flathub integriert ist, ermöglicht zudem die Isolierung von Metadaten basierend auf der Architektur des Prozessors, wodurch im gleichen Repository Pakete für verschiedene Architekturen besser bereitgestellt werden können.

    Flathub ist ein OSTree-Repository

    Larsson stellte das neue Format bereits im letzten Jahr im GNOME-Blog ausführlich vor. Dort erläutert er, dass Flathub sich beim Verteilen von Flatpaks auf OSTree stützt und somit praktisch ein OSTree-Repository sei. Der Kern eines OSTree-Repositorys ist die Summary-Datei, die den Inhalt des Repositorys beschreibt. Dies ist ähnlich wie die Metadaten, die apt update bei Debian herunterlädt.

    Summary verkleinert

    War diese Zusammenfassung bisher entpackt rund 6.6 MByte groß, konnte sie mit dem neuen Format in Flatpak 1.10 durch die Aufteilung auf einzelne Architekturen für x86 beispielsweise auf 2.7 MByte reduziert werden. Da diese Zusammenfassung bei jeder Flatpak-Installation heruntergeladen wird, reduziert dies insgesamt den Netzwerkverkehr. Damit wird zudem die Erweiterung um neue Architekturen vereinfacht, die jeweils die Menge der vorhandenen Apps multiplizieren. Ein neu eingeführtes inkrementelles Delta-Update tut ein Übriges.

    Weitere Verbesserungen

    Des Weiteren bringt Flatpak 1.10 Unterstützung für die GCC (GNU Compiler Collection) 11 Serie, ein neues flatpak pin Kommando zum Pinnen von Laufzeitumgebungen sowie neue APIs zur Erweiterung der Funktionalität von Flatpak. Sandboxen mit Netzwerkzugang haben jetzt Zugriff auf systemd-resolved und somit auf DNS-Lookups. Flatpak 1.10 kann während Flatpak-Updates nun auch automatisch nicht mehr unterstützte Laufzeitumgebungen deinstallieren.

  • Souk: Neuer Flatpak-Store in Entwicklung

    Souk

    Gnome-Anwendern stehen für die grafisch geführte Installation von Flatpaks je nach installierter Distribution die Anwendungen GNOME Software oder Ubuntu Software zur Verfügung, die beide auf dem gleichen Code aufbauen. Sie installieren nicht nur Pakete im RPM-Format aus den Archiven der jeweiligen Distribution und aktualisieren die Distribution selbst, sondern handhaben nebenher auch Firmware, Flatpaks und Snaps.

    Leichtgewichtiger Flatpak Store

    Dieser Standard-App-Store für GNOME ist selbst auf aktueller Hardware behäbig, unübersichtlich und verbraucht viel zu viel Arbeitsspeicher. Bei Ubuntu wird er als Snap ausgeliefert und ist somit von Hause aus Ressourcen-hungrig. Deshalb entschied sich der Entwickler Felix Häcker, der unter anderem auch für die Anwendung Shortwave und den BitTorrent-Client Fragments verantwortlich zeichnet, einen neuen Flatpak-Store von Grund auf zu entwickeln. Als zweiter Entwickler stieß Christopher Davis dazu.

    Auch auf Smartphones zu Hause

    Adaptive Oberfläche

    Souk wird in Rust und GTK4 geschrieben und als Flatpak ausgeliefert. Die Nutzerschnittstelle entspricht in weiten Teilen der von GNOME-Software, ist aber mit Libhandy entwickelt, damit Souk sich auf Smartphones wie dem Pinephone oder dem Librem 5 und auf Tablets an die mobilen Formfaktoren anpasst. Die Aufteilung in die Tabs Erkunden, Installiert und Aktualisierungen entspricht dem Vorbild.

    Klares Design

    Souk will nicht GNOME-Software Konkurrenz machen, sondern einen Flatpak-orientierten App-Store anbieten der sowohl auf Desktop- als auch adaptiv auf Mobilgeräten läuft. Beim Design ist der bei Purism beschäftigte GNOME-Designer Tobias Bernard beteiligt, was sich in einer klaren Formensprache ausdrückt. Die Ansicht einzelner Apps zeigt neben dem Install-Button auf einen Blick alle relevanten Details in Wort und Bild.

    Souk ist keine offizielle GNOME App. Ob der Flatpak Store bereits für GNOME 40 zur Verfügung stehen wird ist noch unklar. Weitere Informationen, der Quellcode sowie eine Bauanleitung zu Souk sind auf GitLab zu finden.

  • Linux Audio-Anwendungen als Flatpak

    Foto: Alexey Ruban auf Unsplash

    Linux Audio-Anwendungen wie Ardour, Hydrogen, LMMs oder Audacity benötigen Plugins mit Instrumenten und Effekten zur Erweiterung ihrer Fähigkeiten. Diese liegen in freien Formaten wie LADSPA, DSSI und LV2 sowie als proprietäre Erweiterungen VST2 und VST3 vor. Die von Steinberg entwickelten VST2 und VST3 lassen sich dank relativ offener Implementierungen auch als Open Source in Linux nutzen.

    Probleme mit Erweiterungen

    Beim Bereitstellen von Linux Audio-Anwendungen als Flatpak erwies sich das bisher als Problem, da man nicht einfach ein Plugin als Binärdatei in ein Flatpak integrieren kann. Dem kanadischen GNOME-Entwickler Hubert Figuiere ist es gelungen, dieses Problem zu lösen.

    Wie er in seinem Blog schreibt, will er auf die technischen Hintergründe in einem separaten Beitrag eingehen. Im Ergebnis unterstützen einige Musik-Anwendungen wie Muse3, LMMS, Hydrogen, Ardour, Mixxx und Gsequencer in Form von Flatpak verpackt nun Plugins. An der Umsetzung für Audacity arbeitet Figuiere noch.

    Plugins auf Flathub verfügbar

    Eine steigende Anzahl dieser Plugins ist auch im offiziellen Flatpak-Repository Flathub zu finden. Leider ist es bisher nicht möglich, diese Erweiterungen auf der Flathub-Seite selbst oder in GNOME Software über die Suche zu finden. Hierzu hilft der Befehl $ flatpak search LinuxAudio im Terminal, der rund 25 Plugins zu Tage fördert.

    Video-Editoren und GIMP

    Auch einige Video-Editoren wie Kdenlive, Flowblade oder Shotcut unterstützen Audio-Plugins im LADSPA-Format und können nun die paketierten Erweiterungen nutzen. Das gleiche Prinzip wandte der Entwickler auch bei GIMP an, dem in der Flatpak-Version bisher ebenfalls Plugins fehlten. So lassen sich nun unter anderem Erweiterungen wie GMic, LensFun, Resynthesizer, Liquid Rescale und BIMP in der Flatpak-Version von GIMP einsetzen.

  • AppImage – das unbekannte Wesen

    Bild: AppImage-Logo | Lizenz: Public Domain

    AppImage wird häufig in einem Atemzug mit den neuen Paketsystemen Flatpak und Snap genannt. Dabei ist AppImage keineswegs neu, sondern existiert bereits seit über fünfzehn Jahren. Zudem will es nicht mit den Mitbewerbern konkurrieren, sondern hat seine eigene Motivation.

    Richtig ist allerdings, das AppImage bis zum Auftauchen von Flatpak und Snap eher ein Schattendasein führte. Das hat sich in den letzten Jahren grundlegend geändert und auf AppImageHub stehen heute rund 1.000 Anwendungen zur Auswahl.

    Wo kommt AppImage her?

    Die Geschichte von AppImage beziehungsweise seiner Vorläufer begann bereits 2004. Entwickler Simon Peters, der auch heute noch hinter der Software steht, startet das Projekt klik, das nach einer Schaffenspause in PortableLinuxApps umbenannt und seit 2013 als AppImage verfügbar ist.

    Ziel war immer ein einfaches und distributionsunabhängiges Paketformat, das weder Root-Rechte noch eine Installation voraussetzt. Das Host-System soll dabei unverändert bleiben wie bei der Nutzung einer Live-Distribution. Anwendungen sollen schnell vom Entwickler zum Anwender kommen. Dieser muss das Paket lediglich ausführbar machen und kann loslegen.

    Wo sind die Unterschiede?

    AppImage hat zwar grob betrachtet die gleichen Ziele wie Flatpak und Snap, jedoch gibt es entscheidende Unterschiede. So wird im Gegensatz zu den Mitbewerbern keine Installation einer Basis-Software vorausgesetzt. AppImage verzichtet ebenfalls auf die bei Flatpak eingesetzten Laufzeitumgebungen, die desktopspezifisch oft benötige Bibliotheken bündeln und somit verhindern, dass jedes Paket alle benötigten Abhängigkeiten erneut mitbringen muss, auch wenn diese auf dem System bereits vorhanden sind.

    Andererseits muss ein AppImage nur einmal heruntergeladen werden, auch wenn es in Dualboot-Umgebungen eingesetzt wird, denn es läuft wahlweise auch von einem USB-Stick. Dabei lassen sich ohne viel Aufwand auch Anpassungen der Konfiguration mitführen. Das Erstellen von AppImages per AppImageKit ist einfacher als bei der Konkurrenz.

    Keine Sandbox

    AppImage verzichtet derzeit von Hause aus auf ein Sicherheitsmodell wie es Flatpak und Snap in Form von Sandboxen bieten. Hier muss der Anwender noch selbst tätig werden und kann die Anwendungen beispielsweise in Firejail laufen lassen.

    Ein weiterer Nachteil von AppImage ist derzeit noch die Update-Funktion. Diese kann zwar in die Pakete eingebaut werden und aktualisiert dann nur die Differenz zwischen alt und neu, wird aber bisher nur wenig eingesetzt. Simon arbeitet derzeit an einem Werkzeug, dass diesen Schritt für Entwickler vereinfachen soll, wie er kürzlich in einem Interview erläuterte.

  • Flatseal: Rechte von Flatpaks grafisch editieren

    Screenshot: ft

    Flatpak ist als modernes Paketformat im Aufschwung. Distributionen wie Fedora Silverblue oder Endless OS setzen bereits ganz oder zu großen Teilen auf das junge Format. Dabei sind die Linux-Anwender von Flatpak oder den Alternativen Snap und AppImage bisher nicht durchgehend überzeugt.

    Flatpak ist nicht unumstritten

    Die Eigenschaften von Flatpaks werden hochgelobt oder abgelehnt, je nachdem wen man fragt. Nehmen wir einmal die Plattformunabhängigkeit als Beispiel. Entwickler freuen sich, dass das gleiche Flatpak auf fast allen Distributionen läuft und ihnen damit Arbeit erspart. Ein Debian-Anwender wird aber beispielsweise beklagen, dass er die Anpassungen an die Debian-Richtlinien, die bisher der nun überflüssige Paket-Maintainer vornahm, vermisst.

    Rechte bisher unübersichtlich

    Auch was die Rechte angeht, die Flatpaks in einem System haben, herrscht
    Uneinigkeit. Flatpaks laufen in einer Sandbox und lassen sich von daher vollständig gegenüber dem Host-System isolieren. Das ergibt allerdings bei den allerwenigsten Anwendungen Sinn. Der Paketierer gibt dem Flatpak die benötigten Rechte, damit die Anwendung ihren Zweck erfüllen kann. Doch wie sehe ich als Anwender, worauf ein Flatpak Zugriff hat und kann ich diese Rechte ändern oder erweitern?

    Über die Kommandozeile ging das schon immer mit dem Befehl flatpak override, ist aber den meisten Anwendern zu umständlich. Seit rund einem Jahr war auch die Software-Verwaltung von GNOME 3.32 in der Lage, über die Sektion Anwendungen Rechte von Flatpaks zu ändern.

    Flatseal to the rescue

    Mit der neuen App Flatseal ist das jetzt noch mal ein wenig einfacher geworden. Laut Eigenbeschreibung ist Flatseal »ein grafisches Dienstprogramm zur Überprüfung und Änderung grundlegender Berechtigungen von Flatpak-Anwendungen.« Das erledigt die App in übersichtlicher Weise, indem links in einer Leiste die installierten Flatpaks aufgelistet sind und rechts im Hauptfenster die entsprechenden Rechte, die über einen Schalter manipuliert werden können.

    Viel mehr gibt es nicht zu sagen. Nach der Änderung von Rechten muss das Flatpak neu gestartet werden. Sollte etwas schiefgehen, lassen sich die Rechte oben rechts über eine Schaltfläche auf die im Flatpak vergebenen Rechte zurücksetzen. Das Projekt wird auf GitHub gehostet.

  • Bauh: neue Paketformate unter einer gemeinsamen Oberfläche

    Bauh im Suchmodus | Screenshot: ft

    Seit einigen Jahren tummeln sich neue Paketformate im Linuxland. Flatpak, Snap und AppImage bringen alle benötigten Abhängigkeiten direkt im Paket mit und sind somit distributionsübergreifend einsetzbar.

    Weitere Vorteile sind, dass in einer Distribution Pakete installiert werden können, die neuere oder ältere Bibliotheken erfordern als das Gastsystem bietet. Man denke nur an die gerade aus den Distributionen verschwindenden Python 2 oder Qt4.

    Flatpak, Snap, AppImage und AUR

    Im Sommer erschien in der Manjaro-Community ein Tool namens fpakman, um Flatpaks gezielter grafisch verwalten zu können. Das mittlerweile zu Bauh umbenannte Tool wurde seither erweitert und kümmert sich nun unter einer gemeinsamen Oberfläche zusätzlich um Snap, AppImage und Pakete aus dem AUR von Arch Linux und seinen Derivaten.

    Einfach Pip

    Mittlerweile ist die in Python und Qt5 geschriebene und auf GitHub gehostete Anwendung nicht nur unter Manjaro, wo sie seit 18.1 vorinstalliert ist oder unter Arch Linux verfügbar, sondern auch unter Debian, Ubuntu und deren Abkömmlingen. Dort wird sie über den Pip-Installer installiert

    sudo apt install python3-pip
sudo pip3 install bauh

    Nach dem Start von Bauh erscheint ein Verwaltungsfenster, in dem Anwendungen gesucht, installiert, gestartet, aktualisiert oder deinstalliert werden können. Einige Anwendungen können abhängig von ihrem Paketformat auch herabstuft werden. Zunächst scannt die Anwendung nach installierten Paketen der unterstützten Paketsysteme. Sind Anwendungen darunter, für die ein Update vorliegt, wird dieses ebenfalls angezeigt.

    Luft nach oben

    Bauh ist ein noch sehr junges Projekt mit Potenzial, das künftig noch weitere Formate unterstützen will. Eine Einschränkung gibt es derzeit für AppImages. Diese werden nur erkannt, wenn sie per AppImageHub installiert wurden. Beim Design ist noch einiges an Luft nach oben.

    Bessere Übersicht

    Bauh behebt einen Mangel, den sowohl GNOME Software als auch Plasma Discover aufweisen, wenn man diese denn überhaupt nutzt. Diese Anwendungen bieten zwar Unterstützung für Snap und Flatpak, allerdings gehen deren installierte Anwendungen in der Menge der über das Paketsystem installierten Anwendungen unter. Hier bietet Bauh in der Beschränkung auf alternative Formate eine wesentlich bessere Übersicht.

     

  • Alex Larsson über die Flatpak-Revolution

    Die Flatpak-Revolution
    By: Matthias Clasen – CC BY-SA 4.0

     

    Flatpak 1.0 ist seit einigen Tagen als produktiv einsetzbare Version des alternativen Paketsystems verfügbar. Entwickler Alex Larsson vermutet, dass sich nach drei Jahren intensiver Entwicklung die Schlagzahl der Änderungen nun verlangsamen wird. Der Fokus soll sich jetzt mehr auf die umgebende Infrastruktur konzentrieren. Dazu gehört es unter anderem, Flathub für weiteres Wachstum zu rüsten und Flatpak 1.0 in die Distributionen zu bekommen. Darüber hinaus soll an den Laufzeitumgebungen und Portals  gearbeitet werden.

    Larssons Revolution

    Derweil hat sich Red-Hat-Mitarbeiter Larsson dazu geäußert, warum er die Entwicklung zu Flatpak überhaupt begonnen hat. Er hofft auf nichts weniger als auf eine Revolution – eine Revolution des Linux-Paketsystems, dass er als »fundamental kaputt« empfindet. App-Entwickler haben laut Larsson keine sinnvolle Möglichkeit, ihre Arbeit zeitnah an die Anwender zu verteilen.

    Entwickler ohne Kontrolle

    So müssten Entwickler theoretisch Pakete für verschiedenste Distributionen selbst zur Verfügung stellen, wenn sie die Kontrolle über die Aktualität  behalten wollen. Tun sie das nicht – was alleine zeitlich oft nicht möglich ist, ergeben sich weitere Probleme.  Nicht alle Distributionen paketieren alle Apps oder warten oft, bis die Anwendung bekannter ist, was zu einem typischen Henne-Ei-Problem für neue Apps führt. Und wenn die Anwendung dann paketiert ist, hat der Entwickler keine Kontrolle mehr über die angebotene Version und deren Updates, so Larsson.

    Maintainer in der Mitte

    Diese Entscheidungen obliegen dem Paketbetreuer der jeweiligen Distribution. Viele dieser Maintainer machen einen ganz prima Job. So war etwa Flatpak 1.0 in Debian Unstable bereits rund 12 Stunden nach Veröffentlichung verfügbar. Distributionen wie Arch Linux. KDE Neon oder KaOS bieten immer sehr aktuelle Pakete an.

    Bugreports ins Leere

    Auf der anderen Seite stehen Distributionen wie Debian Stable, wo viele Pakete bereits veraltet sind, wenn eine neue Version der Distribution veröffentlicht wird. Einerseits machen die abgehangenen Pakete einen Großteil der Stabilität von Debian aus, andererseits hat der Entwickler die dort verteilten Versionen bereits längst vergessen. Die Anwender schreiben aber im Bedarfsfall Bugreports gegen diese Versionen. Die Fehler sind dann oft längst mit neuen Versionen behoben, die der Anwender aber nicht installieren kann. Im Idealfall portiert der Maintainer die Fixes zurück in die ältere Version. Somit sind Entwickler und Endanwender getrennt, in der Mitte steht – zum Wohl oder Übel – der Maintainer.

    Entwickler am Drücker

    Hier kommen neue Paketsysteme wie Flatpak gerade recht. Sie erlauben auch bei eher unbeweglichen Distributionen die Verwendung aktueller Bibliotheken, gebündelt in verschiedenen Laufzeitumgebungen. Damit können dann auch aktuelle Software-Versionen genutzt und aktualisiert werden.  Ziel ist, dass der Upstream-Entwickler die Kontrolle über die Updates hat.

    Schulterschluss mit den Usern

    Wenn der Entwickler einen wichtigen Fehler behebt, wird im Fall von Flatpak eine neue stabile Version veröffentlicht, die die Anwender verschiedenster Distributionen sofort nutzen kann. Alle Fehler werden gegen die neueste stabile Version eingereicht, so dass sie nicht veraltet sind, und sobald der Fehlerbericht geschlossen wird, erhält der Benutzer die Korrektur. Das bedeutet, dass das Melden von Fehlern für den Benutzer greifbar Sinn macht. Diese Art von virtuosem Zyklus trägt laut Larsson dazu bei, sowohl die Entwicklungsgeschwindigkeit als auch die Softwarequalität zu verbessern.

  • Flatpak 1.0: Sandboxing wird erwachsen

    Flatpack 1.0
    Quelle: NeONBRAND auf Unsplash

    Alex Larsson hat heute nach insgesamt drei Jahren Entwicklung Flatpak 1.0 freigegeben und damit das distributionsübergreifende Paketsystem, das seine Entwicklung unter dem Namen XDG-App begann, für den produktiven Einsatz freigegeben. Die Serie 1.x folgt auf die im Oktober 2017 veröffentlichte Reihe 0.10.x. Flatpak 1.0 soll über signifikant verbesserte Leistung und Zuverlässigkeit verfügen. Neben einer großen Anzahl an beseitigten Fehlern wurde auch mit neuen und verbesserten Funktionen nicht gespart.

    Berechtigungen überarbeitet

    Anwender wird es freuen, dass Flatpak 1.0 bereits bei der Installation einer Anwendung die Zustimmung zu den Berechtigungen anfragt, und nicht erst bei der ersten Ausführung. Wenn ein künftiges Update der Anwendung zusätzliche Berechtigungen benötigt, wird Flatpak dabei erneut auffordern, die Anfrage je nach Bedarf zu entscheiden.

    Neues Portal

    Der Ersteller eines Flatpak kann in der neuen Version der paketierten Anwendung ein Ablaufdatum mitgeben. Das kommt beispielsweise Entwicklern zugute, die eine Testversion herausgeben, die nur eine begrenzte Zeit lauffähig sein soll. Flatpak erhielt auch ein neues Flatpak-Portal,  mit dem Linux-Anwendungen Sandboxen erstellen und sich selbst neu starten können. Das neue Werkzeug flatpak-spawn kann Befehle des Hosts ausführen, sofern die Berechtigungen das erlauben und kann unter Verwendung der APIs des neuen Portals neue Sandboxen aus einer Anwendung heraus erstellen. Zudem kann Flatpak 1.0 TLS-Zertifikate des Hosts für Sandbox-Anwendungen freigeben.

    Flatpaks lernen SSH

    Flatpak 1.0 ermöglicht Apps in Sandboxen zudem den Zugriff auf den SSH-Agent des Hosts für den sicheren Zugriff auf Git-Repositories oder Remote-Server und ermöglicht Apps den Zugriff auf Bluetooth-Geräte. Außerdem ist die P2P-Methode für die Installation von Flatpak-Anwendungen über USB-Sticks oder das lokale Netzwerk nun standardmäßig aktiviert und wird in allen Builds unterstützt. Eine neue Fallback-Lösung für Anwender in einer X11-Sitzung wurde in Flatpak implementiert. Dies kann verwendet werden, um sicherzustellen, dass eine App in Wayland keinen unnötigen X11-Zugriff hat, aber dennoch in einer X11-Sitzung alle nötigen Rechte erhält.

    Darüber hinaus erhielt Flatpak neue Kommandozeilenbefehle und weitere Verbesserungen für Plattform-Entwickler und Linux-Distributoren. Hauptentwickler Larsson bezeichnete die stabile Freigabe von Flatpak als »wichtigen Schritt in Richtung des Ziels, das Linux-Ökosystem zu revolutionieren«. Insbesondere bei Fedora 29 wird Flatpak im Rahmen des Projekts Silverblue eine wichtige Rolle zukommen.

    Flatpak 1.0 braucht, wenn es aus den Quellen gebaut wird, Bubblewrap 0.2.1 und OSTree 2018.7. Distributoren sind aufgefordert, die neue Version möglichst bald ihren Anwendern zur Verfügung zu stellen. Alle Änderungen zu Flatpak 1.0 sind auf GitHub verzeichnet.