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.

Abgedichtet sind die Lücken in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Für PHP 8.1 und älter gibt es bislang keine regulären Releases mit dem Fix, da hilft nur der Umstieg auf einen unterstützten Zweig. Auf einem normalen Server erledigt das der Paketmanager. Bei Docker sieht die Sache anders aus: Jeder Container bringt sein eigenes PHP mit, und das bleibt so alt, wie das Image eben ist.

Welcher Container hat welches PHP?

Die erste Frage lautet also: In welchen Containern auf dem Heimserverchen steckt überhaupt ein PHP? Bei Nextcloud oder WordPress ist das klar, bei selbst gebauten Images oder kleinen Web-Apps weniger. Statt jeden Container einzeln abzuklappern, fragt die folgende Schleife alle laufenden Container nach ihrer PHP-Version und gleicht sie gleich mit den gepatchten Versionen ab.

for c in $(docker ps --format '{{.Names}}'); do
  v=$(docker exec "$c" php -r 'echo PHP_VERSION;' 2>/dev/null) || continue
  case "${v%.*}" in
    8.5) fix=8.5.12 ;;
    8.4) fix=8.4.27 ;;
    8.3) fix=8.3.36 ;;
    8.2) fix=8.2.35 ;;
    *)   fix=99 ;;
  esac
  if [ "$(printf '%s\n' "$fix" "$v" | sort -V | head -n1)" = "$fix" ]; then
    printf '\e[32m%-30s %-8s ok\e[0m\n' "$c" "$v"
  else
    printf '\e[31m%-30s %-8s anfällig?\e[0m\n' "$c" "$v"
  fi
done

Container ohne PHP überspringt die Schleife stillschweigend. Bei allen anderen landet die Version grün in der Ausgabe, wenn sie mindestens auf dem Stand des Patches ist, und rot, wenn sie darunter liegt. Rot gibt es auch für PHP 8.1, 7.x und älter, denn dafür existiert schlicht kein Fix. Bei mir sieht das Ergebnis so aus:

$ ./php2shell-simple.sh
nextcloud-app-1                8.5.12   ok
nextcloud-cron-1               8.5.12   ok
linuxundich-test-wordpress-1   8.3.36   ok
planetfoss-web                 8.3.33   anfällig?
sisu-web                       8.4.26   anfällig?

Nextcloud und das Test-WordPress hatten ihre Updates also schon gezogen, PlanetFOSS und die Seite für Sisu hingen dagegen noch hinterher. Das Fragezeichen hinter „anfällig“ ist übrigens Absicht. Die Schleife vergleicht nur die Versionsnummer. Nutzt ein Image das PHP-Paket von Debian, Ubuntu oder Alpine, kann der Fix zurückportiert sein, ohne dass sich die Nummer ändert. Dann hilft nur ein Blick in die Sicherheitsmeldungen der Distribution.

Genauer hinschauen lässt sich mit php2shell-check von EXT IT. Das MIT-lizenzierte Skript arbeitet nur lesend und bewertet PHP anhand der Paketversionen statt nur der Versionsnummer, berücksichtigt also auch zurückportierte Fixes. Es schaut in Docker-Container, FPM-Pools und noch laufende alte Prozesse und schickt auf Wunsch eine harmlose Anfrage an eure Website. Für die Container braucht es Root-Rechte oder die Mitgliedschaft in der Gruppe docker.

Die Projektseite schlägt den üblichen Einzeiler mit curl und sudo bash vor. Bei einem Skript, das mit Root-Rechten auf dem Server läuft, mag ich das nicht so gern. Ladet lieber das Skript samt SHA256SUMS aus den Releases herunter, prüft es mit sha256sum -c SHA256SUMS, lest einmal drüber und startet es dann von Hand. Ein „nicht anfällig“ ist laut den Entwicklern übrigens keine Garantie:

$ sudo bash php2shell-check.sh https://eure-seite.example

Auf meinem Heimserver lief das Skript mit sudo. Als Mitglied der Gruppe docker sähe es die Container zwar auch ohne Root-Rechte, laufende Prozesse anderer Benutzer und manche Logs blieben dann aber verborgen. Geholt und gestartet habe ich es so:

$ curl -fsSLO https://github.com/EXT-IT/php2shell-check/releases/latest/download/php2shell-check.sh
$ chmod +x php2shell-check.sh 
$ sudo ./php2shell-check.sh 

Das Urteil deckt sich mit der Schleife: planetfoss-web mit PHP 8.3.33 und sisu-web mit PHP 8.4.26 sind anfällig, Nextcloud und das Test-WordPress nicht. Zusätzlich hat es einen gestoppten Container von Tuxsucht gefunden, den meine Schleife glatt übersehen hat:

PHP in docker containers
  [ OK ] container      nextcloud-app-1 (nextcloud:35-apache)
         PHP 8.5.12 (fixed from 8.5.12)
[...]
  [VULN] container      planetfoss-web (planetfoss-web:local)
         PHP 8.3.33, fixed in 8.3.36
         -> Update PHP to 8.3.36 or later (container: pull the new image and recreate)
[...]
  [VULN] container      sisu-web (sisu-web:local)
         PHP 8.4.26, fixed in 8.4.27
[...]
  [WARN] container      php83 (stopped, tuxsucht-php)
         stopped, but its image ships PHP 8.3.33: it comes back vulnerable on the next start
[...]
Summary  2 vulnerable, 3 undecided, 12 warnings, 11 ok

Klar, docker ps listet eben nur laufende Container, und ein gestoppter Container nimmt keine Anfragen an. Startet ihn aber irgendwann jemand wieder, ist die Lücke sofort zurück. Deutlich wird das Skript außerdem beim Thema mod_php: Alle fünf laufenden Container liefern PHP über das Apache-Modul aus, und genau gegen dieses Setup demonstriert das Advisory einen kompletten Angriff ohne Anmeldung.

Bis zum Update schlägt das Skript als Notbehelf vor, session.upload_progress.enabled=0 und expose_php=0 zu setzen und post_max_size unter einem Viertel von memory_limit zu halten. Die Prüfung von außen hat dagegen wenig gebracht. Für die beiden Websites meldet das Skript nur, dass die Header keine PHP-Version verraten und keine WAF davorsteht. Über den Patchstand sagt das nichts, was das Skript auch ehrlich zugibt.

Und wie bekommt man das PHP aktualisiert?

Im Container selbst solltet ihr nichts aktualisieren, das wäre beim nächsten Neustart wieder weg. Stattdessen zieht ihr im jeweiligen Compose-Verzeichnis das neue Image und baut den Container damit neu auf. Bei selbst gebauten Images mit eigenem Dockerfile braucht es ein docker compose build --pull, damit Docker auch das Basis-Image frisch holt:

$ docker compose pull && docker compose up -d

Wichtig: Das hilft natürlich nur, wenn das Basis-Image die gepatchte Version auch schon enthält. Laut IT-Connect tauchten die neuen Tags anfangs sogar ohne Image dahinter auf, inzwischen liefern allgemeine Tags wie php:8.3-apache das gepatchte PHP. Wer dagegen eine feste Version wie php:8.4.24-fpm im Dockerfile stehen hat, muss sie selbst anheben. Lasst die Schleife nach dem Update einfach noch einmal laufen. Kümmert euch zuerst um die Container, die aus dem Internet erreichbar sind.

Wie das in der Praxis aussieht, zeigt die Testumgebung von PlanetFOSS. Das Image baut auf php:8.3-apache auf und packt im Dockerfile nur noch Erweiterungen wie GD und Intl dazu. Mein Deploy-Skript ruft zwar docker compose up -d --build auf, holt dabei aber kein neues Basis-Image, sondern nimmt das vom August aus dem Cache. Daher stammte das alte PHP 8.3.33. Erst --pull lädt die frische Fassung:

$ cd /data/docker/planetfoss
$ docker compose build --pull web
$ docker compose up -d web

Nach gut einer Minute stand das neue Image, und der Container lief mit PHP 8.3.36. Die Datenbank im selben Compose-Projekt bleibt davon unberührt, weil beide Befehle nur den Dienst web ansprechen. Die Schleife zeigt PlanetFOSS danach grün, und auch php2shell-check meldet nur noch sisu-web als anfällig. Das alte Image liegt übrigens noch als Leiche auf der Platte, docker image prune räumt es weg.

$ ./php2shell-simple.sh
[...]
nextcloud-cron-1               8.5.12   ok
linuxundich-test-wordpress-1   8.3.36   ok
sisu-web                       8.4.26   anfällig?

Alles in allem ist PHP2Shell ein gutes Beispiel dafür, dass Selfhosting mit Docker zwar bequem ist, die Updates aber nicht von allein kommen. Weitere Details zu den Lücken hat heise zusammengetragen. Wie man Container ohne viel Gefrickel auf Stand hält, habe ich mir übrigens in Docker-Container einfach aktuell halten mit Dockcheck angeschaut. Wie haltet ihr eure Container aktuell?

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

Genau dafür gibt es jetzt PlanetFOSS. Die Seite läuft schon ein paar Tage im Probebetrieb, ab heute möchte ich sie offiziell starten. Die Idee ist ein Planet, der nicht an einem Projekt hängt, sondern themenübergreifend sammelt: Distributionen, Desktops, Kernel, Selfhosting, Gaming, Sicherheit, Politik. Dazu kommen Verlage, Blogs, Projektseiten und Videokanäle, auf Deutsch und Englisch, und jeder Besucher filtert selbst, welche Sprache er sehen will.

Magazin statt Liste

Optisch orientiert sich PlanetFOSS an einem modernen Computer-Magazin und nicht an der klassischen Planet-Liste. Es gibt einen Aufmacher, Karten mit Bild und Anriss, Rubriken und eine Leiste mit den Themen des Tages. Übernommen wird dabei nur, was die Seiten selbst für Vorschauen ausliefern, also Open-Graph-Angaben oder den Inhalt des RSS-Feeds. Jede Karte verlinkt direkt auf den Originalartikel, Volltexte gibt es nicht.

Auch beim Datenschutz habe ich mir Mühe gegeben. Die Vorschaubilder liegen als WebP auf dem eigenen Server, sodass keine Besucher-IP bei fremden Servern landet. Es gibt keine Cookies, keine externen Skripte und kein Tracking. Artikel lassen sich trotzdem mit einem Stern als lesenswert markieren, ohne Konto: Statt eines Captchas löst der Browser eine kleine Rechenaufgabe, gemerkt wird der Stern nur lokal im Browser.

Technisch steckt dahinter ganz klassisches PHP mit MySQL, ohne Framework, auf einem gewöhnlichen Webspace. Alle fünf Minuten stößt ein Cronjob den Takt an: Feeds abrufen, neue Artikel anreichern, einordnen, Startseiten neu erzeugen. Die eigentliche Arbeit steckt aber nicht im Abrufen, sondern im Sortieren. Denn eine Seite mit über hundert Quellen wird schnell zur Bleiwüste, wenn zehn Seiten über dasselbe berichten.

Aus gleichen Meldungen werden Bündel

Erscheint eine neue Firefox-Version, schreiben gefühlt alle darüber. Auf einer normalen Planet-Seite stünde dann zehnmal Firefox untereinander. PlanetFOSS vergleicht deshalb jeden neuen Artikel mit allen Artikeln anderer Quellen aus den letzten 48 Stunden. Steckt im Titel dasselbe Thema mit derselben Versionsnummer, etwa „Firefox 158“ oder „Ubuntu 26.10“, landen die Artikel in einem gemeinsamen Bündel, auch über die Sprachgrenze hinweg.

Daneben gibt es zwei weitere Signale. Verlinken zwei Meldungen auf dieselbe Primärquelle, etwa die Release Notes oder eine Pressemitteilung, gehören sie sehr wahrscheinlich zusammen. Allerweltsziele wie GitHub oder Wikipedia zählen dabei nicht. Als letzter Weg vergleicht der Sammler die Titel selbst: Stoppwörter fliegen raus, und wenn sich die restlichen Wörter zur Hälfte decken und dazu ein gemeinsames Thema auftaucht, ist es ein Bündel.

Das Motto dabei lautet: lieber zu wenig als falsch bündeln. Ein fehlendes „auch bei“ fällt kaum auf, eine falsch zusammengeworfene Meldung dagegen sofort. Auf der Startseite erscheinen Bündel mit zwei Quellen als Karte mit einer Quellen-Leiste darunter. Ab drei Quellen wird daraus eine Story-Karte, die im Raster doppelt so breit ist und jeden weiteren Bericht mit eigener Schlagzeile und eigenem Link zum Original aufführt.

Neue Themen ohne Wörterbuch

PlanetFOSS hat ein Wörterbuch mit Begriffen wie GNOME, Plasma, Proxmox oder Steam. Das hilft bei den Rubriken, die zusätzlich ein kleiner Naive-Bayes-Klassifikator vergibt, und bei Versionsthemen. Nur tauchen in der Open-Source-Welt ständig neue Namen auf, die in keinem Wörterbuch stehen. Bei den ersten Tests fiel mir etwa ArtCraft auf: sieben Artikel zu einem neuen Projekt, und die Seite hatte davon nichts mitbekommen.

Seitdem sucht PlanetFOSS selbst nach neuen Namen. Ein Kandidat muss in den letzten 48 Stunden bei mindestens drei Quellen im Titel stehen (bei nur einer Sprache bei vier), in den vier Wochen davor aber höchstens einmal. Dazu kommt ein kleiner Trick: Ein Name wird nie kleingeschrieben. Wörter wie „released“ oder „Sicherheitslücke“ fallen damit heraus, ganz ohne endlose Stoppwortlisten. Der Rest wird zum neuen Thema.

Kometen und Supernovas

Jetzt wird es spannend. Der Name gibt das Bild vor: Kommt zu einem Thema auf einen Schlag sehr viel herein, etwa am Release-Tag einer neuen Ubuntu-Version, wird es zur Supernova, einem plötzlichen, sehr hellen Ausbruch. Nimmt ein Thema gerade erst Fahrt auf, ist es ein Komet. Und wenn der Ausbruch vorbei ist, bleibt noch eine Weile das Nachglühen.

Ein Komet entsteht, sobald mindestens drei verschiedene Quellen binnen zwölf Stunden über ein Thema schreiben. Er bekommt ein Abzeichen an seinen Karten und rückt in der Themen-Leiste nach vorne. Damit allgemeine Sammelthemen wie der Linux-Kernel nicht zum Dauerkometen werden, müssen sie zusätzlich doppelt so viele Quellen wie normal vorweisen. Hält ein Komet die Substanz nicht, fällt er wieder auf ein normales Thema zurück.

Eine Supernova braucht mehr. Vier Quellen müssen binnen 24 Stunden berichten, fast alle davon in den letzten zwölf Stunden. Das Thema muss breit gestreut sein, also mindestens zwei Arten von Quellen erreichen (Verlag, Blog, Projekt, Video) oder in beiden Sprachen auftauchen. Außerdem muss es mindestens dreimal so viele Quellen erreichen wie im Schnitt der letzten vier Wochen. Sonst wäre jede Ubuntu-Woche eine Supernova.

Einiges kennt PlanetFOSS dabei schon im Voraus. In einem Release-Kalender stehen die bekannten Termine von Ubuntu, GNOME, KDE Plasma, Fedora, Debian, dem Kernel und Firefox. Liegt ein Thema in diesem Fenster, reicht eine Quelle weniger zum Zünden. Gleichzeitig dürfen höchstens zwei Supernovas brennen, damit die Startseite nicht im Dauerfeuerwerk versinkt. Gibt es mehr Kandidaten, zünden die stärksten, der Rest bleibt vorerst ein Komet.

Eine Supernova brennt mindestens zwölf Stunden. Danach kühlt sie ab, wenn sechs Stunden lang nichts mehr kommt oder die Zahl der Quellen unter die Hälfte der Spitze fällt. Kommt eine zweite Welle, etwa die ersten Tests ein paar Tage nach dem Release, kann sie erneut zünden. Nach 72 Stunden landet das Thema im Archiv, die Themenseite bleibt aber erreichbar und sammelt auch spätere Beiträge.

So entsteht die Startseite

Brennt eine Supernova, steht sie als eigenes Band ganz oben über dem Aufmacher, mit der Zahl der Beiträge und Quellen und einer Reihe Karten, sortiert nach offiziellen Ankündigungen, Meldungen, Tests, Anleitungen und Videos. Was in diesem Band steht, taucht weiter unten nicht noch einmal auf. Zusätzlich verschickt PlanetFOSS eine halbe Stunde nach dem Zünden einen Beitrag an das Konto @planetfoss auf Mastodon.

Für alles andere vergibt die Seite Punkte. In die Wertung gehen die Größe des Bündels, die Sterne der Besucher, ein aktives Supernova-Thema und das Gewicht der Quelle ein. Geteilt wird das Ganze durch das Alter des Artikels, sodass ältere Beiträge nach und nach nach unten rutschen. Über wen viele berichten, der hält sich also länger oben, aber eben nicht ewig.

Beim Aufmacher zählt Wichtigkeit vor Frische, nur stammen die Kandidaten aus den letzten 24 Stunden und bringen bevorzugt ein großes Bild mit. Als Alter eines Bündels gilt der zweitjüngste Bericht: Schreiben weitere Quellen, bleibt es vorne, ein einzelner Nachzügler reicht dafür nicht. Steht ein Beitrag schon über acht Stunden im Aufmacher, verliert er die Hälfte seiner Punkte, nach 14 Stunden drei Viertel.

Damit eine fleißige Quelle nicht die ganze Seite füllt, achtet die Auswahl außerdem auf Vielfalt. Im Aufmacher und bei den Top-Meldungen daneben stammt jeder Beitrag von einer anderen Quelle, im Bereich „Neueste“ kommen höchstens zwei Artikel von derselben Seite. Dadurch bekommen auch kleinere Blogs ihren Platz neben den großen Verlagen, und die Startseite wirkt bei jedem Besuch ein Stück anders.

Statistik statt KI

Eine KI, die Texte zusammenfasst oder Themen errät, steckt in PlanetFOSS übrigens nicht. Alles läuft über Zählen, Vergleichen und ein paar Schwellenwerte. In meinen Augen ist das sogar der bessere Weg: Es kostet nichts, schickt keine Daten nach außen und bleibt nachvollziehbar. Wenn eine Supernova zündet, lässt sich genau sagen, warum. Entwickelt habe ich die Seite allerdings selbst KI-unterstützt.

Ganz ohne Nachjustieren ging es natürlich nicht. Anfangs zündete etwa eine Supernova zu Microsoft Defender, obwohl sich die vier Meldungen über 18 Stunden verteilten. Seitdem muss ein Ausbruch wirklich frisch sein. Auch Ubuntu 26.10 zündete am Release-Tag zunächst zwei Stunden zu spät, weil es gegen alle Ubuntu-Meldungen gerechnet wurde. Versionsthemen bekommen deshalb inzwischen ihren eigenen Normalwert.

Solche Fälle schaue ich mir regelmäßig an, dafür legt die Seite alle sechs Stunden einen Schnappschuss von Themen, Bündeln und Aufmachern ab. Von daher wird sich die Logik sicherlich noch weiter verändern. Ein falsches Bündel oder ein Komet, der keiner sein sollte, lässt sich im Admin-Bereich von Hand korrigieren. Die Korrekturen respektiert der Algorithmus beim nächsten Durchlauf brav.

Schaut doch einfach mal auf planetfoss.net vorbei und sagt mir, was ihr davon haltet. Welche Quellen fehlen euch noch, und welche Blogs, Magazine oder andere Veröffentlichungen aus der deutschen oder englischen Linux- und Open-Source-Welt sollten unbedingt mit auf den Planeten? Vorschläge nehme ich gerne in den Kommentaren entgegen. Wer selbst ein Blog betreibt und lieber nicht dabei sein möchte, findet auf der Seite natürlich auch einen Weg zum Abmelden.

Update: Warum die Sternchen auf PlanetFOSS kein Milchglas mehr tragen und was das mit einem Speicherleck in WebKitGTK zu tun hat, lest ihr in WebKitGTK 2.54: Kleines Sternchen, großes Speicherleck.

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

Warum Sonos S1 noch SMB1 braucht

Bei mir hängen noch zwei Play:3, ein Play:1 und ein Connect:Amp im Netz. Alle laufen mit der S1-Software, für die Sonos nur noch Fehlerkorrekturen liefert. Die Lautsprecher spielen nicht nur Streams, sondern auch meine Musiksammlung vom Server. Laut einer Diskussion im Sonos-Forum reichen die Ressourcen der S1-Geräte dafür aber nur für SMBv1, mehr ist auf der alten Hardware nicht drin.

Samba hat das alte Protokoll dagegen schon lange in Rente geschickt. Seit Version 4.11 steht server min protocol ab Werk auf SMB2_02, die NTLMv1-Anmeldung ist laut Samba-Projekt sogar schon seit Version 4.5 abgeschaltet. Die üblichen Anleitungen schalten beides mit zwei Zeilen global wieder ein. Die Lautsprecher spielen dann zwar, aber eben nicht nur sie bekommen die Tür geöffnet.

Wer ein System mit S2 betreibt, ist fein raus. Sonos hat dort mit Version 13.4.1 im Dezember 2021 SMBv2 und SMBv3 nachgereicht und spricht inzwischen gar kein SMBv1 mehr. S2-User lassen die Samba-Standards also in Ruhe. Der Rest dieses Artikels richtet sich an alle, die wie ich noch an ihren alten Lautsprechern hängen und sie nicht wegen eines Protokolls entsorgen wollen.

Was an der schnellen Lösung das Problem ist

SMB1 lässt sich in Samba nur für den ganzen Server erlauben, nicht für einzelne Freigaben oder Geräte. Spätestens seit WannaCry 2017 eine Lücke in Microsofts SMB1 ausnutzte, gilt das Protokoll als Altlast, und NTLMv1 macht es Angreifern leicht, mitgeschnittene Anmeldungen zu knacken. Meldet sich der Lautsprecher dann auch noch mit eurem normalen Benutzer an, wandert ausgerechnet euer Hauptpasswort im schwächsten Verfahren durchs Netz.

Dazu kommen Zeilen, die man beim Abschreiben gern gleich mitnimmt. Mit wide links und allow insecure wide links folgt Samba Symlinks auch dann, wenn sie aus der Freigabe herauszeigen. Gern hängt auch das ganze Datenverzeichnis schreibbar im Netz. Klar, von außen ist so ein Heimserverchen meist dicht. Doch im selben LAN hängen auch Fernseher, Steckdosen und Lautsprecher, deren Software ihr nicht in der Hand habt.

Ein eigener Benutzer nur für Sonos

Der wichtigste Schritt ist ein eigener Benutzer, der nur für die Lautsprecher da ist und sonst nichts darf. Er braucht weder ein Home-Verzeichnis noch eine Shell, Samba kennt ihn nur zum Anmelden. Das Passwort vergebt ihr einmalig und verwendet es nirgendwo sonst, denn per NTLMv1 sollte man es als halb öffentlich betrachten. Neu anlegen lässt er sich mit zwei Befehlen:

$ sudo useradd -r -M -s /usr/bin/nologin sonos
$ sudo smbpasswd -a sonos

Habt ihr schon einen Benutzer, mit dem sich die Lautsprecher anmelden, stutzt ihr ihn mit usermod zurecht. Er verliert die Shell, bekommt / als Home-Verzeichnis und ein gesperrtes Unix-Passwort. Die Anmeldung an Samba läuft über das eigene Passwort aus smbpasswd und funktioniert davon unberührt weiter. Nutzen die Lautsprecher bisher euren normalen Benutzer, legt ihr dagegen lieber einen neuen an:

$ sudo usermod -s /usr/bin/nologin -d / sonos
$ sudo passwd -l sonos

Die smb.conf

Die Konfiguration erlaubt SMB1 und NTLMv1, grenzt aber alles drumherum ein. Samba lauscht nur auf der LAN-Schnittstelle und nicht auf Docker-Bridges oder VPN-Tunneln. Gäste fliegen raus, Drucker gibt es keine, und jede Freigabe bekommt eine Liste der Benutzer, die rein dürfen. Den Namen der Netzwerkschnittstelle (bei mir enp0s25) und die Pfade müsst ihr natürlich an euer System anpassen:

[global]
   workgroup = WORKGROUP
   server string = bender
   server role = standalone server

   # Sonos S1: nur SMB1 + NTLMv1
   server min protocol = NT1
   server max protocol = SMB3
   ntlm auth = ntlmv1-permitted

   # nur LAN und lokal, nicht auf den Docker-Bridges
   interfaces = lo enp0s25
   bind interfaces only = yes

   map to guest = never

   # keine Drucker
   load printers = no
   printing = bsd
   printcap name = /dev/null
   disable spoolss = yes

[homes]
   browseable = no
   writable = yes
   valid users = %S
   invalid users = sonos

[musik]
   path = /data/musik
   browseable = yes
   read only = yes
   valid users = sonos anna ben lena

[data]
   path = /data
   writable = yes
   valid users = anna ben

ntlmv1-permitted ist übrigens nur der sprechende Name für das alte yes. Die Freigabe [musik] ist schreibgeschützt; lesen dürfen sonos und die Familie, hier anna, ben und lena. Selbst wenn jemand die Anmeldung des Lautsprechers knackt, kommt er so nur an die Musik. Auf [data] kommen nur anna und ben, wide links taucht nirgendwo auf, und Symlinks bleiben damit in ihrer Freigabe.

Wichtig ist noch die Zeile invalid users = sonos unter [homes]. Diese Freigabe bietet jedem Benutzer sein Home-Verzeichnis an, und das ist beim Lautsprecher-Benutzer nach dem usermod von oben das Wurzelverzeichnis. Ohne die Zeile gäbe es also eine beschreibbare Freigabe \\bender\sonos auf das ganze System. Was dort tatsächlich geht, regeln zwar die Dateirechte, Verzeichnisse wie /tmp stehen aber für alle offen.

Lässt sich die Sonos-Bibliothek gerade nicht neu einrichten, gibt es auch einen Zwischenschritt ohne eigene Musikfreigabe. Dann nehmt ihr sonos in die valid users der bestehenden Freigabe auf und setzt zusätzlich read list = sonos. Der Lautsprecher darf dann weiter alles lesen, was die Dateirechte hergeben, aber nichts schreiben. Auf Dauer ist die eigene Freigabe aber klar die bessere Wahl.

Bevor ihr die neue Datei aktiviert, lasst ihr sie von testparm prüfen. Das Programm meckert über Tippfehler und unbekannte Optionen, bevor Samba über sie stolpert. Danach startet ihr den Dienst neu, unter Arch heißt er smb, unter Debian und Ubuntu smbd. Offene Verbindungen brechen dabei kurz ab, eingehängte Freigaben auf euren Rechnern verbinden sich aber normalerweise von selbst wieder:

$ sudo testparm -s
$ sudo systemctl restart smb

Die Musikbibliothek in der Sonos-App

Zum Schluss tragt ihr die Freigabe in der S1-App als Musikbibliothek ein. Öffnet dazu die Einstellungen und geht dort auf Musikbibliothek und Musikbibliothek einrichten. Als Pfad tragt ihr die Freigabe im Windows-Format ein, also \\bender\musik, darunter den Benutzer sonos und sein Passwort. Danach liest Sonos die Sammlung ein, was bei großen Bibliotheken etwas dauern kann.

Kontrolle

Ob alles so läuft wie gedacht, zeigt euch smbstatus. In der Spalte Protocol Version seht ihr, wer mit welchem Protokoll angemeldet ist. Normale Rechner sollten sich weiter mit SMB3 verbinden, mein Notebook etwa mit SMB3_11, nur die Lautsprecher tauchen mit NT1 auf. Ein Gastzugriff ohne Passwort sollte dagegen mit NT_STATUS_ACCESS_DENIED abprallen, wenn ihr ihn mit smbclient von einem anderen Rechner aus probiert:

$ sudo smbstatus -b
$ smbclient -N //bender/data -c ls

Vom Ergebnis des zweiten Befehls solltet ihr euch nicht in die Irre führen lassen. Die Zeile „Anonymous login successful“ klingt zwar nach offener Tür, sie betrifft aber nur die Verbindung zum Server selbst, über die ein Client etwa die Liste der Freigaben abfragt. Entscheidend ist die zweite Zeile, denn in die Freigabe selbst kommt ohne Benutzer und Passwort niemand hinein:

$ smbclient -N //bender/data -c ls
Anonymous login successful
tree connect failed: NT_STATUS_ACCESS_DENIED

Bei mir sieht das so aus: Der Lautsprecher im Schlafzimmer liest als sonos per NT1, das Notebook hängt mit SMB3_11 und signierter Verbindung dran. Genau so soll es sein, denn das alte Protokoll bleibt damit auf die Geräte beschränkt, die nichts anderes können. Die übrigen Lautsprecher tauchen erst auf, wenn sie gerade auf die Bibliothek zugreifen:

$ sudo smbstatus -b

Samba version 4.25.0
PID     Username     Group        Machine                                   Protocol Version  Encryption           Signing              
----------------------------------------------------------------------------------------------------------------------------------------
732192  sonos        sonos        192.168.0.60 (ipv4:192.168.0.60:38427)    NT1               -                    -                    
711090  anna         anna         192.168.0.191 (ipv4:192.168.0.191:52826)  SMB3_11           -                    partial(AES-128-CMAC)

Und auf Dauer?

Ganz glücklich bin ich mit SMB1 natürlich trotzdem nicht. Auf meinem Server läuft ohnehin schon bonob, das Navidrome als Musikdienst in die Sonos-App bringt. Kommt die Musik darüber, braucht kein Lautsprecher mehr eine Samba-Freigabe, und SMB1 könnte endgültig weg. Wer jedoch ohne die interne Sonos-Bibliothek nicht auskommt, für den ist die eingegrenzte Variante in meinen Augen ein guter Kompromiss.

Alles in allem kostet die saubere Variante nur einen Benutzer und ein paar Zeilen mehr in der smb.conf. Die Lautsprecher spielen genauso wie mit der schnellen Lösung, nur führt über sie kein Weg zum Rest des Servers. Wie habt ihr eure alten Sonos-Lautsprecher angebunden? Hängt bei euch auch noch SMB1 im Netz, oder seid ihr längst auf S2 umgestiegen?

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

Wobei: Ruft ihr die Ankündigung auf, dann bekommt ihr womöglich nur eine Fehlermeldung zu sehen. Gedosst? Ge-DOS-st! Ausgerechnet der Blog zum Produkt, das Angriffe erkennen und abwehren soll, liegt ziemlich flach und lädt nur sehr langsam. Ob da jemand nachgeholfen hat oder nur zu viele Linux-User ungläubig nachschauen wollten, weiß ich nicht. Ein Defender für den eigenen Webserver wäre jedenfalls ein guter Anfang.

Dabei hatte ich mich so festgelegt. Als 2015 Sophos einen kostenlosen Virenscanner für Linux brachte, habe ich noch frech geschrieben, dass ihr auch ohne Virenscanner Online-Banking betreiben dürft. Wenige Monate später habe ich im Artikel zu AVGs Datenschutzerklärung das Wort Snakeoil benutzt. Elf Jahre später muss ich mich wohl bei der Branche entschuldigen. Microsoft hat ja schließlich gesprochen.

Microsoft entdeckt den Linux-Desktop

Der eigentliche Knaller steht im ersten Satz der Ankündigung: „As more developers begin to use Linux desktops“. Microsoft selbst bestätigt also, dass immer mehr Leute Linux auf dem Desktop einsetzen. Wir Linux-User haben über das Jahr des Linux-Desktops jahrzehntelang Witze gerissen. Jetzt ruft es ausgerechnet der Konzern aus Redmond aus. Ich hätte nicht gedacht, dass ich diese Bestätigung in einer Pressemitteilung für Sicherheitssoftware lesen würde.

Wer schon länger mitliest, der kennt die Vorgeschichte. 2009 musste Microsoft der US-Börsenaufsicht beichten, dass Linux offiziell ein Konkurrent ist. 2014 erklärte Microsoft dann, dass Linux als Server-System „falls short“. Heute verkauft der Konzern Schutzsoftware für Linux-Server und Linux-Desktops. Gandhi hatte also recht, nur die letzte Stufe hat er vergessen: Erst lachen sie über dich, dann bekämpfen sie dich, dann verkaufen sie dir einen Virenscanner.

Was der Defender auf dem Linux-Desktop kann

Technisch ist das Ganze übrigens keine neue Software. Microsoft setzt auf denselben Agenten, den es seit einigen Jahren für Linux-Server anbietet. Der Defender erkennt dabei selbstständig, ob er auf einem Server oder einer Workstation läuft. Das ist durchaus ein Fortschritt: 2014 hat mir die Microsoft-Homepage mein Linux noch als Windows 8.1 verkauft. Heute unterscheidet Redmond immerhin schon Server von Desktop.

An Bord sind ein „Next-Gen“-Virenscanner, Endpoint Detection and Response (EDR), Schwachstellen-Management und eine Geräteinventur. Für den Ernstfall gibt es Live Response und Device Isolation. Sprich: Die Firmen-IT bekommt eine Shell auf eurem Rechner und kann ihn per Mausklick vom Netz trennen. Früher hätten wir so etwas als Fernwartungstrojaner bezeichnet und mit ClamAV gejagt. Heute heißt es Enterprise-grade Protection und kommt mit Lizenzvertrag.

Unterstützt werden RHEL, CentOS, Ubuntu, Debian, SLES, Fedora und Oracle Linux, unter Gnome, KDE oder einem anderen Desktop. Dass ein Sicherheitsprodukt ausgerechnet CentOS aufführt, das seit 2024 keine Updates mehr bekommt, hat schon einen gewissen Charme. Arch Linux fehlt dagegen auf der Liste. Ich bleibe also leider schutzlos – I use Arch, btw. Und, ganz ehrlich, auch ein bisschen erleichtert.

Für wen ist das Ganze gedacht?

Den Defender gibt es nicht als Paket im Software-Center und schon gar nicht kostenlos. Ihr braucht dafür Microsoft Defender for Endpoint Plan 2 oder eine Lizenz für Microsoft 365 E5 bzw. E7. Ein Phoronix-Leser bat im Forum, diese Marketingbegriffe doch bitte mal in normale Sprache zu übersetzen. Mache ich gerne: Für Hinz-und-Kunz-Linux ist das nichts. Und der Status ist ohnehin noch Public Preview.

Ganz ernst gemeint: Ein Argument hat Microsoft schon. Entwickler-Rechner hängen an Git-Repos, CI/CD-Pipelines und Cloud-Zugängen, wer dort einbricht, der greift nach der ganzen Lieferkette. Die eigentliche Zielgruppe sind aber Compliance-Abteilungen. Die haben nun endlich ein Häkchen, um Linux-Notebooks im Konzern zu erlauben. Ob ihr dann noch sudo benutzen dürft, steht auf einem anderen Blatt. Microsoft hat sudo ja ohnehin schon 2009 patentiert.

Die schönste Zusammenfassung lieferte ein Leser im Phoronix-Forum: „Number of viruses on Linux: 1“. In meinen Augen trifft das den Nagel auf den Kopf. Wer privat Linux nutzt, Software aus den Paketquellen installiert und nicht jedes Skript aus dem Netz blind mit Root-Rechten ausführt, der braucht weiterhin keinen Virenscanner. Daran ändert auch ein Defender nichts, der für Linux nun hauptberuflich Windows-Malware sucht.

Nur eine Pointe kann ich mir zum Schluss nicht verkneifen. Schleswig-Holstein will bis Ende 2026 Windows und Microsoft Office aus Verwaltung und Schulen werfen. Pünktlich zur Zielgeraden steht Microsoft nun mit dem passenden Defender für die neuen Linux-Rechner vor der Tür. Wer behauptet, dass man in Redmond nicht flexibel ist? Was meint ihr: Fürsorge, Telemetrie oder einfach nur gutes Geschäft?

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

Der Name stand ursprünglich für Kool Desktop Environment, eine Anspielung auf das kommerzielle Common Desktop Environment (CDE) anderer Unix-Systeme. Weil KDE auf Qt setzte, dessen Lizenz damals nicht wirklich frei war, entstand als Gegenentwurf GNOME. Die Kurzfassung der folgenden Jahre laut heise: 1997 der Verein KDE e.V., 1998 KDE 1, später das beliebte KDE 3 und 2008 das ziemlich holprige KDE 4.

Mit KDE 4 sind damals viele User von Bord gegangen, manche pflegen den Vorgänger bis heute als Trinity-Desktop weiter. Gleichzeitig brachte die Version Programme wie Dolphin und Okular sowie die Plasma-Oberfläche mit. Heute teilt sich das Projekt in die Bibliotheken KDE Frameworks, die Anwendungen in KDE Gear und den Desktop KDE Plasma. Letzterer läuft inzwischen auch auf Smartphones, Fernsehern und dem Steam Deck.

Plasma 6.8: Tschüss, X11

Pünktlich zum Geburtstag ist Plasma 6.8 erschienen, und die Version zieht einen dicken Strich: Plasma startet keine X11-Sitzung mehr, sondern läuft nur noch unter Wayland. Gnome hat diesen Schritt ja bereits vorgemacht. Ältere Programme, die noch X11 brauchen, laufen weiterhin über XWayland. Die KDE-Anwendungen selbst sollen auf X11-Desktops vorerst weiter funktionieren.

Unter der Haube zeichnet KWin laut 9to5Linux nur noch über OpenGL ES, Vulkan soll später folgen. NVIDIA-Grafik bekommt standardmäßig Triple Buffering, die Plasma-Shell startet schneller. Im Alltag sticht Spectacle heraus, das bei Bildschirmaufnahmen nun Systemton und Mikrofon mitschneidet. Neu sind außerdem das Backup-Programm Kup und ein Verweilklick, Steam-Fenster bekommen endlich Schatten und abgerundete Ecken.

Wann ihr Plasma 6.8 bekommt, hängt wie üblich an eurer Distribution. Laut OMG! Ubuntu liefern Rolling-Release-Distributionen wie Arch Linux die Version in den nächsten Tagen aus, bei KDE neon dauert es einige Wochen. Kubuntu 26.10 hat den Termin knapp verpasst und bleibt bei Plasma 6.7. Dort heißt es also warten oder auf einen Backport hoffen.

KDE: The Documentary

Wer sich für die Geschichte hinter den Versionsnummern interessiert, der sollte sich heute Abend eine gute Stunde freihalten. Der YouTube-Kanal CultRepo hat mit Unterstützung von KDE eine Doku gedreht, die um 19:30 Uhr deutscher Zeit Premiere feierte. KDE: The Documentary – The Story of Free Software Underdogs ist auf Englisch und dauert knapp über eine Stunde.

Video wird erst nach Klick von YouTube geladen.

Die Doku erzählt die Höhen und Tiefen der drei Jahrzehnte: den Streit um die Qt-Lizenz und die Rivalität mit GNOME, den Erfolg von KHTML, aus dem später WebKit und damit auch Chrome hervorgingen, und das Debakel um KDE 4. Zu Wort kommen unter anderem Matthias Ettrich, Lars Knoll, Aaron Seigo, Nate Graham und – nett für die Gnome-Ecke – auch GNOME-Mitgründer Miguel de Icaza.

Spenden zum Geburtstag

Ganz ohne Geld läuft natürlich auch freie Software nicht. KDE hat deswegen eine Spendenaktion zum Jahresende gestartet, auf der Seite stehen Meilensteine bei 50.000, 75.000 und 100.000 Euro. Das Geld soll unter anderem in barrierefreie und stromsparende Software fließen. Wer KDE längerfristig helfen möchte, der kann Fördermitglied werden. Das Ziel dafür hat KDE passend zum Gründungsjahr von 1.500 auf 1.996 Mitglieder angehoben.

KDE und ich

Meine eigene Linux-Reise begann mit Fenstermanagern wie Window Maker und Enlightenment E17. Irgendwann, ich schätze zu Zeiten von KDE 3.x, bin ich dann auch bei KDE gelandet. Ein kompletter Desktop mit allem Drum und Dran – das war für Linux damals herausragend. Bis dahin musste man sich Panel, Dateimanager und den ganzen Rest meist noch selbst zusammensuchen.

Ein KDE-Jünger bin ich allerdings nie geworden. In meiner Zeit als „Chrissss“ bei ubuntuusers.de saß ich fest auf der Gnome-Seite und habe bei Wiki-Artikeln regelmäßig die KDEler um Hilfe gebeten, sobald es um den KDE-Teil ging. Für einen Artikel über Bluetooth-Mäuse habe ich dann doch mal KDE 4 installiert – und mich gewundert, dass es nicht einmal Bluetooth-Einstellungen mitbrachte.

Ganz losgelassen hat mich KDE trotzdem nie. 2009 habe ich hier im Blog zu KDE 4.3 gratuliert und gefragt, ob die Entwickler einen alten GNOMEler wie mich noch zum Umstieg bewegen. Ganz geklappt hat das nicht. Doch KDE Connect habe ich mir per Erweiterung in Gnome geholt, und schreibe ich unter KDE Markdown, dann mit Kate. Wenn KDE, dann richtig.

Alles in allem sähe der Linux-Desktop ohne KDE heute ganz anders aus, und ohne den ewigen Wettstreit der beiden wohl auch Gnome. In meinen Augen hat das Projekt einen Großteil dazu beigetragen, dass Linux überhaupt auf normalen Rechnern angekommen ist. Von daher: Herzlichen Glückwunsch zum Dreißigsten! Seit wann nutzt ihr KDE, und welche Version ist euch am meisten im Gedächtnis geblieben?

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

Im Mai 2014 habe ich mir dort einen Account angelegt, seitdem begleitet mich DDNSS. 2016 habe ich den Dienst in den Kommentaren selbst als Anbieter „ohne Nervereien“ weiterempfohlen. Nun liegt eine E-Mail von Robert in meinem Postfach, mit der ich so nicht gerechnet hätte. Nach mehr als 13 Jahren Betrieb steht DDNSS.de vor einer Veränderung: Robert führt derzeit Gespräche über eine mögliche Übernahme des Dienstes.

Übernahme statt Abschaltung

Ein endgültiges Aus ist damit allerdings nicht beschlossen. Spätestens bis zum 31. Oktober 2026 soll eine Entscheidung fallen und die Übergabe geregelt sein – vorausgesetzt, die Gespräche führen zu einem Ergebnis. Kommt die Übernahme zustande, führt der neue Betreiber DDNSS einfach weiter. Scheitern die Gespräche, will Robert rechtzeitig Bescheid geben, damit ihr euch in Ruhe auf einen Wechsel einstellen könnt.

Wer DDNSS in seiner FRITZ!Box oder auf dem eigenen Serverchen eingetragen hat, muss also erst einmal nichts tun. Eure bestehenden DynDNS-Einträge laufen vorerst unverändert weiter, akuten Handlungsbedarf gibt es laut Robert nicht. Rückfragen beantwortet er unter webmaster@ddnss.de. Schaden kann es trotzdem nicht, schon mal nachzusehen, wo bei euch DDNSS überall eingetragen ist – im Router, im ddclient oder in irgendeinem Skript.

Danke, Robert

Leicht fällt Robert der Schritt nicht. Seit Mai 2013 hat er nach eigenen Worten sehr viel Zeit und Arbeit in DDNSS.de gesteckt – ein Geschäftsmodell gab es dabei nie, wer wollte, konnte spenden. Nach über 13 Jahren ist so eine Entscheidung für ihn persönlich alles andere als einfach. Von daher bemüht er sich um eine tragfähige Lösung, statt einfach den Stecker zu ziehen.

Ich möchte mich an dieser Stelle ganz herzlich bei Robert bedanken. In meinen Augen ist es keine Selbstverständlichkeit, so einen kostenlosen Dienst über so viele Jahre am Laufen zu halten. Bei DynDNS merkt man ja meist erst, was man daran hat, wenn es plötzlich nicht mehr funktioniert. Ich hoffe, dass Robert für sein Baby ein ordentliches neues Zuhause findet.

Ich selbst leiste mir inzwischen eine „richtige“ Domain für meine Selfhosting-Aktivitäten. Bei meinem Webhoster geht das recht einfach: Die FRITZ!Box aktualisiert die Einträge meiner eigenen Domain direkt per DynDNS, ein externer Dienst ist dafür nicht mehr nötig. Wer ohnehin eine Domain besitzt, sollte bei seinem Hoster mal nachschauen, ob der so etwas anbietet.

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

Qt6 und ein Assistent für den Start

Die größte Änderung unter der Haube: Picard 3 setzt auf Qt6 statt Qt5. Das bringt bessere Skalierung auf hochauflösenden Displays und einen Dunkelmodus auf allen Plattformen, ein Neustart ist beim Umschalten nicht mehr nötig. Als Voraussetzung nennt das Projekt unter Linux Qt 6.6 und Python 3.10 oder neuer. Wer ein älteres System fährt, bleibt bei Picard 2, das noch mindestens eine Wartungsversion bekommen soll.

Neu ist auch ein Einrichtungsassistent beim ersten Start. Er fragt unter anderem, ob Picard Dateien beim Speichern umbenennen und verschieben soll, und wie es mit Update-Prüfungen aussieht. Dazu kommen kleine Tutorial-Hinweise, die beim ersten Laden von Dateien oder beim Clustern aufpoppen. Beides lässt sich in den Einstellungen abschalten.

Das neue Plugin-System

Die tiefgreifendste Änderung betrifft die Erweiterungen. Plugins brauchen jetzt eine MANIFEST.toml, sind per Git versioniert und lassen sich aus einer zentralen Registry, aus fremden Git-Repositories oder aus einem lokalen Ordner installieren. Es gibt Vertrauensstufen von offiziell bis untrusted, und Plugins mit Sicherheitsproblemen können zentral gesperrt werden. Zum Start sollen etwa 30 Plugins bereitstehen, teils portiert, teils neu.

Der Haken: Plugins aus Picard 2 laufen nicht mehr. Nicht jedes ist schon portiert, wer eines vermisst, kann es im Forum anfragen. Die Plugin-Liste in den Einstellungen ist übrigens erst einmal leer. Mit einem Klick auf „Plugin installieren“ kommt ihr an die verfügbaren Erweiterungen.

Sitzungen, Profile und Cover-Art

Der Workspace lässt sich als Sitzung speichern und später wiederherstellen, inklusive Datei-Zuordnung und manuellen Änderungen. Einstellungsprofile kann man exportieren und importieren, Zugangsdaten bleiben dabei außen vor. Außerdem lassen sich eigene Spalten per Skript definieren, Listen filtern und mehrere Tags auf einmal kopieren.

Bei den Cover-Bildern kann Picard Bilder unterhalb einer Mindestgröße verwerfen, automatisch skalieren oder in ein bestimmtes Format konvertieren. Das Ganze geht auf ein Google-Summer-of-Code-Projekt von 2024 zurück.

Weitere Neuerungen laut Ankündigung:

• Ein überarbeiteter Abgleich bei der Release-Zuordnung und eine Spalte „Match“, die nach Trefferqualität sortiert.
• Der eingebaute Player unterstützt MPRIS2 und kann Listens an ListenBrainz melden.
• Erste Unterstützung für synchronisierte Lyrics im LRC-Format über das Tag syncedlyrics.
• ISRCs lassen sich von CDs auslesen und zu MusicBrainz einreichen.
• Das neue Kommandozeilenwerkzeug picard-cli verwaltet Plugins und Profile.

Wie schlägt sich Picard 3 in der Praxis?

Ich habe Picard 3.0.1 in einer TUXEDO-OS-VM ausprobiert, bewusst nur an Kopien zweier Alben aus meiner Sammlung: „Analogue“ von a-ha und „21“ von Adele. Gespeichert habe ich nichts, die Originale blieben unberührt. Picard 3.0.1 gibt es auf PyPI, das Flathub-Paket ist noch nicht auf dem aktuellen Stand und liefert weiterhin Picard 2.13.3. Der Ablauf ist vertraut: Ordner hinzufügen, Gruppieren, Abfragen. Beide Alben hat Picard auf Anhieb mit 13 von 13 Titeln zugeordnet und das Cover geladen. Bei a-ha schlägt der Editor aus „A-Ha“ ein „a-ha“ vor, so wie MusicBrainz den Namen führt. Die neue Ansicht mit Ursprünglichem und Neuem Wert macht solche Abweichungen schnell sichtbar.

Die Tutorial-Hinweise sind mir beim ersten Laden direkt begegnet. Wer Picard schon kennt, schaltet sie vermutlich ab, für Einsteiger sind sie eine nette Hilfe.

Alles in allem ist Picard 3 für mich vor allem ein großes Fundament-Update. Wer Plugins aus Picard 2 nutzt, sollte vor dem Umstieg prüfen, ob es sie schon im neuen System gibt. Alle anderen bekommen eine modernere Oberfläche und ein paar nützliche Neuerungen. Welche Picard-Plugins fehlen euch bisher in Version 3?

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