Neue Besen kehren bekanntlich gut. Aber trifft diese Binsenweisheit auch auf die neuen technischen Ansätze Wayland, Flatpak und Pipewire zu?

Von Mitte der 1990er-Jahre bis 2015 blieben einige Grundfesten eines Linux-Systems unverändert: Als grafische Oberfläche lief ein X-Server, sämtliche Software stammte aus den von den Distributionen mitgelieferten Paketen. Ab etwa 2015 stand dann zur Debatte, das uralte X-Window-System durch Wayland [1] zu ersetzen. Zu dieser Zeit stellte auch Alexander Larsson mit seinem Paketsystem Xdg-app (heute: Flatpak [2]) generische, auf praktisch allen Linux-Distributionen lauffähige Softwarepakete vor. Die jüngste grundlegende Veränderung betrifft das Soundsystem Pulseaudio, das die Distributionen zunehmend durch das neue Pipewire-Framework [3] ersetzen.

Geschlossene Gesellschaft

Eine der größten Einschränkungen, mit denen Linux Windows-Umsteiger konfrontiert, ist die Tatsache, dass sich unter Linux zunächst nur für die jeweilige Distribution vorgesehene Pakete installieren lassen. Dagegen funktionieren unter Windows generische setup.exe-Dateien über mehrere Versionen des Betriebssystems hinweg.

Das hängt damit zusammen, wie die beiden Systeme mit Hilfsprogrammen umgehen, den sogenannten Bibliotheken: Windows überlässt die Verwaltung der Software selbst und stellt lediglich ein System zur Verfügung, das es erlaubt, mehrere Versionen einer Bibliothek parallel zu installieren. OpenSuse dagegen stellt mit seiner zentralen Paketverwaltung (Abbildung 1) sicher, dass alle Programme dieselbe Version einer systemweit installierten Bibliothek nutzen.

Abbildung 1: Die zahlreichen benötigten Hilfsprogramme einer Anwendung – hier des KDE-Dateimanagers – stellt eine Distribution für alle Programme in einer einzigen Version bereit.

Jede Distribution enthält in jedem Release andere Versionen dieser Hilfsprogramme. In den meisten Fällen bedeutet das, dass Programme für jede Distribution neu aus dem Quellcode kompiliert werden müssen – eine Aufgabe, die nicht immer leicht gelingt und die etliches an Erfahrung voraussetzt. Genau deswegen ist es üblich, das an die Entwickler der Distributionen zu delegieren und die mitgelieferten Pakete zu installieren.

Allerdings wird es für die Distributionen schwieriger, einen möglichst großen Querschnitt der wachsenden Anzahl freier Programme aktueller Versionen zu paketieren: Die Zahl der verfügbaren Programme und das Tempo der Entwicklung in der Welt der freien Software nimmt stetig zu, die Ressourcen der Distributoren eher nicht.

Für die Entwickler einer Software gestaltet es sich ebenfalls aufwendig, fertige Pakete für mehrere Distributionen bereitzustellen: Der Bau von Paketen für RPM-basierte Systeme wie OpenSuse und Fedora, für DEB-basierende Distributionen wie Debian und Ubuntu oder für Arch Linux läuft grundverschieden ab. Selbst Linux-Initiator Linus Torvalds beschwerte sich auf der DebConf 2014 darüber, wie schwierig es sei, seine Tauchcomputersoftware Subsurface (Abbildung 2) unters Volk zu bringen [4].

Abbildung 2: Die von Linus Torvalds initiierte Tauchcomputersoftware Subsurface bietet ein gutes Beispiel dafür, wie schwierig es für Softwareentwickler ist, ihre Programme unter Linux dem Endnutzer zugänglich zu machen.

Linus glaubte 2014, noch keine Lösung für das Problem zu kennen. Doch bald darauf standen auf der Webseite von Subsurface neben nativen Paketen für Ubuntu, Debian, Fedora und OpenSuse auch generische Appimage-Pakete bereit, die unter allen Linux-Distributionen funktionieren (Abbildung 3).

Abbildung 3: Die gegenwärtigen Entwickler von Subsurface machen sich die Mühe, vier Linux-Distributionen mit einem eigenen Paket zu bedienen. Alle weiteren deckt das generische Appimage ab.

Von hinten aufgezäumt

Appimage-Pakete umgehen das Problem der unterschiedlichen Bibliotheken dadurch, dass sie nicht nur das eigentliche Programm enthalten, sondern auch dessen Abhängigkeiten. Bei einem solchen Paket handelt es sich um ein selbstentpackendes Archiv, das Sie lediglich im Dateimanager anklicken müssen, um das enthaltene Programm zu starten. Appimages greifen ausschließlich auf das Home-Verzeichnis zu und tasten das System nicht an. Deswegen müssen Sie im Regelfall auch keine zusätzliche Software installieren.

Ein Nachteil von Appimage-Paketen liegt in ihrer Größe: Das native OpenSuse-Paket von Subsurface umfasst lediglich 9 MByte, das Appimage dagegen 113 MByte. Das spielt bei einer Handvoll von Programmen hinsichtlich Download und Plattenplatz kaum eine Rolle. Einer der Hauptgründe, weswegen die Linux-Distributionen dennoch den Aufwand betreiben, um nur eine Version jeder der zahlreichen genutzten Bibliotheken installieren zu müssen, liegt in der Hauptspeicherbelegung: Schwergewichte wie Qt erfordern gut und gern einige zig MByte RAM. Teilen sich alle Programme dieselbe Qt-Version, dann lädt das System sie nur ein Mal in den Hauptspeicher. Bei unterschiedlichen Versionen, wie sie bei distributionsübergreifenden Paketen zwangsläufig auftreten, erfolgt das einmal pro laufendem Programm.

Negativ fällt an den ansonsten praktischen Appimages außerdem auf, dass die von OpenSuse laufend bereitgestellten Sicherheitsaktualisierungen für sie nicht greifen: Sie enthalten ja jeweils eine eigene Version der möglicherweise fehlerhaften Bibliothek. Es ist ihnen nicht ohne Weiteres anzusehen [5], um welche Version es sich dabei handelt.

Flatpak gilt gegenüber dem seit 2004 prinzipiell verfügbaren Appimage als vergleichsweise moderneres plattformübergreifendes Paketformat. Es bügelt einen Teil dieser Nachteile durch sogenannte Runtimes [6] aus, also Sammlungen häufig gebrauchter Abhängigkeiten. Daraus bedienen sich die einzelnen Flatpak-Pakete und teilen die Komponenten dann mit anderen Flatpak-Paketen, wenngleich nicht mit dem restlichen System. Die Flatpak-Entwickler versorgen die Runtimes außerdem mit Bugfixes.

Um Flatpaks zu nutzen, installieren OpenSuse-Anwender zunächst das Paket flatpak und fügen dann mit den Aufrufen aus Listing 1 das Standard-Flatpak-Repository hinzu und frischen den lokalen Katalog auf. Existieren schon Pakete, dann spielt dieses Update genau wie zypper up verfügbare Updates ein.

# flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
# flatpak update

Etwas überspitzt formuliert installiert Flatpak also ein zweites System parallel zu OpenSuse – eigene Programme mit eigenen Bibliotheken, die es wie OpenSuse zentral pflegt. Flatpak verhält sich wie ein Paketmanager, der Abhängigkeiten automatisch mitinstalliert: flatpak search durchsucht das Repository, flatpak install installiert ein Paket, flatpak uninstall entfernt es wieder. Auch die KDE- und Gnome-Appstores Discover und Gnome Software unterstützen das Paketformat.

Flatpak bietet außerdem eine Container-Architektur, die Programme vom restlichen System abschotten kann: Der Datei- und Netzzugriff lässt sich blockieren oder auf einzelne Verzeichnisse beschränken. Jedes Paket kann diese Mechanismen ein- oder ausschalten. In der Praxis sind sie meist deaktiviert (Abbildung 4).

Abbildung 4: Exemplarisch zeigt das Flatpak-Paket Audacity, welche zusätzlichen Absicherungsmöglichkeiten Flatpak beherrscht.

Standardmäßig fragt Flatpak bei der Installation nach dem Root-Passwort. Eine Installation ohne Root-Rechte gestattet die Option --user. Das Mischen von systemweiten und benutzerspezifischen Installationen birgt aber den Nachteil, dass das System umfangreiche Runtimes mehrfach herunterladen und aktuell halten muss.

Wer den nötigen Zeitansatz vergleicht, um ein Linux- und ein Windows-System aktuell zu halten, spürt den technischen Vorteil der unter Linux üblichen Praxis, Bibliotheken in exakt einer Version vorzuhalten. Wahr ist allerdings ebenso, dass die Distributionen bei der Pflege ihrer Paket-Repositories mehr und mehr an ihre Grenzen stoßen und Linux-Anwender in Zukunft wohl viele Programme – vielleicht sogar alle, mit Ausnahme zentraler Systemkomponenten – über Flatpak-Pakete installieren werden.

Fenster der Vergangenheit

Die Wurzeln des bis heute immer noch eingesetzten grafischen X-Window-Systems, auch bekannt als X11 (Abbildung 5), reichen bis ins Jahr 1984 zurück. Sein Konzept, jegliche Kommunikation, auch mit lokalen Anwendungen, über eine Pseudo-Netzwerkschnittstelle abzuwickeln, entstammt dem Zeitalter des Terminalzugriffs auf Großrechner.

Abbildung 5: Die ressourcenschonenden Zeichenfähigkeiten des X-Servers bieten heute keinen Mehrwert mehr: Grafiken ohne Kantenglättung, Farbverläufe und Schatten wirken einfach zu altmodisch.

Mehr als ein Jahrzehnt lang störte diese archaische Grundstruktur unter Linux niemanden. Zum Problem wurde sie erst im Kontext der etwa 2005 aufkommenden 3D-Desktop-Effekte (Abbildung 6). Bei 3D-Animationen, die mit mindestens 50 Hz Bildschirmwiederholfrequenz ablaufen, führt die zusätzliche Latenz der Pseudo-Netzwerkschnittstelle leicht zum Ruckeln oder zu Blitzern (sogenannten Tearing-Artefakten).

Abbildung 6: 3D-Effekte wie beim heute noch in KDE verfügbaren Anwendungsumschalter 3D-Fenstergalerie führen unter X11 zu Problemen.

Es gab weitere Gründe, den X-Server in Rente zu schicken: Unter X11 erhalten alle Programme ungeprüft Zugriff auf Maus, Tastatur und Bildschirm. Das macht es zum Beispiel selbst Schadsoftware, die nur mit Benutzerrechten läuft, leicht, Passwörter abzugreifen. Auch nutzt kein modernes Programm mehr die Funktionen des X-Servers zur Schriftdarstellung und zum Zeichnen: Ohne Kantenglättung oder halbtransparenten Schlagschatten wirkten damit gezeichnete Oberflächen archaisch. Unnützer Code stellt immer auch ein unnötiges Sicherheitsrisiko dar.

Der X-Server gestattet es, Bitmaps wie die Oberfläche eines Schalters im Server zwischenzuspeichern, was sich beim Arbeiten via Netzwerk als nützlich erweist. Stürzt aber ein Programm ab, dann bleiben die Grafikressourcen bis zum Neustart von X11 im Speicher. Es gab also genug alte Zöpfe, die einen Neuansatz lohnenswert erscheinen ließen.

Ob sich jedoch der Umstieg von X11 nach Wayland im Moment tatsächlich lohnt, hängt auch davon ab, ob Sie Gnome oder KDE nutzen. Gnome begann bereits 2013 mit der Integration der Wayland-Kompatibilität, während KDE zu dieser Zeit mit dem Wechsel von KDE 4 auf 5 beschäftigt war. Daher läuft Gnome unter Wayland schon seit längerer Zeit stabil, während KDE mit Plasma 5.26.4 in Tumbleweed diesen Zustand gerade einmal mit inzwischen vergleichsweise kleinen Einschränkungen erreicht. Frühere Fehler scheinen immerhin gelöst, wie eine versagende Zwischenablage, nicht mehr zuklappbare Kontextmenüs oder der Effekt, dass KDE bestimmte Anwendungen einfach “vergisst”, sodass sie sich nicht mehr durch Klick auf das Fenster aktivieren lassen.

Fenster der Zukunft

Es kostet so gut wie keinen Aufwand, KDE oder Gnome unter Wayland auszuprobieren: Gnome-Anwender installieren im YaST-Modul Software als Schema die Gnome-Desktop-Umgebung (Wayland), wobei es eigentlich nur um das Paket gnome-session-wayland geht. KDE-Anwender benötigen keine zusätzlichen Pakete.

Zum Starten genügt es, im Anmeldebildschirm als Arbeitsflächen-Sitzung entweder Plasma (Wayland) oder GNOME on Wayland auszuwählen. Sind Sie mit der Stabilität des Desktops unter Wayland nicht zufrieden, wählen Sie bei der nächsten Anmeldung wieder eine X11– oder Xorg-basierte Sitzung.

Mancher wird sich fragen, welche Vorteile das vergleichsweise unausgereifte Wayland gegenüber X11 bringen soll. Hier sei erwähnt, dass Wayland die zwei Ziele, mit denen es entworfen wurde, bereits erreicht: Nur das Wayland-Programm mit Fokus besitzt Zugriff auf Maus und Tastatur. Auf dem 8-Kern-Rechner des Autors waren zwar auch unter X11 praktisch nie Hänger oder ein Tearing bei den Desktop-Animationen wahrzunehmen, dennoch wirkt der Ablauf der Animationen unter Wayland glatter.

Ressourcen-Einsparungen sind im Moment nicht zu erwarten, da gegenwärtig während einer Wayland-Sitzung sogar zwei Instanzen des X-Servers im Hintergrund laufen: Der Anmeldebildschirm basiert in der Voreinstellung auf X11 [7], auch wenn er eine Wayland-Session starten soll. Außerdem wartet im Hintergrund der Desktop-Sitzung ein X-Server, der sich um noch nicht Wayland-kompatible Programme kümmert. Alle Anwendungen, die auf die Toolkit-Bibliotheken Qt und GTK aufsetzen, sollten dank ihres Unterbaus ohne weitere Veränderungen bereits mit Wayland zusammenarbeiten.

Um zu ermitteln, ob ein Programm im Wayland-Modus läuft, installieren Sie das Paket xeyes (Abbildung 5, Mitte): Folgen seine Augen dem Mauszeiger, wenn Sie ihn über ein Programmfenster bewegen, dann läuft es unter X11. Bleiben sie starr, dann liegt eine Wayland-Anwendung vor. Das demonstriert zugleich, dass dort Benutzereingaben immer nur ein Programm erreichen und für die nicht aktiven Anwendungen verborgen bleiben.

Klang der Zukunft

Bereits der Linux-Kernel spielt Sound aus mehreren Quellen gleichzeitig ab. Seit 2012 benutzt OpenSuse trotzdem den Soundserver Pulseaudio. Die Lautstärkeregler der Desktop-Umgebungen (Abbildung 7) ermöglichen es, die Lautstärke einzelner Programme zu regeln, auf bestimmte Soundkarten umzuleiten oder die Priorität eines nur temporär angeschlossenen USB- oder Bluetooth-Audiogeräts so festzulegen, dass es sofort nach dem Verfügbarwerden die Wiedergabe übernimmt. Zu guter Letzt macht die Tatsache Pulseaudio unverzichtbar, dass manche Programme wie Firefox ohne es gar keinen Ton mehr abspielen – bis jetzt, denn mit Pipewire steht ein Nachfolger in den Startlöchern.

Abbildung 7: KDE und ähnlich auch Gnome regeln dank Pulseaudio nicht nur die Lautstärke der Audiogeräte, sondern auch die der einzelnen Anwendungen.

Tatsächlich gibt es einige Gründe, Pulseaudio durch einen modernen Nachfolger zu ersetzen. Dazu zählt etwa der durchwachsene Ruf von Pulseaudio hinsichtlich Stabilität. Vor allem die Frühphase des Einsatzes unter Ubuntu ab Version 8.04, bei der sich ein Großteil der Bug-Reports im Bereich Audio auf Pulseaudio zurückführen ließ, blieb Linux-Veteranen im Gedächtnis.

Tatsächlich kämpfte der Autor dieses Artikels stets mit dem Problem, dass Pulseaudio immer wieder die Einstellungen vergaß, insbesondere die Deaktivierung des in der Grafikkarte integrierten Sound-Devices. Seit dem Umstieg auf Pipewire im August 2021 traten solche Probleme nicht mehr auf. Andererseits erforderten bis Anfang 2022 gelegentliche Abstürze des Servers einen Neustart von Pipewire. Die Software gilt noch als instabil; ihre Entwickler rechnen, wie die niedrige Versionsnummer andeutet, noch mit grundlegenden Fehlern.

Zur hohen Nutzerzufriedenheit [8] trotz der frühen Version kommt hinzu, dass Pipewire zwei Fliegen mit einer Klappe schlägt: Es ersetzt nicht nur Pulseaudio, sondern gleichzeitig auch den für den professionellen Aufnahmeeinsatz mit minimalen Latenzen konzipierten Soundserver Jack. Sowohl für Pulseaudio als auch für Jack ausgelegte Programme funktionieren auf Anhieb.

Anfangs war Pipewire ausschließlich als Tool für Video-Streaming gedacht, das Videokonferenzprogrammen anders als unter X11 erst nach expliziter Nachfrage das Aufnehmen von Wayland-Fenstern gestattet. Diese Funktion ging mit dem Einbau der Audio-Routing-Fähigkeiten nicht verloren [9].

Um von Pulseaudio auf Pipewire umzusteigen, installieren Sie die Pakete pipewire und pipewire-pulseaudio. Dann starten Sie die entsprechenden Dienste mit den Befehlen aus Listing 2. Für eine Rückkehr zu Pulseaudio notieren Sie sich die bei diesem Vorgang deinstallierten Pulseaudio-Pakete (Abbildung 8).

# systemctl --user enable --now pipewire.socket
# systemctl --user enable --now pipewire-pulse.socket
# systemctl --user enable --now wireplumber.service

Abbildung 8: Um zu Pulseaudio zurückzukehren, genügt es, die von YaST bei der Pipewire-Installation als entfernt gelisteten Programme wieder zu installieren.

Pipewire befindet sich noch in einer Phase der zügigen Verbesserung, von der Tumbleweed-Anwender profitieren. Die in Leap enthaltene Version 0.3.49 vom März 2022 sollte ebenfalls bereits stabil genug laufen, damit sich ein Umstieg lohnt. Sowohl das altbekannte Verwaltungswerkzeug für Pulseaudio, Pavucontrol, als auch QJackCtl für Jack lassen sich wie gewohnt weiterverwenden (Abbildung 9).

Abbildung 9: Verwaltungsprogramme wie Pavucontrol (links, für Pulseaudio) oder QJackCtl (rechts, für Jack) funktionieren auch mit Pipewire.

Fazit

Wayland, Flatpak und der neue Soundserver Pipewire schicken sich an, altgediente Techniken wie X11, die distributionsgebundenen RPM-Pakete und Pulseaudio zu ersetzen. Dass den neuen Technologien die Zukunft gehört, scheint unausweichlich.

X11 gilt architektonisch als veraltet und unsicher; selbst seine eigenen Entwickler votieren dafür, es mittelfristig in Rente zu schicken. Viele Distributoren stöhnen unter der Last, immer mehr Programme in aktueller Version anbieten zu müssen. Wenn die Entwickler selbst zunehmend ein generisches Paket ihrer Software für alle Linux-Varianten ausliefern, gelangen Anwender auch dann an die aktuellste Version der Software, wenn die Distributions-Updates hinterherhinken.

Pulseaudio zeigt sich in der Praxis auch nach 10 Jahren Einsatz bei OpenSuse noch fehlerbehaftet. Pipewire scheint schon jetzt bei Version 0.3 auf einem besseren Weg, wenn es nicht sogar bereits stabiler funktioniert. Es vereinheitlicht außerdem das alltagstaugliche Pulseaudio mit dem für professionelles Recording optimierten Jack, was Paul Davis, der Entwickler von Jack und des meistgenutzten freien Musikprogramms Ardour, ausdrücklich lobt [10].

OpenSuse prescht bei den neuen Techniken weder vor, wie Fedora oder Ubuntu, die Pulseaudio schon durch Pipewire ersetzt haben, noch zwingt es sie dem Nutzer auf. Letzteres versucht etwa Ubuntu, das viele Pakete nur noch als Snaps anbietet, also als Ubuntu-spezifisches Pendant zu Flatpaks. Dem Anwender die Wahl zwischen den alten und neuen Technologien zu lassen, wie OpenSuse das tut, ist schon deshalb die richtige Politik, weil Anwendern so der Umstieg ohne großen Aufwand gelingt. (tle)