Hängen geblieben ist vor allem, wie schnell so eine Sammlung wächst, wenn ein paar Leute regelmäßig etwas beitragen – und wie schnell sie verstaubt, wenn nicht. Im deutschsprachigen Raum sind wir bis heute verwöhnt: Das ubuntuusers-Wiki ist in meinen Augen eine der besten Linux-Dokumentationen überhaupt.

Das offizielle Ubuntu-Wiki hatte es daneben immer etwas schwerer – eine angestaubte Optik, zwei parallele Adressen und für jeden, der mitschreiben wollte, erst einmal ein Antrag auf Launchpad. Wer hierzulande eine Lösung suchte, ist entsprechend selten dort gelandet. Jetzt bekommt es einen kompletten Neustart.

Aus zwei Wikis wird eins

Genau genommen waren es ja sogar zwei offizielle Wikis: Neben wiki.ubuntu.com gab es noch das CommunityHelpWiki unter help.ubuntu.com/community. Welches davon für welchen Inhalt zuständig war, wusste am Ende vermutlich nicht mal mehr Canonical selbst. Wer eine Seite anlegen wollte, durfte erst einmal raten.

Damit ist jetzt Schluss: Beide Altlasten werden von einem einzigen neuen Wiki abgelöst, das seit dieser Woche in Produktion ist. Unter der Haube werkelt nun MediaWiki statt MoinMoin – dieselbe Software also, die auch das Arch-Wiki und die Wikipedia antreibt.

Der Wechsel war überfällig: Die alten Wikis liefen auf einer MoinMoin-Version, die noch Python 2 voraussetzt und entsprechend seit Jahren keine Sicherheitspatches mehr bekommt. Debian ist gerade mit einer ähnlichen Migration beschäftigt, Ubuntu ist mit dem Umzug also nicht allein.

Zum Mitschreiben reicht ein Ubuntu-One-Account

Für Autoren ändert sich am meisten. Bisher musste man sich auf Launchpad um die Mitgliedschaft in einer Wiki-Editoren-Gruppe bewerben und dann auf einen Menschen warten, der einen wildfremden Antragsteller nach Gutdünken für vertrauenswürdig hält oder eben nicht. Künftig reicht ein Ubuntu-One-Account, um bestehende Seiten zu bearbeiten.

Wer neue Seiten anlegen oder geschützte Seiten anfassen will, braucht zehn Edits und einen mindestens vier Tage alten ersten Beitrag – das klassische Autoconfirmed-Modell aus der Wikipedia-Welt. Neue Mitstreiter sollen sich erst etwas Vertrauen erarbeiten, bevor sie an die heiklen Stellen dürfen.

Geschrieben wird wahlweise im visuellen Editor mit Slash-Befehlen oder im Quelltexteditor, der Syntaxhervorhebung, Linting, Live-Vorschau und Multi-Cursor mitbringt. Dazu kommen Dark Mode, eine mobiltaugliche Oberfläche, Bild-Uploads samt Galerien, automatische Spamfilter und – für die Bastler unter euch – ein sandboxed Lua-Interpreter für dynamische Templates.

50 Seiten sind noch kein Wiki

Der Haken an der Sache: Inhalte hat das neue Wiki so gut wie keine. Statt zehntausende Seiten aus zwei Jahrzehnten zu migrieren, startet Ubuntu mit rund 50 Seiten und der Ansage, dass die Community den Rest selbst nachziehen soll.

Nachvollziehbar ist das schon, denn ein guter Teil des alten Bestands war veraltet, doppelt oder schlicht Spam – und übertragen werden soll nur, was sich heute noch lohnt. Trotzdem heißt das erst einmal: Alte Lesezeichen und die Treffer eurer letzten zehn Google-Suchen laufen ins Leere.

Immerhin landet ihr dann nicht auf einer nackten 404, sondern bekommt Suchtreffer im neuen Wiki, Suchtreffer im Archiv und das Angebot, die Seite gleich selbst anzulegen. Aus der Sackgasse wird so mit etwas gutem Willen direkt ein eigener Artikel.

Der alte Bestand liegt im Archiv

Wer im Altbestand stöbern will, findet ihn als Textarchiv auf GitHub – bereits nach MediaWiki-Syntax konvertiert, was das Migrieren einzelner Seiten deutlich erleichtert –, als Tarball mit Bildern, Anhängen und Versionsgeschichte und als Web-Viewer zum lokalen oder Online-Betrieb.

Eine Warnung gibt das Team gleich mit: Der Abzug ist einige Monate alt, ganz frische Edits aus dem alten Wiki fehlen. Die Weiterleitungen von help.ubuntu.com/community sollen in den nächsten Tagen folgen, Fehler meldet ihr vorerst per Discourse an das Communications Council.

Technisch ist das ein sauberer Schnitt, und die Editoren-Hürde endlich abzuräumen war längst fällig. Ob daraus wieder eine ernstzunehmende Wissenssammlung wird, entscheidet sich aber nicht an der Software, sondern daran, ob sich genug Leute finden, die die guten alten Seiten herüberholen und nebenbei aktualisieren.

Das Arch-Wiki ist schließlich auch nicht wegen MediaWiki gut, und ubuntuusers war es auch nie. Wie seht ihr das – lohnt sich der Aufwand für das offizielle Wiki überhaupt? Finden sich heute noch ausreichend Autoren, die das Wiki mit Leben füllen? Oder ist die Ära der Distro-Wikis ohnehin vorbei?

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

Seit Samstag steht der Trailer zu „KDE: The Documentary“ auf YouTube, gut 43.000 Aufrufe hat er in den ersten Tagen gesammelt. Der komplette Film folgt am 14. Oktober. Erzählt wird die Geschichte des Projekts von Matthias Ettrichs Aufruf im Usenet über den Qt-Lizenzstreit, der die freie Desktop-Welt gespalten hat, bis hin zu KDE 4 – jenem Release, an dem die Community fast zerbrochen wäre – und dem Comeback danach.

Video wird erst nach Klick von YouTube geladen.

Die Besetzungsliste liest sich wie ein Klassentreffen der freien Desktops: Gründer Matthias Ettrich, dazu Martin Konold, Matthias Kalle Dalheimer, Eva Brucherseifer und Cornelius Schumacher aus den frühen Jahren. Von Trolltech- und Qt-Seite kommen Eirik Chambe-Eng und Lars Knoll, für die Plasma-Ära stehen Aaron Seigo, Sebastian Kügler, Eike Hein, Albert Astals Cid und Nate Graham. Und mittendrin: Miguel de Icaza, der Gnome 1997 als Antwort auf genau dieses Lizenzproblem mitgegründet hat. Dass der in einer KDE-Doku zu Wort kommt, ist für sich genommen schon eine kleine Sensation.

Warum ausgerechnet der 14. Oktober?

Das Datum ist kein Zufall, sondern der Geburtstag. Am 14. Oktober 1996 schrieb Matthias Ettrich sein legendäres Posting in die Newsgroup de.comp.os.linux.misc und rief dazu auf, gemeinsam eine grafische Oberfläche für Unix zu bauen – gedacht für Endanwender, nicht für Admins. Der Name Kool Desktop Environment war ein Seitenhieb auf das damals proprietäre CDE. Nebenbei ein hübsches Detail für uns: Der Startschuss für den wohl bekanntesten Linux-Desktop fiel in einer deutschsprachigen Newsgroup, Betreff „New Project: Kool Desktop Environment. Programmers wanted!“.

KDE wird also an diesem Tag 30 Jahre alt, und das Projekt nutzt die Gelegenheit für eine Spendenkampagne. Das Ziel sind 1.500 unterstützende Mitglieder, als Stretch Goal stehen bis zur Akademy 1.996 in den Büchern – die Jahreszahl als Zielmarke, das muss man erst mal hinbekommen. Rund 70 Prozent der Mittel kommen laut KDE von privaten Nutzern, nicht von Konzernen. Wer etwas beisteuern möchte, findet die Details auf der Jubiläumsseite.

CultRepo: die Leute hinter der Kamera

Produziert hat den Film CultRepo, und der Name dürfte vielen erst einmal nichts sagen. Hinter dem Team steckt der YouTube-Kanal, der früher unter Honeypot lief – dem Berliner Jobportal für Entwickler, dessen aufwendig gedrehte Open-Source-Dokus dem Kanal den Ruf als „Netflix für Entwickler“ eingebracht haben. Seit 2025 ist die Truppe eigenständig unterwegs, finanziert über Sponsoren und direkte Unterstützung der Zuschauer. Geführt wird sie von Emma Tracey, die Filme machen Josiah McGarvie und Ida Bechtle.

Die Liste der bisherigen Filme ist ordentlich: Elixir (2018), Ember.js und GraphQL (2019), Vue.js (2020), Kubernetes und Prometheus (2022), Ruby on Rails und React.js (2023), Node.js (2024), Angular, Vite und Python (2025). Zuletzt kam im Juni 2026 C++: The Documentary mit Bjarne Stroustrup heraus. Bisher ging es also praktisch immer um Sprachen und Frameworks – KDE ist der erste Desktop im Programm. Und im Gegensatz zu einem Framework hat dieses Projekt tatsächlich Drama zu bieten: Lizenzkrieg, Abspaltung, ein Release, das Nutzer reihenweise vertrieben hat, und trotzdem 30 Jahre auf dem Buckel.

Auch als Gnome-User freue ich mich jedes Mal, wenn aus Richtung KDE wieder ein Update mit dickem Funktionspaket kommt. Ein zweiter großer, quicklebendiger Desktop tut der Linux-Welt gut – und dass dieses Projekt seit 30 Jahren durchhält, ist alles andere als selbstverständlich. Ein Großteil der Geschichte dahinter steht bislang verstreut in Mailinglisten-Archiven und alten Planet-KDE-Beiträgen, und die Leute, die dabei waren, werden auch nicht jünger. Am 14. Oktober wissen wir mehr. Und ihr? Womit habt ihr damals angefangen – KDE, Gnome oder doch einem der alten Window-Manager?

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

Tfm bringt unter anderem eine Seitenleiste, Tabs, eine Zwei-Fenster-Ansicht und Dateivorschauen mit. Auch die üblichen Dateioperationen wie Kopieren, Verschieben, Umbenennen und Löschen sind mit an Bord. Interessant dabei: Ihr müsst nicht ausschließlich über die Tastatur arbeiten. Tfm unterstützt auch die Maus, und damit beispielsweise das Markieren, Verschieben und Umbenennen von Dateien per Drag & Drop.

Damit verbindet tfm typische Funktionen grafischer Dateimanager mit der Umgebung des Terminals. Wer ohnehin häufig dort arbeitet, kann Dateien und Verzeichnisse verwalten, ohne extra ein grafisches Programm zu öffnen.

Installation über das AUR

Tfm findet ihr im AUR (Arch User Repository). Wer einen AUR-Helper wie yay verwendet, installiert die Binärversion direkt. Unter Arch Linux genügt dafür folgender Befehl:

$ yay -S tfm-tui-bin

Anschließend startet ihr den Dateimanager mit:

$ tfm

Nutzt ihr eine andere Distribution, findet ihr auf der Projektseite eine Installationsbeschreibung für das dort bereitgestellte Installationsskript. Darüber installiert ihr die aktuelle Version unabhängig von den Paketen eurer Distribution.

Nerd Fonts für die Symbole

Damit tfm Ordner und Dateien mit den vorgesehenen Symbolen darstellt, braucht ihr einen Nerd Font. Diese Schriften bringen zusätzliche Zeichen und Icons mit, die Terminal-Anwendungen für die Darstellung von Ordnern, Dateien und anderen Elementen nutzen.

Für diesen Artikel verwende ich den Hack Nerd Font. Unter Arch Linux liegt die Schrift direkt in den offiziellen Paketquellen und lässt sich mit pacman installieren:

$ sudo pacman -S ttf-hack-nerd

Damit tfm die Symbole korrekt darstellen kann, muss die Hack Nerd Font lediglich auf eurem System installiert sein – eine Auswahl der Schrift im Terminal ist dafür nicht nötig. Eine manuelle Aktualisierung des Font-Caches braucht es bei einem Paket aus den Arch-Repositories normalerweise auch nicht.

Beta mit kleinen Macken

Tfm befindet sich derzeit noch im Beta-Stadium, und das merkt ihr am ehesten bei der Darstellung der Symbole. In meinen Tests wurden die Nerd-Font-Symbole nicht bei jedem Start zuverlässig angezeigt – Ordner und andere Elemente erscheinen dann teilweise ganz ohne die vorgesehenen Icons.

Ein Neustart von tfm oder des Terminals behebt das Problem meist. Auffällig dabei: Die Darstellung funktioniert auch ohne Änderungen am Font-Cache beim nächsten Start wieder – die Probleme lassen sich also nicht allein auf eine fehlerhafte Installation der Schrift zurückführen.

Für die grafische Vorschau von Bildern braucht tfm ein Terminal, das das Kitty Graphics Protocol unterstützt. Unter Linux eignet sich dafür beispielsweise Ghostty, dessen Linux-Oberfläche auf GTK4 basiert. Gnome Terminal kann diese Funktion dagegen nicht bieten, weil die zugrunde liegende VTE-Bibliothek das Kitty Graphics Protocol nicht unterstützt.

Auch bei der übrigen Oberfläche solltet ihr noch nicht mit der Stabilität und Konsistenz rechnen, die ihr von etablierten Dateimanagern gewohnt seid. Wer tfm ausprobiert, sollte deshalb erst einmal mit unkritischen Dateien arbeiten und wichtige Daten nicht allein einer noch jungen Software anvertrauen.

Die wichtigsten Tastenkürzel

Trotz der Mausunterstützung spielt die Tastatur bei tfm eine wichtige Rolle. Die wichtigsten Befehle findet ihr in der folgenden Übersicht:

Unterm Strich ist tfm für mich ein sympathischer Fund für alle, die ohnehin ständig im Terminal unterwegs sind. Seitenleiste, Tabs, Zwei-Fenster-Ansicht, Vorschau und Mausbedienung sorgen für einen Komfort, den man von der Kommandozeile sonst nicht gewohnt ist. Wer mag, kann bei Bedarf sogar Animationen einschalten – wie das aussieht, zeigt ein Video auf Reddit.

Die Macken der Beta-Phase, allen voran bei der Symboldarstellung und der noch nicht ganz ausgereiften Oberfläche, sollte man dabei aber im Hinterkopf behalten. Ich bleibe an der Entwicklung dran und würde tfm aktuell vor allem zum Ausprobieren empfehlen – am besten mit unkritischen Dateien, bis die Software etwas gereift ist.

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

Und ja: Der Name ist ein bisschen sperrig. Ich weiß! Tuxsucht klingt zunächst so, als würde hier jemand nach Tux süchtig sein. Oder nach Linux. Gemeint ist aber etwas anderes: Tux sucht. Für euch. Nach Linux. Die Idee hinter tuxsucht.de ist eigentlich daher ziemlich simpel, lasst mich ein bisschen ausholen.

Eine Suchmaschine, die nicht alles durchsucht

Wenn ich nach einem Linux-spezifischen Problem suche, möchte ich nicht zwangsläufig das gesamte Web durchsuchen. Genau hier setzt Tuxsucht an: Statt möglichst viele Treffer zusammenzutragen, konzentriert sich die Suche auf ausgewählte deutschsprachige Quellen rund um Linux und freie Software.

Eine normale Websuche liefert zwar eine gewaltige Menge an Treffern. Darunter finden sich aber oft SEO-optimierte Ratgeberseiten, automatisch erzeugte Inhalte, kommerzielle Ergebnisse und jede Menge Seiten, die mit Linux nur am Rande zu tun haben. Gute Informationen können dabei schnell untergehen. Das galt 2009, aber erst recht auch heute durch den zunehmenden KI-Slop im Netz.

Tuxsucht geht deshalb einen etwas anderen Weg: Die Suche beschränkt sich auf eine ausgewählte Sammlung deutschsprachiger Linux-Foren, Blogs und auf Linux spezialisierter Shops/Hersteller. Der Suchraum ist dadurch bewusst kleiner, dafür aber thematisch deutlich relevanter. Gleichzeitig möchte ich damit die deutschsprachige Linux-Community stärken und Informationen auch für Menschen zugänglich machen, die kein oder nur wenig Englisch sprechen.

Das kann zum Beispiel praktisch sein, wenn ich wissen möchte, ob eine bestimmte Hardware unter Linux funktioniert. Oder ob jemand bereits Erfahrungen mit einer Grafikkarte, einem WLAN-Chip oder einer bestimmten Software gesammelt hat. Gerade solche Erfahrungsberichte finden sich häufig in Foren und Blogs.

Statt mich durch Seiten zu arbeiten, die mit Linux wenig zu tun haben, suche ich dort, wo Linux tatsächlich Thema ist. Tuxsucht soll damit keine Konkurrenz zu allgemeinen Suchmaschinen sein, sondern eine kleine, thematisch fokussierte Alternative für die deutschsprachige Linux-Welt.

Die passende Technik ist eine Abwägung

Bei einem Projekt wie Tuxsucht liegt der Gedanke nahe, die Suchmaschine komplett selbst zu betreiben. Mit SearXNG gibt es beispielsweise freie Software für eine selbst gehostete Metasuchmaschine. Sie bündelt Ergebnisse verschiedener Suchdienste und lässt sich auf eigener Infrastruktur betreiben.

Für Tuxsucht wäre das durchaus reizvoll: freie Software, mehr Kontrolle über die Infrastruktur und weniger Abhängigkeit von einem einzelnen Anbieter. Allerdings müsste ich dafür nicht nur die Software betreiben, sondern auch einen dauerhaft erreichbaren öffentlichen Dienst bereitstellen und entsprechend warten.

Ein eigener Suchindex wäre noch einmal eine ganz andere Größenordnung. Speicherplatz, Rechenleistung, Bandbreite, Crawling und laufende Wartung würden aus dem kleinen Nebenprojekt schnell ein eigenes Infrastrukturprojekt machen. Genau dafür fehlen mir allerdings Zeit und Ressourcen – Tuxsucht soll überschaubar bleiben.

Auch bei kommerziellen Suchanbietern gibt es Alternativen. Die Brave Search API liefert beispielsweise eigene Suchergebnisse und unterstützt individuelle Filtermöglichkeiten. Der Dienst kostet derzeit 5 US-Dollar pro 1000 Suchanfragen, wobei monatlich 5 US-Dollar Guthaben enthalten sind.

Das ist für ein größeres Projekt durchaus interessant, für Tuxsucht aber ebenfalls nicht besonders attraktiv. Bei einer öffentlichen Suchmaschine entstehen die Kosten schließlich mit jeder einzelnen Suche. Je häufiger Tuxsucht genutzt wird, desto stärker würde damit auch die laufende Rechnung wachsen.

Google bietet mit der Programmable Search Engine genau die Funktion, die Tuxsucht benötigt: Die Suche lässt sich auf eine definierte Auswahl von Domains beschränken. Die Standardvariante ist kostenlos, allerdings mit Werbung; die kostenpflichtige API kostet 5 US-Dollar pro 1000 Anfragen.

Deshalb nutze ich für Tuxsucht derzeit schlicht die kostenlose Variante von Google. Das ist für ein Open-Source-affines Projekt sicher nicht die konsequenteste Lösung. Es ist aber eine pragmatische Lösung, die ohne eigene Suchinfrastruktur und ohne nutzungsabhängige Kosten funktioniert.

Warum das heute noch sinnvoll ist

Eine auf Linux beschränkte Suche mag zunächst etwas aus der Zeit gefallen wirken. Schließlich können Google, Bing und andere allgemeine Suchmaschinen praktisch das gesamte Web durchsuchen. Gerade diese enorme Reichweite ist bei einer sehr speziellen technischen Frage aber nicht immer ein Vorteil.

Mehr Ergebnisse bedeuten schließlich nicht automatisch bessere Ergebnisse. Wer beispielsweise nach einem Linux-Treiber, einer Hardware-Erfahrung oder einer Lösung für ein distributionsspezifisches Problem sucht, braucht häufig keine hunderttausend Treffer. Hilfreicher sind einige wenige Ergebnisse aus Quellen, die das Thema tatsächlich behandeln.

Gerade bei technischen Fragen sind Forenbeiträge, Erfahrungsberichte und Diskussionen oft wertvoller als eine hübsch aufbereitete Seite mit allgemeinen Informationen. Bei Linux kommt hinzu, dass Lösungen distributions-, versions- oder hardwareabhängig sein können und sich entsprechend schnell verändern.

Tuxsucht versucht deshalb gar nicht erst, das gesamte Internet abzubilden. Tuxsucht sucht dort, wo Linux gesucht, diskutiert und ausprobiert wird. Das Ergebnis muss dadurch nicht immer besser sein – aber es soll für bestimmte Linux-Fragen schneller zu relevanten Informationen führen.

Was ich jetzt damit vorhabe

Mit dem Neustart möchte ich Tuxsucht.de wieder zu dem machen, was es eigentlich immer sein sollte: eine kleine, nützliche Anlaufstelle für die deutschsprachige Linux-Welt. Das Projekt soll dabei bewusst überschaubar bleiben und nicht versuchen, aus jeder Suchanfrage ein eigenes Portal zu machen.

Die Domainliste werde ich deshalb weiter pflegen und bei Bedarf erweitern. Wenn euch ein wichtiges Linux-Forum, ein guter Blog oder eine passende andere Seite fehlt, könnt ihr sie über das Kontaktformular vorschlagen. Gerade bei solchen Projekten lebt die Auswahl schließlich auch von den Hinweisen aus der Community.

Und vielleicht wird aus dem lange vernachlässigten Projekt ja tatsächlich wieder ein Werkzeug, das man gelegentlich gerne zur Hand nimmt. Nach dem technischen und optischen Neustart ist zumindest die Grundlage dafür wieder da. Jetzt muss Tuxsucht nur noch zeigen, ob Tux tatsächlich noch gut suchen kann. Tuxsucht.de ist jedenfalls wieder da. Tux sucht für euch. Nach Linux.

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

Hintergrund: YouTube und die Enshitification

YouTube-Ripper wie yt-dlp sowie unabhängige YouTube-Clients wie NewPipe und Klons wie PipePipe, die unter der Haube mit yt-dlp arbeiten, sollen künftig stärker blockiert werden. Grund dafür ist, dass freie Clients keine Werbung anzeigen und häufig Funktionen wie SponsorBlock direkt integrieren.

Technisch funktioniert das Blocken von yt-dlp über eine JavaScript-Challenge, die künftig einen Browser oder Client mit vollwertiger JavaScript-Engine erfordert. Der bisher in yt-dlp integrierte rudimentäre JavaScript-Interpreter genügt dafür nicht mehr. Die aktuelle Version yt-dlp 2025.11.12 kann nun jedoch Deno und andere JS-Runtimes einbinden. Für Anwender entsteht daraus kein großer Aufwand:

### Ohne Deno gibt yt-dlp eine Warnung aus...
$ yt-dlp https://www.youtube.com/watch?v=dQw4w9WgXcQ
[...]
WARNING: [youtube] No supported JavaScript runtime could be found. YouTube extraction without a JS runtime has been deprecated, and some formats may be missing. See  https://github.com/yt-dlp/yt-dlp/wiki/EJS  for details on installing one. To silence this warning, you can use  --extractor-args "youtube:player_client=default"
[...]
WARNING: [youtube] dQw4w9WgXcQ: Some web_safari client https formats have been skipped as they are missing a url. YouTube is forcing SABR streaming for this client. See  https://github.com/yt-dlp/yt-dlp/issues/12482  for more details
[youtube] dQw4w9WgXcQ: Downloading m3u8 information
WARNING: [youtube] dQw4w9WgXcQ: Some web client https formats have been skipped as they are missing a url. YouTube is forcing SABR streaming for this client. See  https://github.com/yt-dlp/yt-dlp/issues/12482  for more details
[info] dQw4w9WgXcQ: Downloading 1 format(s): 401+251
[...]

### Installation von Deno über die Paketverwaltung...
$ sudo pacman -S deno

### Deno löst die JS-Challenge erfolgreich...
$ yt-dlp https://www.youtube.com/watch?v=dQw4w9WgXcQ
[youtube] Extracting URL: https://www.youtube.com/watch?v=dQw4w9WgXcQ
[...]
[youtube] [jsc:deno] Solving JS challenges using deno
[...]
[download] Destination: Rick Astley - Never Gonna Give You Up (Official Video) (4K Remaster) [dQw4w9WgXcQ].f251.webm
[download] 100% of    3.27MiB in 00:00:00 at 9.59MiB/s
[Merger] Merging formats into "Rick Astley - Never Gonna Give You Up (Official Video) (4K Remaster) [dQw4w9WgXcQ].webm"
Deleting original file Rick Astley - Never Gonna Give You Up (Official Video) (4K Remaster) [dQw4w9WgXcQ].f251.webm (pass -k to keep)
Deleting original file Rick Astley - Never Gonna Give You Up (Official Video) (4K Remaster) [dQw4w9WgXcQ].f401.mp4 (pass -k to keep)

Derzeitige Situation und Ausblick

In Zukunft werden Paketbetreuer Deno mit hoher Wahrscheinlichkeit automatisch als Abhängigkeit von yt-dlp mitinstallieren. Unter Arch Linux ist das jedoch noch nicht der Fall – hier muss das Paket weiterhin manuell nachgerüstet werden, was sich über Pacman schnell erledigen lässt: Es genügt ein pacman -S deno. Man verliert dadurch lediglich rund 100 MByte Speicherplatz. Bei Ubuntu aber scheint Deno noch nicht in den Paketquellen zu sein.

Derzeit funktionieren viele Downloads zwar noch ohne Deno oder eine andere vollwertige JavaScript-Engine, doch Google wird die Schrauben mit Sicherheit weiter anziehen. Je strenger die technischen Hürden ausfallen, desto unzuverlässiger werden die bisherigen Workarounds arbeiten, bis sie schließlich komplett ausfallen. Mittelfristig ist daher davon auszugehen, dass Downloads von YouTube-Videos mit yt-dlp ohne Deno nicht mehr möglich sein werden.

PS: Wer sich wundert, wie man in einem Terminalfenster Videos abspielen und Bilder ansehen kann, sollte sich mal mplayer mit der libcaca sowie den Bildbetrachter jp2a ansehen. Beide Tools finden sich in den Paketquellen von Arch und sicher auch bei anderen Distributionen. Sie zählen sicherlich zu den kleinen Freuden des Linux-Alltags – aber was wäre die Linux-Welt ohne ein bisschen nerdiges Zeug?

$ mplayer -really-quiet -vo caca video.webm
$ jp2a --colors bild.png

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

Aber ehrlich gesagt: Für den gelegentlichen Radiogenuss braucht man nicht immer den ganzen Schnickschnack. Hier kommt Yet Another Radio ins Spiel – eine kompakte und praktische Erweiterung für die GNOME Shell. Sie spielt eure Lieblingssender ab, ohne dass man eine extra Anwendung öffnen muss. Der Komfort bleibt dabei erhalten: Man muss sich die Sender und deren URLs nicht selbst aus dem Netz zusammensuchen, eine Datenbank ist direkt integriert.

Was ist Yet Another Radio?

Der Entwickler beschreibt seine Motivation auf Reddit so:

Hello everyone! Long story short, I recently switched from KDE to GNOME and saw that there is no extension like the popular Advanced Radio Player for GNOME which is simple and easy to use. So I started developing my very first extension.

Kurz gesagt: Wer ein einfaches, übersichtliches Tool sucht, um Radiosender direkt aus dem GNOME-Panel zu steuern, findet hier genau das Richtige. Hier geht’s zur Extension auf GNOME Extensions

Funktionen im Überblick

Mit Yet Another Radio könnt ihr eure Lieblingssender direkt aus dem Panel abspielen, ganz ohne zusätzliches Fenster öffnen zu müssen. Über die Radio Browser API lassen sich tausende Sender durchsuchen, sodass ihr schnell das findet, was euch gerade interessiert. Eure Favoriten könnt ihr markieren, um sie jederzeit mit nur einem Klick abzuspielen.

Wer möchte, kann außerdem eigene Sender manuell hinzufügen oder bestehende Listen importieren und exportieren. Das ist praktisch, wenn ihr zum Beispiel mehrere Geräte nutzt. Die Erweiterung zeigt zudem Trackinformationen inklusive Albumcover an, wobei ich bisher allerdings noch keinen Sender gefunden habe, bei dem diese Funktion wirklich angezeigt wird.

Yet Another Radio ist also ideal für alle, die Internetradio unkompliziert in GNOME nutzen möchten, ohne auf eine umfangreiche Anwendung wie Shortwave angewiesen zu sein. Einfach installieren, Sender suchen, Favoriten setzen – fertig. Wer mehr will, kann die Senderlisten importieren oder eigene Stationen hinzufügen. Eine kleine, feine Erweiterung, die zeigt, wie praktisch GNOME-Erweiterungen sein können.

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