LN-Waschpress

Schlagwort: Flatpak

  • 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.

  • 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.