Linux App Summit 2026: Treffen der Linux-Desktop-Avantgarde

Klein, aber fein war das Treffen der Linux-Desktop-Community. Auf dem Linux App Summit (LAS 2026) Mitte Mai in Berlin trafen sich rund 110 Personen, darunter war projektübergreifend die Avantgarde der Entwickler für moderne Linux-Systeme vor Ort. Dabei ging es weniger um das Aussehen der Desktopoberfläche, als um grundlegende Konzepte, um die Installation einfacher, das System sicherer und robuster sowie die Benutzung komfortabler zu machen. Statt um Desktop-Themes, Distributionen und Pakete drehten sich die Gespräche um Images, Apps und wie das teils veraltete Linux-Ökosystem wieder zu modernen Betriebssystemen wie Android/ChromeOS, macOS und ja, auch Windows, aufschließen kann.

Die etwas mehr als ein Dutzend Vorträge waren sinnbildlich eingerahmt zwischen der Eröffnungs-Keynote von systemd-Erfinder Lennart Poettering und dem Schlussvortrag von Jorge Castro, Initiator des Projektes Universal Blue, aus dem die modernen Linux-Systeme Bluefin und Bazzite hervorgegangen sind. Beide, Castro und Poettering, fordern ein grundlegendes Umdenken, wie Linux-Betriebssysteme bereitgestellt werden, verfolgen aber unterschiedliche Ansätze.

Unveränderliche Images

Lennart Poettering plädierte in seiner Keynote für eine strikte Trennung von Betriebssystem und lokalen Daten (Inhalt der Benutzerverzeichnisse, lokale Konfigurationen et cetera), wo ersteres über ein unveränderliches, für alle gleiches Image verteilt wird. Das erlaubt, die Authentizität des Betriebssystems kryptografisch sicherzustellen, indem vereinfacht gesagt Prüfsummen der Images, aber auch anderer Komponenten wie Kernel und Bootloader, über den TPM-Chip abgesichert sind. Weitere Komponenten kann man als Erweiterungen einklinken, die ebenfalls als verifizierbare Images vorliegen. Manipuliert jemand einen Teil des Systems, ändern sich Hashwerte und führen dazu, dass das TPM-Modul den weiteren Bootvorgang und die Entschlüsselung der Partition mit den lokalen Daten verweigert. Gleichzeitig erlaubt das Design, mithilfe eines korrekten Images den Werkzustand wiederherzustellen.

Poetterings Ziel ist es, die Zustandsräume (State Spaces) zu verkleinern, also die Unterschiede zwischen verschiedenen Installationen, um die Prüfung und Absicherung der Systeme zu erleichtern. Ihm schwebt vor, das aus dem Speichermanagement bekannte Sicherheitskonzept „Schreiben oder Ausführen“ (W^X) auch auf das Dateisystem auszuweiten. Code solle nur dann ausgeführt werden, wenn dieser von einem überprüften, unveränderlichen Image komme. Er betont aber: „Sicherheit ist nie binär, sondern eine graduelle Angelegenheit.“ So könne etwa innerhalb von Containern was anderes gelten, wenn alles im Userspace läuft und voneinander abgeschottet ist.

Um das zu realisieren, kommen viele unterschiedliche Komponenten von systemd zum Einsatz, etwa systemd-sysupdate, systemd-repart, oder Standards aus dessen Umfeld, wie Discoverable Disk Images. Poettering hat gemeinsam mit anderen Entwicklern die Firma Amutable gegründet, die ein verifizierbares Linux-System anbieten wollen, was aber eher auf Server und Rechenzentren abzielt.

Für den Desktop setzt neben ParticleOS aus dem systemd-Projekt insbesondere Gnome OS Poetterings Ideen um. An dessen Umbau war maßgeblich der Gnome-Entwickler Adrian Vovk beteiligt, der auch auf der LAS 2026 anwesend war.

Container auf dem Desktop

Auch Kubernetes-Spezialist Jorge Castro fordert ein radikales Umdenken und will ein robustes Linux-System, geht aber mit seinem Projekt Universal Blue einen anderen Weg, indem er Erfolgskonzepte von Containern, etwa Docker, auf den Linux-Desktop übertragen will. „Es gibt 20 Millionen Entwickler in der Cloud-Native-Community“, betont Castro im Gespräch mit c’t. „Ich sehe es als meinen Job an, die wieder für Betriebssystem zu begeistern, damit Gnome und KDE Bestand haben.“ Die Cloud-Entwickler will er mit dem Projekt Universal Blue erreichen, das auf dem von Red Hat entwickelten, aber stiefmütterlich behandelten, Fedora Silverblue basiert. Das System startet aus einem bootbaren Container; Updates holt das Tool bootc ähnlich, wie man es von Docker gewohnt ist. Die Images, also OCI-Container, bauen Castro und seine Mitstreiter automatisiert auf GitHub. Mit Universal Blue hat Castro eine ganze Reihe moderner Linux-Systeme losgetreten.

Bluefin nutzt ein aufgehübschtes Gnome, setzt komplett auf Apps aus Flathub sowie Kommandozeilentools aus Homebrew und soll eine Nutzererfahrung wie ChromeOS bieten. „Chromebooks sind super, ich will diese Power mit einem normalen Linux“, sagte Castro in Berlin. Von Bluefin inspiriert entstand Bazzite mit KDE Plasma, was SteamOS des Gaming-Handhelds Steam Deck nachempfunden ist, Steams Gaming Mode unterstützt und so abseits typischer Linux-Zielgruppen auf Resonanz stieß. Auf mobilen Konsolen, wie dem Asus ROG Ally, laufen Spiele mit Bazzite teils schneller, als mit dem vorinstallierten Windows. „Gamer Nerds retten möglicherweise den Linux Desktop“, meint Castro. Im projekteigenen Discord würden 33.000 „Kids“, so Castro, abhängen: „Neue User ganz ohne schlechte Gewohnheiten.“

Den anwesenden Gnome- und KDE-Entwicklern empfahl er, das Schicksal in die eigene Hand zu nehmen und ein eigenes Desktop-Produkt auszuliefern, das Out-of-the-Box funktioniert. Bei klassischen Distributionen gäbe es zu viele Altlasten. „Die Leute gehen mit X11 nach Hause, was eure Arbeit erschwert“, klagte Castro. „It hurts me!“

Castro kritisierte aber auch, dass trotz mehrfacher Ankündigung im de-facto Linux-App-Store Flathub es nicht möglich ist, für Apps zu bezahlen oder auch nur zu spenden.

Apps in VMs einsperren

Was mit modernen Linux-Komponenten möglich ist und wo die Grenzen liegen, zeigte Spectrums Projektleiterin Alyssa Ross. Spectrum priorisiert Sicherheit und ähnelt Qubes OS, welches Umgebungen wie „Arbeit“ oder „Privat“ mittels virtueller Maschine (VM) abschottet. Spectrum setzt das radikaler um, weil jede App in einer eigenen VM startet. Apps interagieren mit dem Betriebssystem zusätzlich zu den VM-Schnittstellen wie virtio-gpu und virtio-fs auch über Desktop Portals, wie sie bei Flatpak und Snap eingesetzt werden. Dank Wayland verhalten sich die Anwendungen wie normale Fenster, ein virtuelles Display gibt es nicht, und trotz der Abschottung klappt auch die Zwischenablage.

Spectrum blockiert per Vorgabe alle Berechtigungen, was manchmal nicht so einfach ist. Ross beklagte etwa, dass es bei den Desktop Portals keine Audio-Schnittstelle gibt, das den Zugriff auf das Mikrofon regelt. Sobald eine App Zugang zu der Audioschnittstelle von Pipewire hat, kann sie alle verfügbaren Audio-Geräte nutzen, inklusive aller Mikros.

Als Herausforderung bei der Entwicklung von Spectrum bezeichnete die Projektleiterin den Spagat zwischen der Desktop-Arbeit und der Hypervisor-Arbeit. Das Projekt will mit dem Linux-Desktop-Ökosystem zusammenarbeiten und verfolgt eine Upstream-First-Philosophie, weshalb Spectrum keine eigenen Apps entwickelt.

Flatpak Next

Über den Status von Flatpak und dessen Zukunftspläne berichteten Adrian Vovk und Sebastian Wick, welcher seit vergangenem Jahr neuer Maintainer ist. Die Stagnation bei der Entwicklung von Flatpak sei überwunden, so Wick. Ein Security-Audit hatte einige Sicherheitslücken offenbart, darunter ein Ausbruch aus der Sandbox mittels „path traversal“ (Manipulation eines geöffneten Dateipfades, um Zugriff auf andere Dateien zu erlangen), der schwer zu korrigieren war, weil er sich durch den gesamten Flatpak-Stack zog. Ein erster Fix legte Steam und alle Chrome-basierten Browser lahm, und eine kompatible Lösung zu finden, kostete viel Arbeit.

Neu sind bedingte Berechtigungen. Apps können prüfen, ob es Portals wie das neue USB-Portal gibt, sonst auf veraltete Berechtigungen wie „Alle Geräte“ zurückfallen. Das soll der Verbreitung von Portals helfen, ohne die Apps auf älteren Systemen unbrauchbar zu machen.

Derzeit experimentiert das Flatpak-Team damit, Apps, die noch das veraltete X11-Anzeigesystem verwenden, keinen Zugriff mehr auf das systemweite Xwayland zu geben, sondern für jede solche Anwendung mit Xwayland-satellite eine eigene X11-Umgebung zu starten. Das würde einerseits auch X11-Apps untereinander abschotten, wie es bereits bei Wayland der Fall ist, und andererseits perspektivisch erlauben, aus Wayland-Compositor wie Gnome-Shell den X-Window-Manager-Code herauszuwerfen.

Allgemein machen sich die rund elf Jahre, die Flatpak auf dem Buckel hat, schon bemerkbar. Es fehle teilweise an Abstraktionen, und die notwendige Rückwärtskompatibilität verhindert größere Änderungen. Daher planen Wick und Vovk im Rahmen von Flatpak Next alles neu zu programmieren. Dass dies in Rust geschehen soll, sorgte im Saal für Begeisterung. Dabei soll von Anfang an eine bessere Abstraktion stattfinden, die etwa den Austausch des Speichermechanismus ermöglicht. Flatpaks wären dann denkbar als OSTree, OCI-Container oder DDI.

Statische Berechtigungen, die Löcher in die Sandbox bohren, will das Team künftig nicht mehr ohne Weiteres erlauben. Für Apps soll es künftig zwei Modi geben. Im „confined mode“ sind statische Berechtigungen nicht erlaubt, weshalb sie komplett in der Sandbox laufen und Portals verwenden müssen. Der laxere „unconfined mode“ läuft auf dem Host und nutzt nur die Flatpak-Laufzeitumgebung. Man wolle, so Wick, Vertrieb von Apps und den Einsatz der Sandbox voneinander trennen. Der „unconfined mode“ soll nur mit Flatpak-Quellen („remotes“) möglich sein, denen der User vertraut. Flatpak Next soll für die Sandbox kein bubblewrap verwenden, da selbst ältere Distributionen die Trennung mittels unprivilegierter User-Namespaces unterstützen.

Neue Portals sind ebenfalls geplant, etwa für Rechtschreibprüfung, Passwort-Manager oder für Credentials wie FIDO2-Sicherheitsschlüssel und Passkeys, aber auch um den von Ross vermissten Mikrofon-Zugriff zu regeln. Auch die Portals sollen eine neue Architektur bekommen und Varlink statt D-Bus verwenden. Authentifizierung der Apps und Rechtemanagement soll die von Vovk und Wick neu angedachte systemd-Komponente systemd-appd übernehmen.

Flatpak Next und das bisherige Flatpak sollen parallel installierbar sein und sich nicht ins Gehege kommen; gleiches gilt für die Portals. Gegenüber c’t sagte Wick, es sei einfacher anhand der Erfahrungen Flatpak sauber neu zu entwickeln, als um die Altlasten herumzumanövrieren.

Interessanterweise wies Collabora-Entwickler Thorsten Behrens in seinem Vortrag darauf hin, dass ein Rewrite immer den Nutzen für die User im Fokus haben sollte und kein Selbstzweck sein sollte. So manches trendige Framework sei nach kurzer Zeit schon wieder eingestampft worden.

x86 Code auf ARM

Wie man eine Brücke zwischen zwei Welten schlägt, zeigte Tony Wasserka, der am Emulator FEX mitarbeitet, welcher unveränderten x86-Code auf ARM-Systemen ausführt. Valve plant FEX auf dem angekündigten VR-Headset Steam Frame einzusetzen. Die Schwierigkeit bestehe darin, den x86-Binärcode zur Laufzeit für ARM64 zu rekompilieren und ihn gleichzeitig zu optimieren, um den Code auch schnell genug auszuführen. Wasserka gab Einblicke, wie sie das erreichen. So rekompiliert FEX-Emu den x86-Maschinencode zunächst in eine Zwischensprache um, die dann optimiert wird und woraus dann ARM64-Maschinencode kompiliert wird. Bereits rekompilierte Codestücke speichert FEX-Emu in einem Cache zwischen.

Probleme entstehen etwa dadurch, dass sich das Speichermodell zwischen x86 und ARM64 unterscheidet. Bei Multithreading tauchen Variablen teilweise in einer anderen Reihenfolge auf, als es bei x86 der Fall ist. Das konsequent abzufangen erzeugt einen Overhead, der die Performance massiv drückt. Wasserka und seine Mitstreiter entwickelten daher Heuristiken, um den Overhead nur dort zu erzeugen, wo er zwingend notwendig sei. So habe es bei Unity-Spielen schon gereicht, nach einem bestimmten Memory load offset Ausschau zu halten, sonst sei die Reihenfolge vernachlässigbar. „Es ist erschreckend, wie gut der Trick funktioniert“, resümierte Wasserka.

Ein weiterer Schritt bestand darin, Wrapper für Syscalls zu schreiben. Das sei zwar oft einfach, aber da es Hunderte von ihnen gibt, in der Summe aufwendig. Diese Arbeit sei aber jetzt fast komplett abgeschlossen. Bei Windows-Programmen profitiert das FEX-Emu-Team von den ARM64EC-Windows-Bibliotheken, die Microsoft öffentlich bereitstellt. Der Code der Windows-Programme wird für die ARM64EC-Schnittstelle rekompiliert. Dadurch fallen viele Zwischenschichten weg, wie x86-Wine, x86-Windows- und Linux-Bibliotheken sowie Kernel-Kompatibilitätsschichten. Stattdessen reichen der Rekompilierer, ein WINE für ARM sowie die ARM64EC-Bibliotheken, die direkt mit dem ARM-Kernel interagieren können. Wasserka demonstrierte dem LAS-2026-Publikum FEX live, indem er ein x86-Steam auf seinem ARM64-Notebook öffnete und das Spiel Tunic startete, welches weitgehend flüssig lief.

Linux auf dem Desktop hat es derzeit nicht einfach, da aktuell kaum Geld in den Linux-Desktop fließt. Das zeigt auch ein Blick auf die Sponsoren des LAS 2026, die nicht mehr so zahlreich sind wie noch vor einigen Jahren. Umso engagierter ist die Community, die innovative Ideen ersinnt und umsetzt, wie Bluefin, Bazzite oder Gnome OS zeigen. Die Aufzeichnungen der Vorträge des Linux App Summit sind auf YouTube verfügbar.

(ktn)