Von daher bin ich froh, dass es mit Ghostty ein modernes Terminal mit Tiling-Funktion gibt, das auf GTK 4 und libadwaita aufsetzt. Bei mir ersetzt es inzwischen Tilix, das ich euch 2016 noch unter dem Namen Terminix vorgestellt habe. Ausführlich getestet habe ich Ghostty in der LinuxUser 06/2026. Jetzt ist Version 1.4 erschienen. Die bringt einige Neuerungen mit, die gerade Linux-User betreffen.

Was ist Ghostty?

Für alle, die Ghostty noch nicht kennen: Das Terminal stammt von Mitchell Hashimoto, der vielen als Gründer von HashiCorp (Vagrant, Terraform) bekannt sein dürfte. Ghostty soll schnell sein, viele Funktionen mitbringen und sich trotzdem wie eine normale Desktop-Anwendung anfühlen. Unter Linux nutzt es dafür GTK 4 und fügt sich so gut in GNOME ein. Ghostty ist freie Software unter der MIT-Lizenz.

Tabs, Splits und eine Übersicht aller offenen Tabs bringt Ghostty von Haus aus mit. Neue Splits öffnet ihr mit Strg+Umschalt+O nach rechts und mit Strg+Umschalt+E nach unten. Eine Menüleiste mit Einstellungsdialogen gibt es dagegen nicht. Konfiguriert wird Ghostty über die Textdatei ~/.config/ghostty/config. Außerdem können Programme in Ghostty Bilder direkt im Terminal anzeigen, etwa als Vorschau im Dateimanager.

Weniger Speicherbedarf für schwächere Rechner

Ghostty 1.4 packt den Verlauf zusammen, sobald im Terminal gerade nichts passiert. Laut den Entwicklern braucht er damit 70 bis 90 Prozent weniger Speicher. Im Alltag dürften das die wenigsten spüren. Wer aber das Maximum aus einem schwächeren Rechner herausholen möchte oder mit riesigen Dateien und Ausgaben hantiert, der braucht auch ein Terminal, das sparsam mit den Ressourcen umgeht.

Gleichzeitig merkt sich Ghostty jetzt mehr. Pro Terminal hebt das Projekt den Verlauf von 10 auf 50 MByte an, ihr könnt also deutlich weiter zurückscrollen. Beim Scrollen oder Suchen entpackt Ghostty die Daten unbemerkt wieder. Die Kompression gibt es unter 64-Bit-Linux und macOS. Wer sie nicht möchte, schaltet sie mit scrollback-compression = false ab. Was eine Option tut, verrät euch Ghostty übrigens selbst.

Schärfere Schrift bei krummer Skalierung

Nutzt ihr einen Monitor mit 125 oder 150 Prozent Skalierung, dürfte euch die nächste Neuerung freuen. Bisher wirkte die Schrift in Ghostty bei solchen Werten leicht unscharf. Mit 1.4 werden Text und Rahmenzeichen auch dort sauber dargestellt. Dazu hat das Projekt die Darstellung unter Linux neu geschrieben. Bildrisse, wie man sie etwa beim Scrollen sieht, sollen dabei kaum noch auftreten.

Der Umbau hat allerdings seinen Preis. Ghostty 1.4 braucht mindestens GTK 4.18 und libadwaita 1.7, unter einem aktuellen Arch Linux ist das kein Thema. Ubuntu 24.04 LTS bringt dagegen zu alte Versionen mit. Wer noch auf der alten LTS sitzt, bleibt laut den Entwicklern besser bei einer älteren Ghostty-Version oder greift zu einem Flatpak.

Splits mit der Maus verschieben

Wer viel mit Splits arbeitet, dürfte sich über diese Neuerung freuen: Splits lassen sich jetzt mit der Maus umsortieren. Fahrt ihr an den oberen Rand eines Splits, erscheint ein Griff mit drei Punkten. Den zieht ihr auf einen anderen Split, und eine blaue Fläche zeigt, wo er landen wird. Das klappt auch zwischen Tabs und Fenstern. Laufende Programme, Ausgabe und Arbeitsverzeichnis wandern dabei mit.

So könnt ihr etwa ein laufendes htop von unten nach links verschieben, ohne es neu starten zu müssen. Unter Linux lässt sich ein Split allerdings nur auf einem anderen Split ablegen, nicht als eigener Tab oder eigenes Fenster. Ganze Tabs lagert ihr dagegen über die Befehlspalette in ein neues Fenster aus. Stört euch der Griff, blendet ihr ihn mit drag-handle = never aus.

Fenster benennen und eine deutsche Befehlspalette

Habt ihr mehrere Ghostty-Fenster für verschiedene Projekte offen, verliert man schnell den Überblick. Fenster lassen sich deshalb jetzt über das Menü umbenennen, etwa in „Blog“ oder „Server“. Lasst ihr das Feld im Dialog leer, kehrt Ghostty zum automatischen Titel zurück. Die Befehlspalette ist zudem vollständig übersetzt. Sie zeigt alle Aktionen auf Deutsch an und nennt, falls vorhanden, das passende Tastenkürzel.

Praktisch für Fans eines Drop-down-Terminals im Stil von Guake: Mit dem neuen Befehl ghostty +toggle-quick-terminal blendet ihr das Quick Terminal von Ghostty ein und aus, etwa per eigenem Tastenkürzel. Das klappt unter Plasma, Sway oder Hyprland, aber nicht unter GNOME, dem dafür eine Schnittstelle fehlt. Neu ist auch die Wahl des Bildschirms, auf dem das Quick Terminal erscheint.

Bilder im Terminal und mehr Tempo

Programme können in Ghostty Bilder über das Kitty-Grafikprotokoll anzeigen. Mit 1.4 beherrscht Ghostty das Protokoll vollständig, inklusive animierter Bilder, und lädt große Grafiken spürbar schneller. Davon profitieren Dateimanager für das Terminal wie Yazi oder Tfm, die Bilder direkt in ihrer Vorschau anzeigen. So findet ihr das richtige Foto, ohne extra einen Bildbetrachter zu öffnen.

Auch sonst ist Ghostty schneller geworden. Reinen Text verarbeitet das Terminal laut den Messungen des Projekts 5,7-mal so schnell wie bisher. Das merkt ihr etwa, wenn ein Build oder ein Log viele Zeilen ins Terminal schreibt. Das Ändern der Fenstergröße soll bei langem Verlauf bis zu sechsmal flotter gehen. Einige der übrigen Zahlen aus den Release Notes gelten allerdings nur für macOS.

Keine Fehlermeldungen mehr per SSH

Wer sich mit Ghostty per SSH auf einem Server anmeldet, kennt vielleicht Fehler wie „missing or unsuitable terminal: xterm-ghostty“. Dann funktionieren Programme wie htop oder nano auf dem Server nicht richtig, weil der Server Ghostty nicht kennt. Neu ist der Befehl ghostty +ssh, der dem Server die nötigen Informationen bei Bedarf gleich mitgibt. Klappt das nicht, nutzt er eine kompatible Einstellung.

$ ghostty +ssh user@server

Ein Update lohnt sich zudem aus Sicherheitsgründen. Ghostty 1.4 schließt zehn Lücken. Unter anderem konnten präparierte Grafikbefehle das Terminal zum Absturz bringen. Außerdem ließ sich der Schutz beim Einfügen von Text austricksen, der eigentlich davor warnen soll, mehrzeilige Befehle versehentlich sofort auszuführen. Einige der Lücken betreffen allerdings nur macOS oder die Zsh als Shell.

Achtung bei Tastenkürzeln und Kopieren

Ein paar Änderungen brechen mit altem Verhalten. Unter Linux verschieben Strg+Umschalt+Bild auf und Strg+Umschalt+Bild ab jetzt Tabs. Zum vorherigen oder nächsten Prompt springt ihr dafür mit Strg+Umschalt+Pfeil hoch und Strg+Umschalt+Pfeil runter. Programme im Terminal bekommen diese Tastenkombinationen nicht mehr zu sehen. Wer sie dort braucht, hebt die Belegung in der Konfiguration mit unbind wieder auf.

Habt ihr eingestellt, dass Ghostty markierten Text automatisch kopiert, solltet ihr ebenfalls einen Blick in die Konfiguration werfen. Mit copy-on-select = clipboard landet die Auswahl jetzt nur noch in der normalen Zwischenablage. Wollt ihr sie wie bisher auch mit der mittleren Maustaste einfügen, stellt ihr den Wert auf both um. Was die mittlere Maustaste einfügt, legt middle-click-action fest.

libghostty: Ghostty steckt bald in anderen Programmen

In der Diskussion auf Hacker News zum Release lenkt Mitchell Hashimoto den Blick auf libghostty. Die Bibliothek enthält den Kern von Ghostty, also alles, was ein Terminal im Inneren ausmacht. Andere Programme können ihn nutzen, statt ein eigenes Terminal zu programmieren. Ghostty selbst nennt Hashimoto scherzhaft „just a glorified tech demo for libghostty“.

Für euch heißt das: Ghosttys Technik taucht nach und nach auch in anderen Programmen auf. Die Terminals in den IDEs von JetBrains laufen bereits darauf, für Neovim ist der Umstieg im Gespräch. Und ein KDE-Entwickler baut ein neues Terminal auf Basis von libghostty, das langfristig Konsole beerben könnte. Version 1.0 der Bibliothek soll in den nächsten Monaten erscheinen.

Installation

Unter Arch Linux liegt Ghostty im Repository Extra, zum Zeitpunkt dieses Artikels allerdings noch in Version 1.3.1. Version 1.4 dürfte dort in den nächsten Tagen folgen. Neben dem Terminal selbst solltet ihr auch die Shell-Integration und das Terminfo installieren. Wer nicht warten möchte, findet im AUR das Paket ghostty-nightly-bin, das ich auch für die Screenshots in diesem Artikel genutzt habe.

$ sudo pacman -S ghostty ghostty-shell-integration ghostty-terminfo

Fertige Pakete für Linux stellt das Projekt selbst nicht bereit, darum kümmern sich die Distributionen. Ubuntu führt Ghostty seit 26.04 in den offiziellen Paketquellen, wenn auch nicht immer in der neuesten Version. Für Fedora gibt es ein COPR-Repository, dazu kommen ein Snap, ein AppImage und ein Debian-Paket aus der Community. Einen Überblick liefert die Installationsanleitung von Ghostty.

Alles in allem ist Ghostty 1.4 in meinen Augen ein rundes Update. Für Tilix-Umsteiger wie mich ist es gut zu sehen, dass sich ein modernes Tiling-Terminal auf GTK-Basis so aktiv weiterentwickelt. Wer näher am Bedienkonzept von Tilix bleiben möchte, sollte sich auch Rutile anschauen. Alle Änderungen findet ihr in den Release Notes. Mit welchem Terminal arbeitet ihr?

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Das Wichtigste vorweg: Das Umschalten der Profile hat nie gehakt, denn der Systemdienst tccd spricht weiterhin über dieselbe Schnittstelle mit Pulsgeber. Gestolpert ist die Erweiterung über Dinge drumherum. So heißt die Desktop-Datei des Control Centers jetzt com.tuxedocomputers.tcc.desktop. Pulsgeber hat die App deshalb nicht mehr gefunden, und der Eintrag TUXEDO Control Center fehlte im Menü der Pille.

Aus demselben Grund griff eine zweite Funktion nicht mehr: Ist das Tray abgeschaltet, beendet Pulsgeber das Control Center, sobald ihr sein Fenster schließt. Sonst liefe die App unsichtbar im Hintergrund weiter. Dazu kommt, dass das TCC seit 3.1 in einem anders benannten systemd-Scope läuft. Pulsgeber hat dort nur noch ein paar Hilfsprozesse erwischt, aber nicht den Hauptprozess. Beides ist jetzt behoben.

Kurioser ist die Sache mit dem Autostart. Bisher startete das Tray, wenn die Datei tuxedo-control-center-tray.desktop in ~/.config/autostart lag. Seit 3.1 bringt das Paket den Eintrag systemweit in /etc/xdg/autostart mit, und eine Datei im Home-Verzeichnis schaltet ihn ab, statt ihn einzuschalten. Pulsgeber hat also genau das Gegenteil von dem gemacht, was der Schalter Tray des TCC nicht starten verspricht.

Ganz rund läuft es aber auch beim TCC selbst nicht. Zum Abschalten legt das TCC eine leere Datei an, mit der gnome-session unter GNOME 51 nichts anfangen kann. Das Journal meldet, die Datei lasse sich nicht lesen, und das Tray startet trotzdem. Pulsgeber schreibt stattdessen eine Kopie des Eintrags mit Hidden=true, wie es die Spezifikation vorsieht. Das TCC zeigt den Autostart dann ebenfalls als abgeschaltet an.

Beim Test in meiner eigenen Sitzung kam dann noch ein älterer Fehler ans Licht: Seit Version 0.5.0 hat der Schalter überhaupt nichts bewirkt. Die Einstellungen brachen ab, bevor sie die Autostart-Datei schreiben konnten. Das Beenden des Trays übernimmt deshalb jetzt die Erweiterung selbst, sobald sich die Datei ändert. Mit 0.5.2 verschwindet das Tray sofort und startet auch nach dem nächsten Anmelden nicht mehr.

Wer noch ein älteres Control Center nutzt, merkt von alldem nichts. Pulsgeber erkennt am systemweiten Autostart-Eintrag, welches Verfahren gilt, und verhält sich mit TCC 3.0 und älter wie gehabt. Getestet ist die neue Version mit GNOME 51.1 und TCC 3.1.1 auf meinem InfinityBook S 17 Gen6. GNOME 51 selbst brauchte übrigens keine Anpassung, die Erweiterung lief dort schon vorher ohne Fehlermeldungen.

Bis die Aufnahme in den Katalog der Gnome-Exentsions klappt, gibt es das Update wie gehabt als ZIP-Paket auf der Release-Seite bei GitHub. Habt ihr Pulsgeber schon installiert, spielt ihr die neue Version einfach über die alte, dafür sorgt der Parameter --force:

$ gnome-extensions install --force pulsgeber@linuxundich.de.shell-extension.zip

Unter Wayland lädt GNOME die neue Version erst nach dem nächsten Ab- und Anmelden. Alle Änderungen im Detail stehen im Changelog, Screenshots und Antworten auf häufige Fragen auf der Projektseite von Pulsgeber. Hakt bei euch nach dem Update des Control Centers noch etwas, dann meldet euch gerne hier in den Kommentaren oder als Issue auf GitHub.

Transparenzhinweis: Ich arbeite für TUXEDO Computers. Pulsgeber ist allerdings ein privates Projekt, das KI-unterstützt in meiner Freizeit entstanden ist. Es ist kein Produkt von TUXEDO und erhält keinen offiziellen Support von TUXEDO.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Die Startseite ließ Epiphany kurzerhand komplett einfrieren. Im Journal fand sich anschließend ein Speicherabzug des Webprozesses, und systemd hatte eine Speicherspitze von 5,8 GB notiert. Für eine Nachrichtenseite mit ein paar Kärtchen ist das in meinen Augen dann doch etwas viel. Ein Neustart brachte nichts: Epiphany stellt brav den PlanetFOSS-Tab wieder her und verschluckt sich prompt erneut.

Auf Spurensuche

Ein Blick in die Paketchronik brachte den ersten Hinweis: Arch Linux hatte am 7. Oktober WebKitGTK, die Browser-Engine hinter Epiphany, auf Version 2.54 aktualisiert. Den Browser selbst konnte ich schnell entlasten. Der MiniBrowser, ein schlichter Testbrowser, der bei WebKitGTK mit dabei ist, lief mit der PlanetFOSS-Startseite innerhalb von Sekunden auf mehrere Gigabyte auf. Eine schlichte Beispielseite kommt dagegen mit 170 MB aus.

Die Spur führt zum Sternchen

Bei der Fehlersuche hat mir eine KI unter die Arme gegriffen, die Eingrenzung lief dann ganz klassisch per Ausschlussverfahren. Ohne JavaScript hing die Seite weiterhin, ohne Stylesheet lief sie dagegen brav. Danach flog eine Gestaltungsregel nach der anderen raus, bis der Übeltäter feststand: backdrop-filter. Der zeichnet den Hintergrund hinter einem Element unscharf und sorgt so für den beliebten Milchglas-Effekt.

Den Effekt nutzt PlanetFOSS an mehreren Stellen, vor allem aber an den kleinen Merken-Sternchen oben links auf jeder Artikelkarte. Davon gibt es auf der Startseite 55 Stück, dazu acht Nachrichtenkarten und zehn Play-Symbole auf den Videos. Jedes dieser Elemente bekommt seine eigene Milchglas-Ebene. In der Masse geht WebKitGTK 2.54 dabei offenbar in die Knie. Kleines Sternchen, große Auswirkungen eben.

Zur Gegenprobe habe ich mir eine Testseite mit lauter Kärtchen gebaut, jedes mit einem kleinen Milchglas-Element. Bei zehn bis 14 Karten blieb der Speicher im grünen Bereich, bei 18 Karten war schon rund ein Gigabyte belegt. Ab 22 Karten schoss der Verbrauch auf sieben bis acht Gigabyte. Irgendwo um die 20 Ebenen kippt die Sache also, ganz genau festnageln lässt sich die Grenze aber nicht.

Spannend dabei: Am Weichzeichnen selbst liegt es gar nicht. Auch ein Milchglas ohne jede Unschärfe oder ein simpler Graufilter bläht WebKitGTK genauso auf. Das Problem steckt also darin, wie die neue Version solche Ebenen verwaltet. Schaltet man die Grafikbeschleunigung der Engine ab, bleibt die Testseite zwar schlank. Als Lösung taugt das aber nicht, schließlich kann ich meinen Besuchern schlecht vorschreiben, wie sie ihren Browser starten.

Firefox und Chrome lässt das kalt

Bleibt die Frage, ob nur WebKitGTK betroffen ist. Dazu habe ich dieselbe Kopie der Startseite einmal mit der alten und einmal mit der neuen Gestaltung in verschiedenen Browsern geladen und jeweils den Speicherverbrauch gemessen. Das Ganze einmal auf meinem Arch-Notebook und einmal in einer virtuellen Maschine mit Ubuntu 26.04. Bilder und Texte waren in allen Durchgängen identisch.

Das Ergebnis ist eindeutig. Firefox und Chrome zeigen vorher und nachher praktisch den gleichen Verbrauch. Auch die ältere WebKitGTK-Version 2.52 von Ubuntu bleibt mit rund 680 MB völlig gelassen. Nur die Version 2.54 explodiert: Auf meinem Notebook kletterte der Speicherbedarf in 40 Sekunden auf 9,8 GB, nach dem Umbau der Seite waren es gerade einmal 300 MB.

In der VM lief Epiphany als Flatpak, das die neue Engine gleich mitbringt. Dort blähte sich der Browser in einer Minute auf 4,3 GB auf, bis von gut 5 GB Arbeitsspeicher gerade noch 300 MB frei blieben. In einem früheren Durchgang warf der Tab gleich ganz das Handtuch: Hoppla! Beim Anzeigen dieser Seite ging etwas schief. Mit der neuen Gestaltung blieb es bei 721 MB.

Deckender Hintergrund statt Milchglas

Die Lösung auf Seiten von PlanetFOSS ist unspektakulär. Sternchen, Nachrichtenkarten und Play-Symbole verzichten jetzt aufs Milchglas, dafür ist ihr Hintergrund einfach etwas weniger durchsichtig. Den Unterschied sieht man eigentlich nur, wenn man beide Versionen direkt nebeneinanderlegt und ganz genau hinschaut. Für ein paar Gigabyte weniger Speicherhunger ist das in meinen Augen ein mehr als fairer Tausch.

Seit ein paar Tagen ist die Änderung live, und der MiniBrowser kommt mit der echten Startseite wieder mit 213 MB aus. Den Milchglas-Effekt in der aufklappenden Rubrikenleiste und an den Quellen-Links im Aufmacher habe ich behalten. Das sind nur eine Handvoll Ebenen, und die bringen WebKit nicht aus dem Tritt. Auch linuxundich.de nutzt den Effekt nur an zwei Stellen und war deshalb nie betroffen.

Alles in allem steckt das Problem klar in WebKitGTK 2.54 und nicht in meinem Stylesheet. Betroffen sind wohl alle Seiten, die genügend Elemente mit backdrop-filter verwenden. Von daher mein Rat an alle, die Websites bauen: Milchglas lieber sparsam dosieren und die Seite auch mal in Epiphany laden. Einen Fehlerbericht samt Testfall habe ich im WebKit-Bugzilla eingereicht. Hoffentlich habe ich niemandem die Browsersitzung gekillt.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Javad kam 2020 zum Team, weil damals die Dokumentation für Shell-Erweiterungen fehlte. Also entstanden YouTube-Tutorials und später, auf Einladung von Sriram Ramkrishna und dessen Projekt GNOME Extensions Rebooted, der Port Guide für GNOME Shell 40. Der half vielen beim Umstieg von GTK3 auf GTK4, und ohne ihn hätten laut Javad etliche Autoren aufgegeben.

Heute gibt es die gesamte Dokumentation, die man für eigene Erweiterungen braucht. Trotzdem vibe-coden viele ihre Extensions und reichen sie bei EGO ein, ohne je einen Blick in die Doku geworfen zu haben. Javad fühlt sich deshalb, als füttere die Dokumentation eher die LLMs als menschliche Entwickler. Seit Anfang 2025 explodieren die Einreichungen, und die große Mehrheit ist KI-generiert.

Javad beantwortet seit Jahren täglich Fragen und prüft Erweiterungen, oft 4 bis 10 Stunden am Tag. Das ist unbezahlt und entspricht locker einem Vollzeitjob, die monatlichen Spenden liegen dagegen nahe null. Die Folge: Javad steht nah am Burnout und schreibt, ohne finanzielle Unterstützung nicht mehr in diesem Tempo weitermachen zu können. Immerhin gab es 2026 den GNOME Pants Award.

Das Hauptproblem ist die Qualität. Erweiterungen laufen direkt im Prozess der GNOME Shell, schlechter KI-Code gefährdet also die Stabilität des ganzen Desktops. Laut Javad erzeugen LLMs unnötig komplexen, schwer lesbaren Code, der im Review deutlich länger dauert. Manche Einreicher lassen sogar ihre Antworten von einer KI schreiben, und einmal landeten dabei versehentlich die Anweisungen an das Modell im Text.

Einen Lichtblick gibt es allerdings: Javads offener Brief an KI-Modelle korrigierte konkrete Code-Muster, die die Modelle falsch erzeugten. Nach wenigen Wochen waren die meisten dieser Fehler verschwunden. Javad nimmt das als gute Nachricht, aber auch als Beweis dafür, wie stark die Dokumentation die Modelle füttert. Gelöst ist das Review-Problem damit nicht.

Wer wird gesucht?

• Reviewer: Gefragt sind Entwickler mit Kenntnissen in GTK und im Quellcode der GNOME Shell. Die Rolle ist ehrenamtlich, die Verfügbarkeit unter der Woche sollte konstant sein. Javad bietet Mentoring an und bringt euch den Review-Prozess bei.
• Shexli-Helfer: Den Linter gibt es seit ein paar Monaten, er soll Reviews erleichtern. Reviewer melden False Negatives und False Positives, und wer mithilft, behebt sie in Shexli. Gesucht wird jemand, der den Linter verbessert.
• Spender: Wer die Arbeit finanziell unterstützen möchte, findet die Spendenseite.

Wer im Review-Team mitmachen oder bei Shexli helfen möchte, meldet sich im Matrix-Kanal #extensions:gnome.org. Eine feste Frist nennt Javad nicht, wohl aber den Grund zur Eile: Ohne mehr Hilfe geht es in diesem Tempo nicht weiter. Meldet euch also lieber früher als später, auch für eine erste Rückfrage ohne feste Zusage.

In meinen Augen ist das ein Weckruf für alle, die GNOME-Erweiterungen im Alltag nutzen. Ohne Reviewer gibt es keine geprüften Erweiterungen, und ohne geprüfte Erweiterungen fehlt vielen von uns ein gutes Stück GNOME. Wer Zeit und das nötige Know-how hat, sollte sich das also ernsthaft überlegen. Alle anderen können zumindest ein paar Euro in die Spendenkasse werfen.

Räusper. Ich auch.

Ich muss gestehen, dass ich mich da selbst angesprochen fühle. Mit Pulsgeber habe ich eine GNOME-Shell-Erweiterung geschrieben, die KI-unterstützt entstanden ist. Und ja, ich habe durchaus Respekt davor, sie bei EGO einzureichen. Der Gedanke, dass jemand den entstandenen Code Zeile für Zeile durchgehen muss, ist mir nicht ganz geheuer. Ich möchte niemandem Arbeit aufhalsen, schon gar nicht einem Team, das ohnehin am Limit läuft.

Trotzdem sollte man in meinen Augen nicht jeden KI-Beitrag als KI-Slop brandmarken. Solche Erweiterungen bringen vieles voran und ermöglichen Funktionen, die vorher außer Reichweite lagen. Entscheidend ist am Ende die Qualität des Codes, nicht das Werkzeug, mit dem er entstanden ist. Das Problem sind eher ungeprüfte Massen, nicht die KI an sich.

Dahinter steckt für mich auch diese Frage: KI-Code ist schnell erzeugt, aber jemand muss ihn trotzdem lesen und prüfen. Das dürfte nicht nur EGO treffen, sondern jedes Projekt, das Beiträge von außen annimmt und vor der Veröffentlichung prüft. Wie seht ihr das: Ist die Flut an KI-Einreichungen auch bei anderen Plattformen ein Problem, und wie sollten Projekte damit umgehen?

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Also habe ich mir selbst einen Client gebaut: Gnomos setzt auf GTK4 und libadwaita und soll sich wie ein ganz normaler Teil von GNOME anfühlen. Die aktuelle Version 0.28.5 könnt ihr als Flatpak-Bundle auf GitHub herunterladen und ausprobieren. Bei mir läuft das Programm schon eine ganze Weile, die schwerwiegendsten Bugs dürften von daher ausgeräumt sein.

Auslöser waren meine älteren Geräte. Sonos hat den Support für Produkte der ersten Generation eingestellt, darunter die ZonePlayer ZP80, ZP90, ZP100 und ZP120 sowie die Fernbedienung CR100. Die Lautsprecher selbst laufen weiter, nur die aktuelle Android-App spielt nicht mehr mit. Gnomos spricht die alten Kisten direkt über das Heimnetz an, ein Sonos-Konto oder ein Cloud-Dienst ist dafür nicht nötig.

Die Kommunikation mit den Lautsprechern übernimmt noson, die Bibliothek hinter der Noson-App. Darauf sitzt eine eigene Oberfläche, die sich an den aktuellen GNOME-Designprinzipien orientiert, anstatt die offiziellen Sonos-Apps oder das Vorbild Noson-App nachzubauen. Disclaimer vorweg: Bei der Entwicklung hat mir eine KI das Heavy-Lifting abgenommen. Architektur, technische Entscheidungen und Tests liegen allerdings bei mir.

Jetzt läuft, mit Liedtext

Klickt ihr auf die Wiedergabeleiste am unteren Fensterrand, füllt der aktuelle Titel das ganze Fenster. Das Cover erscheint groß auf einem Hintergrund in dessen Farben. Daneben stehen die nächsten Titel der Warteschlange und, sofern ihr es einschaltet, synchrone Liedtexte von LRCLIB. Ein Klick auf eine Zeile springt an die passende Stelle im Lied.

Wer es nostalgisch mag, lässt das Cover als Schallplatte rotieren. Eine Spielerei, klar, aber ein nettes Detail. Dazu kommt ein Mini-Player im Posterstil: Das Cover füllt ein kleines, quadratisches Fenster. Die Bedienelemente blenden erst ein, wenn ihr mit der Maus darüberfahrt. So bleibt die Musik im Blick, ohne viel Platz auf dem Desktop zu belegen.

Alle Räume an einem Ort

Die Raumauswahl in der Kopfleiste zeigt, was gerade in welchem Zimmer läuft. Zieht ihr einen Raum auf einen anderen, gruppiert Gnomos beide, ein Klick löst die Gruppe wieder auf. Innerhalb einer Gruppe stellt ihr die Lautstärke pro Raum ein. Jedes Zimmer lässt sich zudem per Klick starten oder pausieren, ohne dass die Gruppe dafür aufgelöst werden muss.

Auch die Warteschlange bearbeitet ihr direkt in der App. Titel verschiebt oder entfernt ihr, eine fertige Liste speichert ihr als Sonos-Playlist. Dazu kommen Favoriten und die Sonos-Alarme, die ihr anlegen, bearbeiten und duplizieren könnt. Einen Wiedergabeverlauf führt Sonos selbst nicht, von daher zeichnet Gnomos ihn lokal auf. Über jeden Eintrag findet ihr Interpret oder Album später wieder.

Die ganze Musiksammlung

Gnomos durchsucht die Musikfreigabe im Netzwerk, Sonos-Favoriten und -Playlists, Internetradio und die Dienste, die ihr in Sonos verknüpft habt. Dazu zählen Spotify und über bonob auch Navidrome oder andere Subsonic-Server. Große Bibliotheken öffnen sich zügig als Cover-Raster, wahlweise auch als Liste. Ein Live-Filter hilft bei langen Listen, Internetradio-Sender sucht ihr über radio-browser.info nach Name oder Land.

Teil des GNOME-Desktops

Gnomos unterstützt MPRIS2. Medientasten, Sperrbildschirm und der Player in den Schnelleinstellungen funktionieren daher sofort, inklusive Shuffle und Wiederholung. Optional gibt es eine kleine Shell-Erweiterung, die für jeden Raum einen eigenen Lautstärkeregler in die Schnelleinstellungen setzt. Sie steckt nicht im Flatpak, ihr installiert sie getrennt, die Anleitung dazu liegt im Repository. Dann regelt ihr die Räume, ohne die App zu öffnen.

Dazu kommen ein Dunkelmodus, Desktop-Benachrichtigungen bei Titelwechsel und Tastenkürzel für Wiedergabe, Lautstärke, Suche und aktuellen Titel. An den Lautsprechern selbst stellt ihr Bass, Höhen, Loudness, Nachtmodus und Subwoofer ein. Ein Dialog pro Raum zeigt Modell, IP- und MAC-Adresse sowie die Softwareversion, praktisch bei mehreren Geräten im Netz. Geräte der ersten Generation kennzeichnet die App mit einem eigenen Hinweis.

Wie das alles zusammenspielt, seht ihr in einem kurzen Video, in dem ich Gnomos bei der Arbeit zeige und die wichtigsten Funktionen durchgehe.

Für die Steuerung selbst verlässt Gnomos das Heimnetz nicht. Online fragt die App nur zwei Dinge ab: Liedtexte bei LRCLIB und Künstlerfotos über die öffentliche Deezer-API. Beides ist standardmäßig ausgeschaltet, ihr entscheidet in den Einstellungen selbst, ob ihr es nutzen wollt. Alles andere bleibt im eigenen Netzwerk, es gehen keine Daten an Dritte, auch nicht heimlich.

Installation

Gnomos gibt es bisher nur als Flatpak-Bundle. Mein Plan ist, die App auf Flathub zu bringen, dafür braucht es aber noch ein paar mehr Tester. Bis dahin ladet ihr gnomos-<Version>-x86_64.flatpak von der Release-Seite herunter und installiert die Datei mit diesem Befehl:

flatpak install --user gnomos-*.flatpak

Fehlt die GNOME-51-Laufzeit, holt Flatpak sie von Flathub nach. Bundles aktualisieren sich nicht von selbst, schaut also gelegentlich auf der Release-Seite nach neuen Versionen, denn Gnomos bekommt regelmäßig Korrekturen und neue Funktionen. Die Anleitung zum Selbstbauen, die Übersetzungen (Deutsch und Englisch sind dabei) und den Quellcode findet ihr im GitHub-Repository. Gnomos steht unter der GPL-3.0.

Noch nicht fertig

Ich teste Gnomos bisher nur mit meinem eigenen Sonos-Haushalt aus Geräten der ersten Generation. Andere Modelle, neuere Generationen und ungewöhnliche Konfigurationen kann ich nicht prüfen, von daher sind Rückmeldungen Gold wert. Gnomos ist noch vor Version 1.0, und an der einen oder anderen Ecke knirscht es sicher noch. Mehr zum Projekt steht auf der Projektseite.

Für mich ist Gnomos aber längst weit genug, dass ich es im Alltag einsetze. Habt ihr Sonos-Lautsprecher und einen GNOME-Desktop? Dann probiert die App aus und schreibt mir in den Kommentaren, was bei euch klappt und was nicht, gerne auch mit anderer Hardware als meiner. Fehler und Ideen könnt ihr außerdem als Issue auf GitHub melden.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Nur bin ich schon seit Jahren mit Arch Linux und GNOME unterwegs, und daran soll sich auch auf meinem InfinityBook nichts ändern. Auf die Steuerung der Hardware durch das TCC möchte ich trotzdem nicht verzichten. Von daher wollte ich seine Fähigkeiten auch unter GNOME optimal nutzen können, und zwar so, dass sie sich wie ein selbstverständlicher Teil des Desktops anfühlen.

Herausgekommen ist Pulsgeber, eine kleine Erweiterung für die GNOME-Shell, die ab sofort in Version 0.4.0 bereitsteht. Bei der Entwicklung hat mir KI geholfen: Den Großteil des Codes hat sie geschrieben. Die Anforderungen und Entscheidungen von Name über Symbol bis zum Verhalten kamen dagegen von mir. Die Ergebnisse habe ich sorgfältig geprüft und die Erweiterung ausgiebig selbst auf meinem Notebook getestet.

Was Pulsgeber macht

Unter GNOME fühlt sich das TCC nämlich ein wenig wie ein Gast an. Das Profilmenü steckt im Tray-Icon (das es eigentlich ja gar nicht geben sollte), und die Taste für das Control Center mit dem Kürzel Super+Alt+F6 läuft unter Wayland ins Leere. Dazu funkt GNOMEs eigener Energiemodus dem TCC ständig dazwischen, denn power-profiles-daemon und der TCC-Dienst tccd schreiben dieselben Prozessoreinstellungen.

Der tccd stellt sein Profil nach wenigen Sekunden wieder her, die Umstellung im GNOME-Menü hält also nur einen kurzen Augenblick. Pulsgeber räumt hier auf. Die Erweiterung setzt eine Pille „TCC-Profil“ in die Schnelleinstellungen, genau dorthin, wo GNOME sonst seine Energiemodi anzeigt. Ein Klick auf die Pille wechselt wie gewohnt zwischen dem Standardprofil und dem zuletzt gewählten.

Das Menü daneben listet alle Profile aus dem TCC. Ein von Hand gewähltes Profil gilt dabei nur so lange, bis ihr das Netzteil ein- oder aussteckt. Danach übernimmt wieder das Profil, das ihr im TCC für Netz oder Akku hinterlegt habt. Was als Nächstes kommt, verrät euch der Kopf des Menüs, etwa „Bis Akkubetrieb, dann Cool and breezy“.

Jedes Profil bekommt ein eigenes Symbol: ein Puls fürs Stromsparen, zwei für den Mittelweg, drei für volle Leistung und ein Puls über einem Schieberegler für eure eigenen Profile aus dem TCC. Auf Wunsch zeigt die obere Leiste das Symbol an, solange nicht das Standardprofil aktiv ist. So seht ihr auf einen Blick, wie schnell euer Notebook gerade tickt.

In den Einstellungen blendet ihr außerdem GNOMEs Energiemodus aus, schaltet power-profiles-daemon auf Wunsch ganz ab und verhindert, dass das Tray des TCC überhaupt erst startet. Dazu legt ihr fest, welche Profile im Menü auftauchen und welches Symbol sie jeweils tragen. Die TCC-App braucht ihr dann nur noch, um Profile anzulegen und zu bearbeiten. Alle Schalter lassen sich jederzeit wieder zurückdrehen.

Das eigentliche Umschalten erledigt ohnehin der Systemdienst tccd, und mit dem spricht Pulsgeber direkt. Die App des Control Centers muss dafür also weder geöffnet sein noch im Hintergrund mitlaufen. Was das in der Praxis heißt, zeigt am besten das kurze Video: Ich wechsle darin die Profile über die Schnelleinstellungen, und das zur Kontrolle geöffnete TCC zieht jedes Mal direkt mit.

Installation

Pulsgeber benötigt GNOME 50 oder 51 sowie das TUXEDO Control Center samt seinem Dienst tccd. Getestet habe ich die Erweiterung bislang auf einem InfinityBook S 17 Gen6 mit GNOME 50.5 unter Arch Linux. Mein Ziel ist es, Pulsgeber auf GNOME Extensions zu veröffentlichen. Bevor ich die Erweiterung dort einreiche, möchte ich allerdings erst einmal ein wenig Feedback von euch sammeln.

Daher gibt es Pulsgeber vorerst nur über GitHub. Ladet euch das ZIP-Paket pulsgeber@linuxundich.de.shell-extension.zip von der Release-Seite herunter und installiert es im Terminal:

$ gnome-extensions install pulsgeber@linuxundich.de.shell-extension.zip

Nach dem Ab- und wieder Anmelden aktiviert ihr die Erweiterung:

$ gnome-extensions enable pulsgeber@linuxundich.de

Pulsgeber spricht Deutsch und Englisch und richtet sich nach der Sprache eures Desktops. Den Quellcode findet ihr im GitHub-Repository, Übersetzungen in weitere Sprachen nehme ich dort gerne entgegen. Das Control Center selbst ist ebenfalls freie Software, die Quellen liegen bei TUXEDO auf GitHub. Weitere Screenshots und Antworten auf die wichtigsten Fragen findet ihr auf der Projektseite von Pulsgeber.

Bei mir hat Pulsgeber das Tray-Icon des TCC komplett abgelöst: Akkubetrieb unterwegs, volle Leistung am Schreibtisch, und das ohne einmal das Control Center öffnen zu müssen. Nutzt ihr ein TUXEDO-Notebook mit GNOME? Dann probiert die Erweiterung aus und schreibt mir, was euch noch fehlt oder wo es hakt – entweder hier in den Kommentaren oder als Issue auf GitHub.

Transparenzhinweis: Ich arbeite für TUXEDO Computers. Pulsgeber ist allerdings ein privates Projekt, das in meiner Freizeit entstanden ist. Es ist kein Produkt von TUXEDO und erhält keinen offiziellen Support von TUXEDO.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Die naheliegende Lösung: /etc/fstab plus ein Dispatcher-Skript für NetworkManager, das anhand von SSID oder Server-Erreichbarkeit automatisch mountet. Klingt nach einer Feierabend-Sache. Ist es aber nicht ganz – ich bin dabei über drei Stolperfallen gestolpert, die einem erst auffallen, wenn der Rechner runterfährt, aufwacht oder in den Standby soll. Genau die drei nehme ich hier mit euch durch.

Getestet habe ich das Ganze auf Arch Linux, aber das Setup ist nicht Arch-spezifisch: Solange eure Distribution systemd und NetworkManager mitbringt – also etwa auch Fedora, Ubuntu, Debian oder openSUSE –, funktioniert alles hier eins zu eins.

Der Grundaufbau

Netzwerkfreigaben bekommen in der fstab klassischerweise noauto, damit sie beim Boot nicht sofort, sondern erst bei Bedarf eingehängt werden:

//server/home /mnt/server/home cifs credentials=/etc/samba/server.credentials,rw,uid=1000,gid=100,noauto,_netdev 0 0
//server/data /mnt/server/data cifs credentials=/etc/samba/server.credentials,rw,uid=1000,gid=100,noauto,_netdev 0 0

Für den Mount-Typ selbst gibt’s je nach Protokoll gute Anleitungen im Arch Wiki, etwa zu Samba/CIFS und zu davfs2 für WebDAV – beide funktionieren unabhängig von der Distribution, solange cifs-utils beziehungsweise davfs2 installiert sind.

Das eigentliche Mounten übernimmt dann ein Skript unter /etc/NetworkManager/dispatcher.d/. NetworkManager ruft solche Skripte bei jeder Verbindungsänderung auf und übergibt Interface und Status (up, down, pre-down und ein paar weitere) mit – alle Details dazu stehen in der NetworkManager-dispatcher-Manpage. Ein simples Skript prüft die aktive WLAN-SSID und mountet, wenn’s passt:

#!/bin/bash
IFACE="$1"
STATUS="$2"

case "$STATUS" in
    up)
        SSID=$(nmcli -t -f active,ssid dev wifi | awk -F: '$1 == "yes" {print $2; exit}')
        if [[ "$SSID" == "MeinHeimnetz" ]]; then
            mount /mnt/server/home
            mount /mnt/server/data
        fi
        ;;
    down)
        umount /mnt/server/home
        umount /mnt/server/data
        ;;
esac

Fertig, oder? Nicht ganz. Sobald ihr das System runterfahrt, aus dem Standby weckt oder in den Standby schickt, zeigt sich, dass die Sache Tücken hat.

Warum nicht einfach GVfs?

Ihr fragt euch jetzt vielleicht, wieso ich mir das mit fstab und Dispatcher-Skripten überhaupt antue – GNOME bietet über „Mit Server verbinden“ im Dateimanager doch einen viel einfacheren Weg, Netzwerkfreigaben per SMB oder WebDAV einzubinden. Genau da liegt für mich das Problem.

Solche Mounts laufen nicht über den Kernel, sondern über GVfs, GNOMEs virtuelles Dateisystem. Programme, die die GIO-Bibliothek nutzen – fast alle GTK-Anwendungen, allen voran der Dateimanager selbst –, sprechen Freigaben direkt über eigene URIs wie smb:// oder dav:// an und zeigen entsprechend auch Vorschaubilder und Metadaten korrekt an. Für Programme, die das nicht können, blendet GVfs die Freigabe zusätzlich unter /run/user/<uid>/gvfs als ganz normalen Pfad ein. Diese Brücke läuft tatsächlich über FUSE – GVfs selbst ist zwar kein klassisches FUSE-Dateisystem, sondern eine eigene Architektur mit Daemon-Prozessen pro Protokoll, stellt aber genau für diesen Fall über gvfsd-fuse einen POSIX-kompatiblen Pfad bereit.

Genau diese Brücke ist bei mir der Knackpunkt: Nicht jedes Programm kommt damit zuverlässig klar. Konkret zeigt sich das bei mir in einem Markdown-Editor, in den ich auch Bilder für Artikel einbinde. Der Dateimanager zeigt die Bilder auf dem Netzlaufwerk ganz normal an, weil er GVfs nativ spricht. Der Markdown-Editor dagegen zeigt für dasselbe Bild nur einen Platzhalter – die Einbindung über den FUSE-Pfad funktioniert schlicht nicht zuverlässig, obwohl die Datei nachweislich da ist.

Ein klassischer Kernel-Mount über CIFS oder davfs2, wie im Rest dieses Artikels beschrieben, taucht dagegen als ganz normaler, stabiler POSIX-Pfad im Dateisystem auf – ohne Sonderbehandlung, für jedes Programm gleich. Der Mehraufwand mit fstab und Dispatcher-Skripten zahlt sich also gerade dann aus, wenn ihr Freigaben nicht nur im Dateimanager, sondern in ganz unterschiedlichen Anwendungen zuverlässig nutzen wollt.

Problem 1: Der Rechner fährt nicht mehr sauber runter

Fehlt in der fstab die Option _netdev, weiß systemd nicht, dass es sich hier um eine Netzwerkfreigabe handelt. Beim Shutdown kann es dann passieren, dass systemd versucht auszuhängen, nachdem das Netzwerk schon weg ist – der umount blockiert, bis der Job-Timeout greift, und euer System hängt beim Herunterfahren fest.

_netdev behebt das, weil systemd damit die richtige Reihenfolge kennt: erst aushängen, dann Netzwerk kappen. Wichtig ist außerdem, dass ein Dispatcher-Skript nicht nur auf down, sondern auf pre-down reagiert – der Status feuert, bevor die Verbindung wirklich fällt, während down schon danach kommt und für ein sauberes Aushängen zu spät ist. Damit das klappt, braucht es zusätzlich einen Symlink im Unterordner pre-down.d/.

Problem 2: Nach dem Aufwachen hängt sich der Dateimanager auf

Ein mount-Aufruf für CIFS oder WebDAV läuft im Kernel und kann bei nicht erreichbarem Server ziemlich lange blockieren – gerade kurz nach dem Aufwachen, wenn DNS oder Routing noch nicht ganz da sind. NetworkManager wartet standardmäßig synchron, bis so ein Dispatcher-Skript fertig ist, bevor es weitermacht. Hängt der mount-Aufruf, hängt bei euch plötzlich auch der Dateimanager oder die Netzwerkanzeige, weil die vom Verbindungsstatus abhängen.

Die Lösung: Mount-Versuche einfach im Hintergrund laufen lassen, damit das Dispatcher-Skript selbst sofort zurückkehrt, egal wie lange der eigentliche Mount braucht.

run_async() {
    ( "$@" ) &>/dev/null &
    disown
}

Problem 3: Der Standby funktioniert plötzlich nicht mehr

Und hier wird’s spannend. Mit der Lösung aus Problem 2 stolpert ihr in ein neues, deutlich fieseres Problem, das sich in meinem Fall so äußerte: Der Bildschirm geht aus, aber Tastaturbeleuchtung und LEDs bleiben an – ihr müsst hart abschalten. Was war passiert?

Der mount-Syscall für CIFS oder davfs blockiert bei nicht erreichbarem Server im sogenannten D-Zustand (uninterruptible sleep) – einem Zustand, den kein Signal unterbricht, auch SIGKILL nicht. Bevor der Kernel sich tatsächlich schlafen legt, versucht er, alle Prozesse einzufrieren. Ein Prozess im D-Zustand lässt sich aber nicht einfrieren, und der ganze Standby hängt fest, bis die Netzwerkoperation im Kernel von selbst aufgibt – das kann durchaus ein paar Minuten dauern.

Weil die Mount-Versuche aus Problem 2 jetzt länger im Hintergrund weiterlaufen, steigt eben auch die Chance, dass genau in dem Moment, in dem ihr in Standby gehen wollt, so ein blockierender Verbindungsversuch gerade aktiv ist.

Der zuverlässige Ausweg: Vor jedem mount erst mit einem echten Userspace-Verbindungstest prüfen, ob der Server überhaupt erreichbar ist – so einer lässt sich per Timeout wirklich abbrechen, zum Beispiel über Bashs eingebautes /dev/tcp:

tcp_reachable() {
    local HOST="$1"
    local PORT="$2"
    local TIMEOUT_SECONDS="${3:-2}"
    timeout "${TIMEOUT_SECONDS}s" bash -c "echo >/dev/tcp/${HOST}/${PORT}" &>/dev/null
}

Nur wenn der Test klappt, folgt der eigentliche mount. Damit landet ihr so gut wie nie mehr im riskanten, blockierenden Kernel-Connect, weil ihr zu dem Zeitpunkt schon wisst, dass der Server da ist.

Die Kombination, die bei mir funktioniert

Am Ende braucht ein robustes Setup vier Zutaten:

• _netdev in der fstab, damit systemd Netzwerkfreigaben beim Herunterfahren richtig einordnet.
• pre-down-Handling samt Symlink in pre-down.d/, damit das Aushängen garantiert vor dem Verbindungsabbau passiert – mit Timeout und Lazy-Unmount als Backup, falls der normale umount mal zickt.
• Asynchrone Mounts im up-Fall, damit NetworkManager und alles, was davon abhängt, nicht blockiert.
• Ein Erreichbarkeitstest vor jedem mount, damit der eigentliche, potenziell blockierende Kernel-Connect gar nicht erst passiert.

Dazu noch ein kleiner Healthcheck per systemd-Timer, der ein paar Minuten nach dem Boot und danach regelmäßig nachschaut, ob die Freigaben wirklich da sind, und notfalls nachhilft. Praktisch, falls der auslösende Netzwerk-Event mal zu früh oder zu spät kommt.

Alle Dateien im Überblick

Damit ihr das Ganze direkt nachbauen könnt, hier der komplette Satz an Dateien. Ich habe die Beispielnamen aus meinem eigenen Setup (ein Samba-Server namens bender, WebDAV via tuxedo) durch generische Platzhalter ersetzt – die müsst ihr natürlich an eure eigene Umgebung anpassen.

/etc/fstab – die beiden Freigaben, einmal Samba, einmal WebDAV:

//server/home /mnt/server/home cifs credentials=/etc/samba/server.credentials,rw,uid=1000,gid=100,noauto,_netdev,x-systemd.mount-timeout=15s,soft 0 0
//server/data /mnt/server/data cifs credentials=/etc/samba/server.credentials,rw,uid=1000,gid=100,noauto,_netdev,x-systemd.mount-timeout=15s,soft 0 0
https://cloud.example.com/remote.php/dav/files/user /mnt/webdav davfs noauto,_netdev,uid=1000,gid=100,x-systemd.automount,x-systemd.idle-timeout=300,x-systemd.mount-timeout=15s 0 0

Die fstab referenziert die Zugangsdaten nur, gespeichert werden sie in eigenen Dateien – schon damit das Passwort nicht im Klartext in einer Datei steht, die jeder lesen kann.

/etc/samba/server.credentials – Zugangsdaten für die Samba-Freigabe:

username=maxmuster
password=GeheimesPasswort123

/etc/davfs2/secrets – Zugangsdaten für die WebDAV-Freigabe, referenziert wird hier der Mountpunkt statt einer Option in der fstab:

/mnt/webdav maxmuster GeheimesPasswort123

Beide Dateien gehören root und dürfen für niemand sonst lesbar sein:

$ sudo chmod 600 /etc/samba/server.credentials /etc/davfs2/secrets
$ sudo chown root:root /etc/samba/server.credentials /etc/davfs2/secrets

/etc/NetworkManager/dispatcher.d/lib/mount-helpers.sh – die gemeinsame Bibliothek, die alle anderen Skripte einbinden:

#!/bin/bash
log() {
    [[ "$DEBUG" == "1" ]] && logger -t "$LOG_TAG" -- "$1"
}

run_async() {
    ( "$@" ) &>/dev/null &
    disown
}

tcp_reachable() {
    local HOST="$1"
    local PORT="$2"
    local TIMEOUT_SECONDS="${3:-2}"
    timeout "${TIMEOUT_SECONDS}s" bash -c "echo >/dev/tcp/${HOST}/${PORT}" &>/dev/null
}

mount_with_retry() {
    local MOUNT="$1"
    local MAX_ATTEMPTS="${2:-3}"
    local SLEEP_SECONDS="${3:-2}"
    local MOUNT_TIMEOUT="${4:-10}"

    if mountpoint -q "$MOUNT"; then
        log "$MOUNT ist bereits eingehängt"
        return 0
    fi

    log "Hänge $MOUNT ein"

    local OUT ATTEMPT
    for ((ATTEMPT = 1; ATTEMPT <= MAX_ATTEMPTS; ATTEMPT++)); do
        if OUT=$(timeout "${MOUNT_TIMEOUT}s" mount "$MOUNT" 2>&1); then
            log "$MOUNT erfolgreich eingehängt"
            return 0
        fi
        log "Versuch $ATTEMPT/$MAX_ATTEMPTS für $MOUNT fehlgeschlagen (evtl. Timeout nach ${MOUNT_TIMEOUT}s): $OUT"
        [[ "$ATTEMPT" -lt "$MAX_ATTEMPTS" ]] && sleep "$SLEEP_SECONDS"
    done

    log "Alle Versuche für $MOUNT fehlgeschlagen"
    return 1
}

umount_with_fallback() {
    local MOUNT="$1"
    local TIMEOUT_SECONDS="${2:-5}"

    if ! mountpoint -q "$MOUNT"; then
        log "$MOUNT ist nicht eingehängt"
        return 0
    fi

    log "Hänge $MOUNT aus"

    if timeout "${TIMEOUT_SECONDS}s" umount "$MOUNT"; then
        log "$MOUNT erfolgreich ausgehängt"
        return 0
    fi

    log "Normaler Unmount von $MOUNT fehlgeschlagen, versuche Lazy Unmount"
    if umount -l "$MOUNT"; then
        log "$MOUNT per Lazy Unmount ausgehängt"
        return 0
    fi

    log "$MOUNT konnte nicht ausgehängt werden"
    return 1
}

/etc/NetworkManager/dispatcher.d/90-server-mount – Samba-Freigabe, gebunden an eine bestimmte WLAN-SSID oder ans Kabelnetz:

#!/bin/bash

DEBUG=1
LOG_TAG="server-mount"

LIB="/etc/NetworkManager/dispatcher.d/lib/mount-helpers.sh"
if [[ -r "$LIB" ]]; then
    source "$LIB"
else
    logger -t "$LOG_TAG" -- "Bibliothek $LIB nicht gefunden, breche ab"
    exit 1
fi

IFACE="$1"
STATUS="$2"

MOUNTS=(
    "/mnt/server/home"
    "/mnt/server/data"
)

mount_server() {
    if ! tcp_reachable server 445 2; then
        log "server auf Port 445 nicht erreichbar, überspringe Mount-Versuch"
        return 1
    fi

    for MOUNT in "${MOUNTS[@]}"; do
        mount_with_retry "$MOUNT" 3 2 10
    done
}

umount_server() {
    for MOUNT in "${MOUNTS[@]}"; do
        umount_with_fallback "$MOUNT" 5
    done
}

log "Dispatcher gestartet: Interface=$IFACE, Status=$STATUS"

case "$STATUS" in
    up)
        if [[ "$IFACE" == wl* ]]; then
            SSID=$(nmcli -t -f active,ssid dev wifi |
                awk -F: '$1 == "yes" {print $2; exit}')

            log "Aktive WLAN-SSID: $SSID"

            if [[ "$SSID" == "MeinHeimnetz" ]]; then
                run_async mount_server
            fi

        elif [[ "$IFACE" == enp* || "$IFACE" == eth* ]]; then
            run_async mount_server
        fi
        ;;

    pre-down|vpn-pre-down)
        log "Netzwerkverbindung wird beendet – Mounts aushängen"
        umount_server
        ;;
esac

log "Dispatcher beendet"
exit 0

/etc/NetworkManager/dispatcher.d/90-webdav-mount – WebDAV-Freigabe, die einfach nur einen erreichbaren Cloud-Server voraussetzt:

#!/bin/bash

DEBUG=1
LOG_TAG="webdav-mount"

LIB="/etc/NetworkManager/dispatcher.d/lib/mount-helpers.sh"
if [[ -r "$LIB" ]]; then
    source "$LIB"
else
    logger -t "$LOG_TAG" -- "Bibliothek $LIB nicht gefunden, breche ab"
    exit 1
fi

IFACE="$1"
STATUS="$2"

MOUNTPOINT="/mnt/webdav"
HOST="cloud.example.com"

mount_webdav() {
    if ! tcp_reachable "$HOST" 443 3; then
        log "$HOST auf Port 443 nicht erreichbar, überspringe Mount-Versuch"
        return 1
    fi

    mount_with_retry "$MOUNTPOINT" 3 2 10
}

log "Dispatcher gestartet: Interface=$IFACE, Status=$STATUS"

case "$STATUS" in
    up)
        run_async mount_webdav
        ;;

    pre-down|vpn-pre-down)
        log "Netzwerkverbindung wird beendet – Mount aushängen"
        umount_with_fallback "$MOUNTPOINT" 5
        ;;
esac

log "Dispatcher beendet"
exit 0

Für beide Skripte braucht ihr zusätzlich noch die passenden Symlinks, damit pre-down garantiert vor dem Verbindungsabbau feuert:

$ sudo ln -s /etc/NetworkManager/dispatcher.d/90-server-mount 
             /etc/NetworkManager/dispatcher.d/pre-down.d/90-server-mount
$ sudo ln -s /etc/NetworkManager/dispatcher.d/90-webdav-mount 
             /etc/NetworkManager/dispatcher.d/pre-down.d/90-webdav-mount

/usr/local/bin/mount-healthcheck.sh – das Sicherheitsnetz, das regelmäßig nachschaut:

#!/bin/bash
DEBUG=1
LOG_TAG="mount-healthcheck"

LIB="/etc/NetworkManager/dispatcher.d/lib/mount-helpers.sh"
if [[ -r "$LIB" ]]; then
    source "$LIB"
else
    logger -t "$LOG_TAG" -- "Bibliothek $LIB nicht gefunden, breche ab"
    exit 1
fi

log "Healthcheck gestartet"

SSID=$(nmcli -t -f active,ssid dev wifi 2>/dev/null |
    awk -F: '$1 == "yes" {print $2; exit}')

if [[ "$SSID" == "MeinHeimnetz" ]] || ping -c 1 -W 1 server >/dev/null 2>&1; then
    mount_with_retry "/mnt/server/home" 2 3
    mount_with_retry "/mnt/server/data" 2 3
else
    log "server im aktuellen Netz nicht erreichbar, überspringe"
fi

mount_with_retry "/mnt/webdav" 2 3

log "Healthcheck beendet"
exit 0

/etc/systemd/system/mount-healthcheck.service und mount-healthcheck.timer – Systemd-Einheiten, die das Healthcheck-Skript 60 Sekunden nach dem Boot und danach alle 10 Minuten anstoßen:

[Unit]
Description=Prueft und stellt Netzwerk-Mounts sicher
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
TimeoutStartSec=120
ExecStart=/usr/local/bin/mount-healthcheck.sh

[Unit]
Description=Fuehrt den Mount-Healthcheck 60s nach Boot und danach alle 10 Minuten aus

[Timer]
OnBootSec=60s
OnUnitActiveSec=10min
AccuracySec=30s

[Install]
WantedBy=timers.target

Aktivieren nicht vergessen:

$ sudo systemctl daemon-reload
$ sudo systemctl enable --now mount-healthcheck.timer

/usr/lib/systemd/system-sleep/90-cancel-network-mounts – optionales Sicherheitsnetz vor dem Suspend:

#!/bin/bash
case "$1/$2" in
    pre/*)
        logger -t sleep-mount-guard "Breche evtl. laufende Netzwerk-Mount-Versuche vor Suspend ab"
        pkill -9 -f 'mount.cifs' 2>/dev/null
        pkill -9 -f 'mount.davfs' 2>/dev/null
        ;;
esac

exit 0

Alle Skripte müssen ausführbar sein:

$ sudo chmod +x /etc/NetworkManager/dispatcher.d/lib/mount-helpers.sh 
              /etc/NetworkManager/dispatcher.d/90-server-mount 
              /etc/NetworkManager/dispatcher.d/90-webdav-mount 
              /usr/local/bin/mount-healthcheck.sh 
              /usr/lib/systemd/system-sleep/90-cancel-network-mounts

Lange Rede, kurzer Sinn

Automatisches Einhängen von Netzwerkfreigaben über NetworkManager funktioniert gut, ist aber kein Fünf-Minuten-Job, wie es die Doku vermuten lässt. Wenn ihr nur den mount-Befehl in ein up-Skript packt, holt euch früher oder später eines der drei Probleme ein – meistens genau dann, wenn ihr unterwegs seid und kein Log zur Hand habt.

Mit _netdev, korrektem pre-down-Timing, asynchroner Ausführung und einem echten Erreichbarkeitstest vor jedem Mount seid ihr auf der sicheren Seite. Und das Muster lässt sich eins zu eins auf andere netzwerkabhängige Automatisierungen übertragen, etwa VPN-Verbindungen oder Backup-Jobs, die nur im richtigen Netz laufen sollen.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Mit Rutile entsteht deshalb ein spannendes Projekt. Die Entwickler schreiben Tilix nicht einfach weiter, sondern entwickeln den Terminal-Emulator vollständig in Rust neu. Gleichzeitig bleibt das Bedienkonzept erhalten. Statt einer Neuerfindung soll eine moderne Umsetzung entstehen, die sich nahtlos in aktuelle GNOME-Systeme mit GTK4 und libadwaita einfügt.

Bewährtes Konzept auf moderner Basis

Viele Terminal-Emulatoren unterscheiden sich hauptsächlich durch ihr Erscheinungsbild oder kleinere Zusatzfunktionen. Rutile verfolgt dagegen einen anderen Ansatz. Ziel ist es, die Arbeitsweise von Tilix möglichst vollständig zu übernehmen und auf eine moderne technische Grundlage zu stellen. Bestehende Nutzer sollen sich sofort zurechtfinden.

Die Anwendung verwendet GTK4, libadwaita und VTE4 und profitiert dadurch von aktuellen Bibliotheken des GNOME-Desktops. Gleichzeitig setzen die Entwickler auf Rust als Programmiersprache. Das verspricht langfristig eine besser wartbare Codebasis und eröffnet die Möglichkeit, neue Funktionen auf einer modernen Architektur aufzubauen.

Flexible Terminalaufteilung

Die wichtigste Funktion übernimmt Rutile direkt von Tilix. Das Terminalfenster lässt sich rekursiv horizontal und vertikal aufteilen. Jeder Bereich kann anschließend erneut geteilt werden. Dadurch entstehen flexibel verschachtelte Arbeitsbereiche, ohne dass die Anwendung auf ein festes Raster oder eine bestimmte Fensteranordnung beschränkt ist.

Im Alltag bietet diese Arbeitsweise viele Vorteile. Links lassen sich beispielsweise Logdateien beobachten, während rechts gleichzeitig mehrere Server oder Container geöffnet sind. Zwischen den einzelnen Bereichen wechselt ihr bequem per Tastatur. Das spart Mausbewegungen und sorgt für einen flüssigen Arbeitsablauf bei komplexeren Aufgaben.

Andere Terminals wie Ghostty bieten diese Funktion ebenfalls, allerdings muss man sich dafür Tastenkombinationen merken. Alternativ kann man natürlich auch Terminal-Multiplexer wie tmux verwenden. Dort gilt jedoch dasselbe. Auch wenn es nicht viele Tastenkombinationen sind: Ich persönlich möchte dafür einfach Buttons haben.

Mehrere unabhängige Sitzungen

Neben den frei aufteilbaren Terminalbereichen unterstützt Rutile mehrere voneinander getrennte Sitzungen. Jede Sitzung besitzt ihre eigene Fensteraufteilung und ihren eigenen Arbeitskontext. Dadurch lassen sich unterschiedliche Projekte oder Aufgaben sauber voneinander trennen, ohne dafür mehrere Programmfenster öffnen zu müssen.

Zwischen den Sitzungen wechselt ihr entweder per Tastenkombination oder über eine Seitenleiste. Diese zeigt kleine Vorschaubilder der jeweiligen Arbeitsumgebung und bleibt standardmäßig ausgeblendet. Wer sie benötigt, blendet sie einfach über die Werkzeugleiste ein und behält so auch bei vielen geöffneten Sitzungen leichter den Überblick.

Synchronisierte Eingaben

Besonders praktisch finde ich die Funktion zur synchronisierten Eingabe. Aktiviert ihr sie, überträgt Rutile sämtliche Tastatureingaben gleichzeitig an mehrere Terminalbereiche einer Sitzung. Das spart Zeit, wenn identische Befehle auf mehreren Servern oder virtuellen Maschinen ausgeführt werden sollen.

Einzelne Terminalbereiche lassen sich jederzeit von der gemeinsamen Eingabe ausnehmen. Dadurch können einzelne Systeme gezielt abweichende Befehle erhalten, ohne die Synchronisierung komplett zu deaktivieren. Trotzdem empfiehlt sich etwas Vorsicht, denn fehlerhafte Befehle werden ansonsten ebenso gleichzeitig auf allen verbundenen Systemen ausgeführt.

Vertraute Bedienung

Auch die Tastenkombinationen orientieren sich eng am Vorbild. Mit Strg+Umschalt+O und Strg+Umschalt+E teilt ihr das Fenster horizontal oder vertikal. Strg+Umschalt+W schließt den aktiven Bereich, während ihr mit den Pfeiltasten zwischen den einzelnen Terminalfenstern wechselt.

Neue Sitzungen öffnet ihr mit Strg+Umschalt+T. Zwischen vorhandenen Sitzungen wechselt ihr per Strg+Umschalt+Bild auf beziehungsweise Bild ab. Wer lieber mit der Maus arbeitet, erreicht dieselben Funktionen zusätzlich über die Werkzeugleiste oder das Kontextmenü der einzelnen Terminalbereiche.

Noch in einer frühen Entwicklungsphase

Rutile befindet sich derzeit noch am Anfang seiner Entwicklung. Die erste Version konzentriert sich bewusst auf die wichtigsten Funktionen. Features wie der Quake-Modus, das Speichern kompletter Sitzungen, Desktop-Benachrichtigungen oder die Nautilus-Integration sollen erst folgen, wenn die vorhandenen Funktionen zuverlässig arbeiten.

Diesen Ansatz halte ich für sinnvoll. Statt möglichst viele Funktionen früh bereitzustellen, konzentriert sich das Projekt zunächst auf einen stabilen Kern. Gerade bei Werkzeugen, die viele Anwender täglich nutzen, sind Zuverlässigkeit und ein konsistentes Bedienkonzept meist wichtiger als eine möglichst lange Funktionsliste.

Was aktuell wirklich fehlt, sind Übersetzungen – einige Dialoge erscheinen derzeit ausschließlich auf Französisch. Außerdem lassen sich die Terminalfarben noch nicht direkt in den Einstellungen anpassen. Das voreingestellte Farbschema macht Programme wie den Midnight Commander teilweise schwer lesbar. Allerdings ist die aktuelle Version von Rutile erst vor wenigen Tagen erschienen, sodass sich hier vermutlich bald etwas tun wird.

Installation

Unter Arch Linux steht Rutile sowohl als Quellpaket als auch als vorkompilierte Variante im AUR zur Verfügung. Für Debian, Ubuntu und Fedora bieten die Entwickler fertige DEB- beziehungsweise RPM-Pakete an. Zusätzlich lässt sich eine eigenständige Binärdatei herunterladen, sofern die benötigten GTK4-Komponenten bereits installiert sind. Alle Informationen zur Installation finden sich auf der GitHub-Seite des Projekts.

Wer Tilix seit Jahren nutzt und auf einen modernen GTK4-Unterbau wechseln möchte, sollte Rutile im Auge behalten. Noch fehlen einige Funktionen, doch der bisherige Entwicklungsstand macht einen sehr vielversprechenden Eindruck. Das Projekt verfolgt einen klaren Fokus und könnte sich zu einem würdigen Nachfolger für Tilix entwickeln.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Schuld daran ist ein Update des offiziellen Linux-Clients auf Electron-Basis, das die GTK-Style-Window-Decoration durcheinandergebracht hat. Die Funktionalität von Spotify bleibt zwar unverändert, optisch sieht es aber alles andere als schick aus.

Lösungsmöglichkeiten für Spotify

Es gibt zwei einfache Wege, um das Problem zu beheben. Die bequemste Variante ist, Spotify als Flatpak zu installieren. Die Flatpak-Version zeigt den blauen Rahmen nicht und ihr müsst euch um nichts kümmern. Änderungen an der Konfiguration sind nicht nötig.

Falls ihr Spotify hingegen über den Spotify Launcher (Paket spotify-launcher aus den Extra-Quellen von Arch) oder direkt aus dem AUR (Eintrag spotify) installiert habt, müsst ihr das Start-Flag --ozone-platform=x11 setzen. Damit wird die GTK-Dekoration korrekt angezeigt. Je nach Installationsart fügt ihr das Flag wie folgt ein:

Für AUR-Spotify in der Datei ~/.config/spotify-flags.conf:

--ozone-platform=x11

Für Spotify Launcher in ~/.config/spotify-launcher.conf:

[spotify]
extra_arguments = ["--ozone-platform=x11"] 

Eventuell müsst ihr diese Dateien erst anlegen. Nach einem Neustart von Spotify sollte der blaue Rahmen verschwunden sein und alles wieder normal aussehen.

Korrektur von Fabian auf Mastodon: Das stimmt so nicht. Das ist ganz alleine dem geschulded das Spotify Wayland-nativ läuft und dort, unter GNOME, eine clientseitige Dekoration (CSD) braucht, die es über diese blaue bereit stellt. Das ganze wieder zu X11 zwingen schafft eventuell echte Probleme, wie verschwommene Schriften, schlechtes (kein) scaling und so weiter. Spotify ist auch nicht Elektron, sondern Chromium Embedded Framework (CEF).

Klar, es ist eine Krücke, aber eine, die derzeit hilft. Die Änderung lässt sich ja auch schnell wieder rückgängig machen. Die anderen Optionen wären, Gnome unter X11 zu betreiben oder sich mit den blauen Rahmen anzufreunden. Beides in meinen Augen auch nicht gerade optimal. So ist es erstmal ein Workaround, den man natürlich nicht vergessen sollte, falls sich Spotify irgendwann einmal wieder komisch verhält.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Neben diesen grafischen Werkzeugen begleitet mich auch der Music Player Daemon, kurz MPD. Der Name klingt zunächst kryptisch, dahinter steckt aber ein einfaches Konzept. MPD ist ein Musikplayer, der im Hintergrund läuft und sich über zahlreiche Clients fernsteuern lässt. Man kann also einen Rechner oder Raspberry Pi an die Stereoanlage hängen, die eigene Musiksammlung einbinden und die Wiedergabe von überall im Haus steuern.

Music Player Daemon aka MPD

MPD unterscheidet sich deutlich von Streaming-Servern wie Jellyfin oder Navidrome, die auf dem Subsonic-Protokoll basieren. Dort streamt der Server die Musik an die Clients, während bei MPD der Client nur die Wiedergabe steuert und der Dienst selbst direkt auf dem Server spielt. Bemerkenswert ist, dass die Entwicklung an MPD auch nach über zwanzig Jahren nicht eingeschlafen ist. Die aktuelle stabile Version MPD 0.24.6 ist gerade erst veröffentlicht worden.

Auch bei den Clients merkt man, dass MPD weiterhin lebendig ist. Während moderne Subsonic-Clients für Linux (speziell für den GNOME-Desktop) inzwischen leider wirklich rar geworden sind (Sublime Music oder Sonixd wurden eingestellt, mit Feishin oder Supersonic werde ich nicht warm), entstehen rund um MPD immer wieder neue Projekte. In letzter Zeit erscheinen vermehrt Anwendungen auf Basis von GTK4 und Libadwaita, die sich optimal in das aktuelle GNOME-Design einfügen und die Funktionen des Desktops optimal nutzen.

MPD für GNOME: Plattenalbum

Plattenalbum (Flathub) hat gerade erst ein Update auf Version 2.4.0 erhalten und nutzt GTK4, ohne sich in ein übertrieben verspieltes Design zu verlieren. Die Albencover stehen klar im Mittelpunkt der Oberfläche. Das Layout bleibt klassisch, links die Künstler, in der Mitte die Alben und rechts der Player mit den Kontrollelementen zur Steuerung der Wiedergabe.

Wer während der Wiedergabe auch die Songtexte lesen möchte, wechselt über den Button oberhalb des Players in die Lyrics-Ansicht. Die Texte müssen dafür nicht im ID3-Tag stehen. Plattenalbum lädt sie automatisch vom brasilianischen Dienst Letras, was besonders praktisch ist, wenn man die eigenen Dateien nicht vollständig gepflegt hat. Weitere Einstellungsmöglichkeiten gibt es nicht viele, und braucht es eigentlich auch nicht.

MPD für GNOME: Euphonica

Euphonica (Flathub) setzt im Gegensatz zu Plattenalbum deutlich stärker auf visuelle Effekte. Der Hintergrund des Fensters passt sich an die Farben des aktuellen Albums an und am unteren Rand bewegt sich ein animiertes Spektrum. Beim Wechsel zwischen Künstler- und Albenansicht oder beim Öffnen eines Albums gleiten die einzelnen Elemente weich ins Bild und erzeugen einen modernen Eindruck.

Auch funktional überzeugt Euphonica. Man kann durch Künstler und Alben navigieren und künftig soll auch das Filtern nach Genres möglich sein. Alben lassen sich mit MPD 0.24 oder neuer bewerten. Über MPRIS integriert sich Euphonica nahtlos in den Desktop, zeigt Benachrichtigungen beim Titelwechsel an und erlaubt die Steuerung der Wiedergabe auch über die Desktop-Funktionen.

Generell wäre es wünschenswert, wenn wieder ein neuer GTK4/LibAdwaita-Client für Subsonic erscheinen würde. Auf meinem kleinen Selfhosting-Server läuft Navidrome sehr zuverlässig. Für Android gibt es Symfonium (proprietär, aber jeden Cent wert) sowie Tempus, eine aktiv weiterentwickelte Version des FOSS-Clients Tempo. Auch das Webfrontend von Navidrome funktioniert ausgezeichnet. Auf dem Desktop fehlt jedoch eine native Anwendung, hier klafft aktuell eine große Lücke.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.