Ein Sternchen ist ein Sternchen

Die Lücke hört auf den schönen Namen *sshole und wurde von Özgün Kültekin (Wakefield) gefunden. Unter den passenden Voraussetzungen meldet sich ein Angreifer per SSH mit einem beliebigen Passwort zwischen 257 und 1024 Byte an. Und zwar ausgerechnet bei Accounts, die eigentlich gesperrt sind und gar kein Passwort haben sollen. Darunter kann sich auch root befinden.

Die Ursache ist fast schon komisch. Gesperrte Accounts tragen in der /etc/shadow statt eines Passwort-Hashes oft nur ein *. Die crypt()-Funktion von musl liefert ebenfalls ein * zurück, wenn bei der Passwortverarbeitung etwas schiefgeht. Und genau das passiert bei Passwörtern über 256 Byte. OpenSSH vergleicht dann Sternchen mit Sternchen, findet beide gleich und winkt den Besucher brav durch.

Entstanden ist das Ganze nicht durch einen einzelnen Patzer, sondern durch mehrere für sich genommen harmlose Änderungen. musl hat 2012 sowohl den Rückgabewert im Fehlerfall als auch die Längengrenze eingeführt. OpenSSH hat 2016 eine Timing-Lücke gestopft und damit dafür gesorgt, dass der Fehler auch echte Benutzer mit * erreicht. Rund zehn Jahre ist das niemandem aufgefallen.

Entwarnung für den Linux-Desktop

Wer auf seinem Arch-Rechner, seinem Ubuntu-Notebook oder seinem Heimserverchen mit Debian einen sshd laufen hat, kann sich entspannt zurücklehnen. Die großen Distributionen setzen auf glibc statt musl und lassen OpenSSH in der Standardkonfiguration über PAM prüfen. Damit ist der Weg zum Sternchen-Vergleich gar nicht erst offen. Laut Analyse sind Debian, Ubuntu und Fedora nicht betroffen, ebenso wenig OpenBSD und Dropbear.

Betroffen sind nur Systeme, bei denen alle diese Punkte zusammenkommen:

• Linux mit musl libc (etwa Alpine Linux, OpenWrt, Buildroot oder Yocto)
• OpenSSH ohne PAM
• Passwortauthentifizierung aktiviert
• mindestens ein Account mit * als Passwortfeld in /etc/shadow
• mindestens ein weiterer Account mit gültigem Passwort-Hash

Gruselig wird es dort, wo keiner hinschaut

Auf dem Papier klingt die Liste nach einer Nische. Bei Alpine Linux ist sie allerdings Standard: Das Paket openssh-server arbeitet dort ohne PAM, Passwort-Logins sind an, und root hat seit Alpine 3.16 ein * als Hash. Auf den offiziellen Images für AWS und Azure gibt es zudem den Benutzer alpine, der per doas ohne Passwort zu root wird. Ein langes Passwort, ein doas, fertig.

OpenWrt selbst kommt zwar mit Dropbear als SSH-Server, der nicht betroffen ist. Wer seinen Router aber auf OpenSSH umgestellt hat, etwa wegen SFTP, sollte genauer hinschauen. Richtig unangenehm wird es bei Buildroot und Yocto. Damit bauen Hersteller die Firmware für Router, NAS, Kameras, Industriesteuerungen und allerlei IoT-Kram. Was da genau drinsteckt, verraten die wenigsten Datenblätter.

Und genau diese Kisten hängen gerne direkt im Netz. Es sind die Geräte, die man einmal aufstellt und dann nie wieder anfasst, weil sie ja laufen. Updates gibt es, wenn überhaupt, nur dann, wenn der Hersteller sich daran erinnert, dass er das Ding mal verkauft hat. In meinen Augen ist das der eigentliche Gruselfaktor dieser Lücke, nicht der Linux-Desktop.

Was ihr jetzt tun solltet

OpenSSH hat heute Version 10.6p2 veröffentlicht, die das Problem auf der OpenSSH-Seite abfängt. Unter Alpine Linux zieht ihr das Update ganz normal über die Paketverwaltung mit apk upgrade openssh. Andere Distributionen beheben den Fehler per zurückportiertem Sicherheitspatch. Startet den SSH-Dienst danach neu, damit auch wirklich die neue Version lauscht. Bei Firmware von der Stange bleibt euch nur, beim Hersteller nach einem Update zu suchen.

Wer nicht sofort aktualisieren kann, schaltet die Passwortanmeldung in der sshd_config ab:

PasswordAuthentication no

Vorher solltet ihr natürlich sicherstellen, dass der Zugang per Schlüssel funktioniert, sonst sperrt ihr euch selbst aus. Unter Alpine geht das auch als eigene Konfigurationsdatei mit anschließendem Neustart des Dienstes:

echo "PasswordAuthentication no" > /etc/ssh/sshd_config.d/00-no-passwords.conf
rc-service sshd restart

Ganz ehrlich: Ein SSH-Server mit Passwortanmeldung, der offen im Internet hängt, war auch vor *sshole keine gute Idee. Zu kurze Passwörter werden erraten, zu lange sind ab heute auch verdächtig. Das beste Passwort für SSH ist und bleibt keins, sondern ein Schlüssel. Habt ihr Alpine-Kisten oder einen OpenWrt-Router mit OpenSSH im Einsatz, und wisst ihr, was eure Geräte im Netz eigentlich für einen SSH-Server fahren?

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

Worum geht es beim di.day?

Die Idee dahinter ist schnell erklärt: Jeden ersten Sonntag im Monat wechselt man auf die gute Seite. Gemeint sind digitale Alternativen, die demokratiefreundlich sind und weniger abhängig machen von wenigen Großkonzernen. Der Wechsel geschieht Schritt für Schritt, niemand muss sein digitales Leben an einem Wochenende umkrempeln.

Dafür gibt es auf der Webseite die Wechselrezepte, Anleitungen für 30 bis 90 Minuten. Eines führt von Instagram zu Pixelfed, ein anderes zeigt Podcasts ohne Spotify, ein drittes App-Stores ohne Google und Apple. Dazu kommen Veranstaltungen, die laut Webseite in Deutschland, Portugal, Irland und sogar in Colorado stattfinden.

Marc-Uwe Kling, ja, der mit dem Känguru

Die Idee zum di.day stammt von Marc-Uwe Kling, ja, dem Autor mit dem kommunistischen Känguru. Koordiniert wird das Projekt von Save Social. Vorgestellt wurde es auch bei Funfacts, dem Nachrichtenformat nach dem Motto „Facts, but funny“, das seit dem 2. März 2026 läuft.

Das Video „Wir müssen uns trennen“ läuft unter dem Hashtag #DIDit auf dem Kanal @funfacts_de. Ein Blick lohnt sich, Weihnachten kommt mit schnellen Schritten. Dann ist ja wieder FamilyAdminDay aka Weihnachten, und das Video liefert die Argumente gegen Facebook, Meta, Microsoft, Apple und Co. gleich mit – unterhaltsam verpackt.

Video wird erst nach Klick von YouTube geladen.

Auch bei TUXEDO in Augsburg gab es schon einen di.day

Bei TUXEDO in Augsburg gab es schon mehrere di.days. Am 4. Januar 2026 lud TUXEDO zu einer Linux-Einführung mit Install-Party in die eigenen Räume ein. Wer wollte, konnte sich dort Linux aufspielen lassen. Kollegen halfen mit Tipps und Trick: Unterstützung, vorher die eigenen Daten zu sichern, gab es gleich dazu.

Einen Monat später folgte der zweite DiDay in Augsburg, diesmal zusammen mit dem Makerspace Habitat e.V. im Pop-up-Store „Zwischenzeit“. Die Teilnehmer installierten TUXEDO OS auf ihren eigenen Geräten und nahmen einen USB-Stick mit dem System gleich mit. Leider habe ich es zu den Terminen bisher nicht geschafft, hoffentlich klappt es beim nächsten Mal.

So könnt ihr abstimmen

Beim Publikumsvoting dürft ihr für bis zu drei Angebote abstimmen. Ihr setzt jeweils ein Häkchen bei den Nominierten eurer Wahl und klickt unten auf Absenden, erst dann zählen die Stimmen. Name und E-Mail-Adresse sind freiwillig. Die Frist läuft bis zum 16. November 2026, 11:00 Uhr.

Das Voting findet ihr beim Grimme Online Award. Meine Wahl fällt auf den di.day, aber natürlich seid ihr frei: Alle drei Stimmen dürft ihr beliebig vergeben, auch der di.day ist natürlich keine Pflicht. Die Reihenfolge der Nominierten ist dort zufällig, beim Stöbern entdeckt ihr vielleicht noch weitere spannende Projekte, die eine Stimme von euch verdient haben.

Wer nach dem Abstimmen selbst loslegen möchte: Der nächste di.day ist immer am ersten Sonntag im Monat. Wer gewechselt hat, darf damit angeben: Unter #DUTgemacht (hört ihr das „gut gemacht“ heraus?) und #DIDit („I did it“) freut sich die Community mit euch. Habt ihr schon ein Wechselrezept ausprobiert?

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

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.

Bevor Fragen aufkommen: Nein, Homarr hat nichts mit dem *arr-Stack zu tun, mit dem so mancher Homelab’er auf hoher See segelt. Kleine Ironie am Rande: Ausgerechnet Sonarr und Radarr dienen in den Release Notes immer wieder als Paradebeispiele für die Integrationen des Dashboards.

Die Entwickler sprechen selbst vom „ultimativen Homarr-Update“. Wer keine Lust auf die ziemlich ausführlichen Release Notes hat, bekommt – O-Ton des Projekts – ein Video für die kurze Aufmerksamkeitsspanne. Es zeigt die wichtigsten Neuerungen von Homarr 2.0 in knapp zwei Minuten im Schnelldurchlauf.

Widgets nach Maß und ein Workshop zum Teilen

Das Herzstück der neuen Version sind die Custom Widgets v2. Eigene Widgets entstehen aus JSX, API-Anfragen, Aktionen und typisierten Einstellungen. Wer nicht selbst programmieren mag, beschreibt dem eingebauten Assistant einfach, was er braucht, und testet das Ergebnis anschließend in einer Art Werkbank.

Genau das macht für mich den Reiz aus: Das Widget-System sieht wesentlich umfangreicher und variabler aus als das von Homepage. Laut den Entwicklern lässt sich damit fast jedes Widget bauen – auch das, welches nur drei Leute brauchen. Die müssen jetzt nicht mehr warten.

Die zweite Hälfte des Konzepts heißt Workshop. Dort veröffentlichen, bewerten und installieren User fertige Widgets und eigenes CSS. Ungetesteter KI-Slop hat dort laut den Entwicklern nichts verloren, der Workshop wird moderiert. Zugangsdaten und Adressen der eigenen Instanz bleiben dabei auf dem eigenen Server.

Ebenfalls neu ist eine Schnittstelle, über die Widgets, Skripte oder KI-Agenten per MCP die gespeicherten Integrationen nutzen. Homarr kennt die Adressen und API-Schlüssel der Dienste ja ohnehin. Es prüft die Rechte, hängt die Zugangsdaten an und reicht die Anfrage weiter, ohne die Schlüssel jemals herauszugeben.

Neuer Board-Editor und viel Kleinkram

Den Board-Editor haben die Entwickler außerdem von Grund auf neu aufgebaut. Das alte Drag-and-Drop flog raus, Verschieben und Skalieren laufen jetzt über dnd-kit und prüfen Kollisionen vor dem Speichern. Gruppen und dynamische Abschnitte weichen sogenannten Containern, und feste Seitenleisten kehren zurück.

Dazu kommen eine neue Ersteinrichtung in sechs Schritten, ein frei konfigurierbarer Header und 31 neue Integrationen, etwa für Linkwarden und Karakeep, Frigate oder Mealie. Docker und Podman lassen sich mit mehreren Hosts anbinden. Für Umsteiger wie mich praktisch: Homarr versteht auch die Docker-Labels von Homepage.

Wichtig für bestehende Installationen: Homarr 2.0 unterstützt nur noch SQLite und PostgreSQL, hier laufen die Migrationen beim Start automatisch. Wer bisher MySQL nutzt, muss seine Daten vor dem Update mit einem separaten Skript nach SQLite überführen. Die nötigen Schritte beschreibt eine Anleitung des Projekts.

Ob ich mein Homepage-Setup tatsächlich in Rente schicke, weiß ich noch nicht. Interessant wird Homarr 2.0 für mich aber ganz sicher. Die Live-Demo zum Reinschnuppern hilft euch gerade allerdings nicht weiter: Sie wird aktuell förmlich überrannt und ist daher offline. Welches Dashboard nutzt ihr in eurem Homelab?

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

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.

Die Umstellung auf GTK4 ist für Shotwell mehr als eine optische Modernisierung. Gerade unter Arch Linux mit aktuellem GNOME und Wayland profitiert die Anwendung von den moderneren Schnittstellen des Toolkits. Auch Funktionen wie Drag-and-drop und Desktop-Portale sollen dadurch zuverlässiger funktionieren.

Für meinen Test habe ich Shotwell unter Arch Linux allerdings nicht aus den Paketquellen, sondern als Flatpak installiert. Das ist gerade bei größeren GNOME-Anwendungen interessant, wenn ihr eine aktuelle Version ausprobieren möchtet, ohne auf den Paketstand der Distribution warten zu müssen. Auch lassen sich die Daten der Anwendung schnell rückstandsfrei löschen.

GTK4 bringt Shotwell nach vorn

Shotwell 0.33 bringt neben der GTK4-Portierung zahlreiche kleinere Verbesserungen mit. Dazu gehören eine Übersicht der Tastaturkürzel, überarbeitete Funktionen zum Exportieren und Drucken sowie Toasts als moderne Alternative zu einfachen Dialogfenstern. Auch das Öffnen von URLs im Viewer wurde ergänzt.

Einige Funktionen, die während der GTK4-Portierung vorübergehend fehlten, sind ebenfalls wieder zurück. Dazu gehört insbesondere Drag-and-drop. Außerdem zeigt der Viewer zusätzliche Systeminformationen an, während sich Kontextmenüs nun auch per Tastatur öffnen lassen. Die Navigation zwischen Bedienelementen wurde ebenfalls verbessert.

Veröffentlichung und Fehlerkorrekturen

Überarbeitet wurde zudem die Veröffentlichung von Bildern an externe Dienste. Das Fenster für die externe Authentifizierung kann nun an verschiedenen Stellen angezeigt werden. Den bisherigen separaten Authentifizierungshelfer ersetzt Shotwell durch einen einfachen Webserver, der lokal auf dem Rechner läuft.

Dazu kommen zahlreiche Fehlerkorrekturen. Unter anderem wurden Probleme mit automatisch ausgeblendeten Werkzeugleisten im Vollbildmodus, der Diashow, dem Setzen von Desktop-Hintergründen und dem Versand vieler Bilder behoben. Auch die Arbeit mit Gesichtern und deren Markierungen wurde weiter verbessert.

Mein Eindruck unter Arch Linux

Für mich ist die GTK4-Portierung die eigentlich interessante Nachricht dieses Releases. Shotwell wirkt damit deutlich besser für aktuelle Linux-Desktops aufgestellt. Gerade unter Arch Linux und GNOME mit Wayland ist es angenehm, wenn eine ältere Anwendung nicht dauerhaft auf ihrem bisherigen GTK-Unterbau festhängt.

Wenn ihr Shotwell unter Arch Linux ausprobieren möchtet, könnt ihr zunächst prüfen, welche Version in euren Paketquellen verfügbar ist. Für meinen Test habe ich stattdessen Flatpak verwendet. Damit lässt sich die aktuelle Shotwell-Version unabhängig vom Paketstand von Arch Linux installieren und wieder entfernen. Aktuell hängt selbst Arch Linux eine Version zurück.

Die neue Version ist damit auch für Nutzer interessant, die Shotwell bisher wegen der technisch überholten GTK3-Basis nicht mehr auf dem Radar hatten. Ob die Anwendung dauerhaft als Bildverwaltung überzeugt, hängt natürlich stark vom eigenen Workflow ab. Für eine schlanke GNOME-Lösung ist sie aber einen Blick wert.

Weitere Beiträge zu GNOME und Bildern

Zum Thema Bildbearbeitung und Fotowerkzeuge findet ihr auch schon einige ältere Beiträge hier im Blog. So habe ich beispielsweise einfache Bildbearbeitung unter Linux und verschiedene Werkzeuge rund um Screenshots und die Arbeit mit Bildern vorgestellt. Auch Gradia setzt inzwischen konsequent auf GTK4.

Die aktuelle Shotwell-Version findet ihr als Flatpak auf Flathub. Wer sich für die neusten technischen Änderungen der Anwendung interessiert und dem weiteren Verlauf der Entwicklung folgen möchte, kann außerdem die offizielle Release-Ankündigung und die Projektseite von Shotwell ansehen.

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