Linux und Ich

Microsoft Defender für Linux-Desktops: Endlich kann ich wieder ruhig schlafen

2026-10-15T13:47:47Z

Ich habe heute früh zweimal auf den Kalender geschaut. Nein, es ist nicht der 1. April, es ist der 15. Oktober. Und trotzdem hat Microsoft gestern ganz ohne Augenzwinkern Microsoft Defender für Linux-Desktops angekündigt. Für mich ist das eine kleine Erlösung: Seit fast 20 Jahren tippe ich ungeschützt auf Linux-Kisten herum, und ich lebe tatsächlich noch. Damit ist jetzt endlich Schluss.

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.

30 Jahre KDE: Plasma 6.8 ohne X11 und eine Doku zum Geburtstag

2026-10-14T21:50:01Z

Heute vor genau 30 Jahren, am 14. Oktober 1996, hat ein Student aus Tübingen namens Matthias Ettrich im Usenet nach Mitstreitern gesucht. Sein Ziel: eine grafische Oberfläche für Linux, die nicht nur Admins, sondern ganz normale Endanwender bedienen können. Daraus ist KDE geworden, eine der größten Gemeinschaften rund um freie Software. Zum Geburtstag gibt es drei Dinge: Plasma 6.8, eine Doku und eine Spendenaktion.

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.

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?

GNOME sucht Freiwillige für das Extensions-Team: EGO-Reviews ersticken in KI-Einreichungen

2026-10-13T18:28:15Z

Wer GNOME mit Shell-Erweiterungen nutzt, kennt extensions.gnome.org, kurz EGO, als zentrale Anlaufstelle. Jede Erweiterung wird dort vor der Veröffentlichung von Menschen geprüft. Und genau diese Menschen sind laut einem Aufruf von Javad Rahmatzadeh immer mehr am Limit. Der ganze Beitrag liest sich wie ein Hilferuf, und genau das ist er in meinen Augen auch.

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?

Gnomos: Sonos-Lautsprecher am GNOME-Desktop steuern, auch alte Modelle

2026-10-12T18:16:31Z

Seit Jahren stehen bei mir Sonos-Lautsprecher im Haus, nur unter Linux fehlte mir dazu eine passende Steuerung. Mit Noson-App gibt es zwar einen freien Sonos-Client. Ich bevorzuge allerdings Anwendungen, die sich ordentlich in den GNOME-Desktop integrieren, und da liegt bei Noson in meinen Augen noch viel Potenzial brach. Das ist keine Kritik am Projekt, nicht jeder Entwickler hat Lust sich mit GTK und GNOME herumzuplagen.

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.

Das Video zeigt synchrone Songtexte, das Gruppieren von Räumen, die Lautstärke in den Schnelleinstellungen und den Mini-Player.

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

DDNSS.de: Betreiber verhandelt über eine Übernahme des DynDNS-Dienstes

2026-10-11T03:28:21Z

Im Mai 2013 machte Dyn, früher einmal dyndns.org, den Login alle 30 Tage zur Pflicht. Ich hatte mich damals in einem Artikel nach einem DynDNS-Anbieter umgeschaut, der nicht jeden Monat nervt. Wenige Wochen später meldete sich Robert Niedziela in den Kommentaren mit einem knappen „biete kostenlosen dyndns dienst.“ Sein Dienst DDNSS.de war da gerade einmal einen Monat alt.

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.

MusicBrainz Picard 3.0: Qt6, Plugin-System und Einrichtungsassistent

2026-10-08T18:05:08Z

Wer seine Musiksammlung sauber getaggt haben möchte, der kommt an Picard kaum vorbei. Der Tag-Editor des MusicBrainz-Projekts gleicht Dateien mit der Datenbank ab und schreibt Interpret, Album, Cover und Co. zurück in die Tags. Am 4. Oktober haben die Macher Picard 3.0 veröffentlicht. Laut Ankündigung stecken knapp drei Jahre Arbeit darin, seit Ende 2023 die Umstellung auf PyQt6 begann: 687 gemergte Pull Requests, fast 6.800 Commits und Beiträge von über 100 Leuten.

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?

scrcpy 5.0 spiegelt Android per Hardware-Dekodierung – jetzt in Arch Linux

2026-10-08T01:22:17Z

Wer sein Android-Smartphone auf dem Linux-Desktop spiegeln möchte, landet früher oder später bei scrcpy. Das freie Programm von Genymobile zeigt den Handy-Bildschirm im Fenster und lässt sich per Maus und Tastatur bedienen, ganz ohne Root-Rechte. Seit dem 5. Oktober gibt es Version 5.0, und die bringt eine Neuerung mit, auf die viele lange gewartet haben: Hardware-Dekodierung.

Der Videostream vom Handy wurde bisher komplett von der CPU entpackt. Mit scrcpy 5.0 übernimmt das die Grafikeinheit, unter Linux per VA-API. Die Neuerung betrifft nur die Seite des Computers, nicht das Handy. Die Release-Notes von scrcpy 5.0 versprechen eine um den Faktor zehn geringere CPU-Last. Auch OMG! Ubuntu berichtet über das Release, und auf Reddit läuft im Subreddit r/Android ein Thread dazu.

Die Hardware-Dekodierung ist ab Werk aktiv, ein zusätzlicher Schalter ist nicht nötig. scrcpy sucht sich den ersten passenden Decoder selbst und fällt andernfalls auf Software zurück. Wer eingreifen möchte, nutzt laut Dokumentation --hwdec, etwa mit auto, vaapi oder disabled. Daneben gibt es Kleinkram: Der Audio-Capture-Modus greift nun alle Quellen ab, ANDROID_SERIAL funktioniert im OTG-Modus, und Shift sowie AltGr verschwinden im UHID-Modus nicht mehr.

Windows-User bekommen erstmals native ARM64-Builds. Für Linux ist das nicht relevant, hier zählt die Grafik. Bei mir ist scrcpy 5.0 gerade per Update auf dem Arch-Notebook gelandet, ein sudo pacman -Syu genügt. Wer das Programm noch nicht installiert hat, holt sich das scrcpy-Paket von Arch Linux mit sudo pacman -S scrcpy. Der Quelltext liegt im GitHub-Repository von scrcpy.

scrcpy

Spiegelt Android-Geräte per USB oder WLAN auf den Linux-Desktop und lässt sie per Maus und Tastatur bedienen – ohne Root.

Version: 5.0
Lizenz: Apache-2.0
Getestet mit: Arch Linux, Pixel 10 mit Android 17, Intel Iris Xe
Projekt: Quellcode

Installation

Arch Linux sudo pacman -S scrcpy

Läuft die Hardware-Dekodierung wirklich?

Damit VA-API etwas zu tun hat, braucht ihr auf dem Rechner einen passenden Treiber. Bei Intel ist das intel-media-driver, bei AMD reicht Mesa. Was die ArchWiki zur Hardware-Videobeschleunigung schreibt, gilt hier eins zu eins, Details zu den Treibern stehen dort. Bei mir arbeitet eine Intel Iris Xe, und scrcpy meldet beim Start brav, dass es VA-API nutzt:

INFO: Interop: vaapi
INFO: Video decoding: vaapi
INFO: Texture (VA-API): 1080x2424

Ich wollte es genauer wissen und habe das Pixel 10 per USB verbunden. Während scrcpy lief, habe ich den Bildschirm sechsmal rauf und runter gescrollt und die verbrauchte CPU-Zeit des scrcpy-Prozesses gemessen. Mit --hwdec=disabled waren es rund 2,9 Sekunden, mit --hwdec=auto nur 0,37 Sekunden. Das ist etwa Faktor acht. Der Test lief zweimal mit gleichem Ergebnis, der Stream war auf 60 FPS begrenzt.

Aurynk: scrcpy mit grafischer Oberfläche

Wer nicht gern Kommandozeilen-Parameter tippt, findet in Aurynk eine hübsche Oberfläche. Die GTK4-App mit Libadwaita-Optik (Quelltext auf GitHub) koppelt Android-Geräte per drahtlosem Debugging, zeigt technische Daten an und startet scrcpy auf Knopfdruck. Sie steht auf Flathub, die Installation läuft wie gewohnt:

$ flatpak install flathub io.github.IshuSinghSE.aurynk

Zum Koppeln öffnet ihr auf dem Handy die Entwickleroptionen und aktiviert das Debugging über WLAN. Aurynk bietet zwei Wege an: einen QR-Code, den ihr mit dem Handy scannt, oder die manuelle Eingabe von IP-Adresse, Port und sechsstelligem Kopplungscode. Ich habe die manuelle Variante genommen. Anschließend zeigt Aurynk Name, Android-Version, RAM, Speicher und Akkustand des Geräts an.

Ganz glatt lief es bei mir allerdings nicht. Aurynk meldete nach dem Koppeln, dass es den Verbindungsport nicht automatisch findet, und zeigte das Gerät nicht an. Geholfen hat ein Workaround: Zuerst habe ich mit adb connect die Verbindung zum Handy aufgebaut und danach in Aurynk noch einmal mit einem frischen Code gekoppelt. Dann tauchte das Pixel in der Liste auf.

Ein Haken bleibt: Das Flatpak bringt sein eigenes scrcpy mit, und das ist Version 3.3.3. Von der neuen Hardware-Dekodierung profitiert Aurynk daher vorerst nicht. Das ändert sich, sobald der Entwickler sein Paket aktualisiert. Wer die 5.0 jetzt schon nutzen möchte, startet scrcpy aus dem Arch-Paket direkt im Terminal. Das Spiegeln selbst funktioniert in Aurynk trotzdem tadellos.

Desktop-Modus: Multitasking auf dem Pixel

Mit --new-display legt scrcpy auf dem Handy ein virtuelles Display an und zeigt es als eigenes Fenster. Ich habe scrcpy --new-display=1920x1080/160 auf dem Pixel 10 mit Android 17 probiert. Heraus kommt ein Desktop mit Taskleiste. Apps öffnen dort erst als Fenster, wenn ihr sie per adb shell am start --display 37 --windowingMode 5 startet. Die 37 ist die ID, die scrcpy beim Start meldet.

Im Fenster laufen nun Browser, Taschenrechner und Stoppuhr nebeneinander, frei verschiebbar wie auf einem normalen Desktop. Auch mehrere Bildschirme gehen: Eine zweite scrcpy-Instanz bekam ein eigenes virtuelles Display, und beide liefen parallel. Die Fenster starteten allerdings im Handy-Hochformat, die gewünschte Größe habe ich per am task resize nachgezogen. Ganz ohne Gefrickel geht es also nicht.

Ein paar Tipps aus der Reddit-Diskussion lohnen sich ebenfalls: --turn-screen-off schaltet das Handy-Display aus, --stay-awake hält es wach, damit sich das Handy nicht sperrt und die Verbindung kappt, und --video-codec=h265 nutzt den sparsameren Codec. Bei mir lag der CPU-Bedarf mit H.265 und Hardware-Dekodierung bei 0,39 Sekunden, ohne bei 3,5 Sekunden. Kommentatoren nutzen scrcpy sogar zur Datenrettung bei kaputtem Touchscreen.

Ein Haken kam in der Diskussion mehrfach zur Sprache: Mit aktivierten Entwickleroptionen verweigern manche Banking-Apps den Dienst. Ein Kommentator schreibt, Android 17 QPR1 verhindere diese Prüfung auf Pixel-Geräten. Ich habe das nicht getestet. Andere nutzen die App Geto, die Entwickleroptionen pro App abschaltet, dabei bricht aber die ADB-Verbindung ab. Wer es braucht, sollte also vorher mit der eigenen Bank-App testen.

Dass sich ein Smartphone vom Desktop aus bedienen lässt, ist übrigens kein neuer Trick. Schon 2010 habe ich dafür ein Java-Programm aus dem xda-Forum bemüht, und Screenshots per adb vom Terminal schoss 2014 android-scrot. Wer sein Android-Gerät ohnehin als halben Linux-Rechner nutzt, dem sei außerdem der Überblick zur neuen Linux-VM für Android ans Herz gelegt.

Mein Fazit: Wer scrcpy unter Arch nutzt, sollte nach dem Update einmal in die Startmeldung schauen. Steht dort „Video decoding: vaapi“, sinkt die CPU-Last spürbar, was gerade bei Notebooks dem Akku guttut. Aurynk ist eine nette Hilfe für alle, die ungern im Terminal tippen. Spiegelt ihr euer Handy per scrcpy oder lieber mit einer anderen Lösung?

Raspberry Pi Imager 2.0 unter Linux: Installation, Root-Rechte, CLI und Tipps

2026-10-14T16:51:43Z

In der letzten Zeit bringe ich meine Raspberry Pis wieder deutlich häufiger zum Einsatz. Und wer neue Projekte auf dem Minirechner startet, der landet zwangsläufig wieder beim Raspberry Pi Imager. Als ich das Programm zuletzt häufiger genutzt habe, war es noch ein schlichtes Fenster mit drei Knöpfen und einem versteckten Einstellungsdialog.

Von daher wollte ich mal wieder schauen, was sich beim Imager so getan hat. Die kurze Antwort: eine ganze Menge. Die lange Antwort – mit besonderem Blick auf uns Linux-User und die kleinen Stolperfallen, die in den meisten Anleitungen unter den Tisch fallen – gibt es in diesem Artikel.

Was ist der Raspberry Pi Imager?

Der Raspberry Pi Imager ist das offizielle Werkzeug der Raspberry Pi-Macher, um Betriebssystem-Images auf eine microSD-Karte, einen USB-Stick oder eine SSD zu schreiben. Anders als bei einem schnöden dd lädt der Imager die Images direkt herunter, entpackt sie on the fly, schreibt sie und prüft anschließend das Ergebnis.

Neben Raspberry Pi OS findet ihr in der Auswahl auch Ubuntu, Mediacenter-Distributionen, Retro-Gaming-Systeme, Images für 3D-Drucker und Heimautomatisierung sowie Hilfs-Images, etwa zum Aktualisieren des Bootloaders. Das Programm steht unter der Apache-2.0-Lizenz, der Quellcode liegt auf GitHub. Ihr könnt also jederzeit nachschauen, was es auf eurem Rechner treibt.

Der eigentliche Clou ist aber die Vorkonfiguration: Hostname, Benutzerkonto, WLAN, Zeitzone, Tastaturlayout und SSH-Zugang lassen sich schon vor dem ersten Start festlegen. Der Pi kommt dann direkt fertig eingerichtet ins Netz – ideal für den Headless-Betrieb, bei dem ihr ohne Monitor und Tastatur auskommen wollt.

Was ist neu im Raspberry Pi Imager 2.0?

Ende November 2025 hat die Foundation den Raspberry Pi Imager 2.0 veröffentlicht, inzwischen ist die Version 2.0.11 aktuell (bzw. 2.0.11.1 als Hotfix). Unter der Haube hat sich seitdem viel getan, vor allem aber sieht das Programm komplett anders aus. Die wichtigsten Änderungen im Überblick:

Assistent statt Einzelfenster: Ihr klickt euch nun Schritt für Schritt durch Gerät, Betriebssystem, Speichermedium, Anpassungen und Schreibvorgang.
Anpassungen gut sichtbar: Der früher versteckte Dialog für die „erweiterten Optionen“ (ich sag nur Strg+Umschalt+X) ist jetzt ein regulärer Schritt im Assistenten.
Standort per Hauptstadt: Statt Ländercodes wählt ihr eine Hauptstadt aus, der Imager leitet daraus Zeitzone, Tastaturlayout und das WLAN-Regulierungsland ab.
Schnittstellen per Mausklick: I2C, SPI, 1-Wire, die serielle Schnittstelle und den USB-Gadget-Modus (der Pi meldet sich am USB-Port als Netzwerkgerät, SSH klappt dann direkt übers Kabel) schaltet ihr direkt im Imager ein, der Umweg über raspi-config entfällt.
Raspberry Pi Connect: Ihr könnt euch schon beim Schreiben mit eurem Connect-Konto anmelden, der Pi taucht dann nach dem ersten Boot direkt in der Fernwartung auf. Seit Version 2.0.10 klappt das auch mit Connect for Organisations.
Barrierefreiheit: Die Oberfläche lässt sich komplett per Tastatur bedienen und ist für Screenreader beschriftet.
Strengere Verifikation: Der Imager zwingt das Betriebssystem, geschriebene Blöcke tatsächlich zu bestätigen. Das kann das Schreiben etwas verlängern, dafür ist das Ergebnis verlässlicher.

Es ist aber auch etwas weggefallen: Eigene Image-Dateien lassen sich zwar weiterhin schreiben, aber nicht mehr mit Hostname, WLAN und Co. vorkonfigurieren. Die Entwickler begründen das damit, dass diese Funktion nie offiziell unterstützt wurde. Anpassen lassen sich nur noch Images, die entsprechend gekennzeichnet sind.

Wer bisher etwa ein selbst gebautes Image mit dem Imager vorkonfiguriert hat, der muss sich also einen anderen Weg suchen – oder greift zum CLI-Modus, den ich weiter unten vorstelle. Entwarnung gibt es dagegen bei den SSH-Schlüsseln: Die zum Start von 2.0 gestrichene Unterstützung für mehrere Schlüssel ist inzwischen wieder zurück.

Raspberry Pi Imager unter Linux installieren

Jetzt wird es für uns Linux-User spannend, denn hier unterscheiden sich die Distributionen deutlich. Die offizielle Download-Seite bietet für Linux ein AppImage an. Auf GitHub gibt es zusätzlich .deb-Pakete für amd64, arm64 und armhf sowie eine reine Kommandozeilenversion. Was eure Distribution mitbringt, ist dagegen eine andere Geschichte.

Arch Linux: aktuell direkt aus extra

Arch-User haben es wie so oft am bequemsten: Der Imager liegt im offiziellen Repository extra und ist dort aktuell (zum Zeitpunkt dieses Artikels die Version 2.0.11.1). Ein AUR-Helper ist nicht nötig, ein einfacher Aufruf von pacman genügt, und schon steht der Imager in eurem Anwendungsmenü bereit:

$ sudo pacman -S rpi-imager

Das Arch-Paket bringt eine Polkit-Regel mit. Startet ihr den Imager ganz normal aus dem Anwendungsmenü, fordert er sich über pkexec selbst die nötigen Rechte an – ihr gebt also nur euer Passwort im Polkit-Dialog ein. Wer einen AUR-Helper wie Paru oder Yay nutzt, findet im AUR zudem rpi-imager-git – normalerweise braucht ihr das nicht.

Ubuntu: Finger weg von Universe und Snap

Bei Ubuntu lauert dagegen eine Falle, über die keine der gängigen Anleitungen ein Wort verliert. Ein sudo apt install rpi-imager funktioniert zwar, installiert aber selbst unter Ubuntu 26.04 noch die uralte Version 1.8.5 aus universe. Auch das Snap im Snap Store steht bei Version 1.9.6.

Beide Pakete bekommen also nichts von dem neuen Assistenten, Raspberry Pi Connect oder den Fehlerkorrekturen der letzten Monate mit. Ubuntu-User greifen daher besser zum AppImage, zum Flatpak (beides weiter unten) oder zum offiziellen .deb-Paket von GitHub. Ersetzt im Befehl durch die Versionsnummer der heruntergeladenen Datei:

$ sudo apt install ./rpi-imager__amd64.deb

Habt ihr schon eine alte Version per apt oder Snap installiert, dann werft sie vorher runter, damit ihr im Anwendungsmenü nicht zwei Imager nebeneinander stehen habt. Sonst startet ihr im Zweifel versehentlich die alte Version und wundert euch über die fehlenden Funktionen.

$ sudo apt remove rpi-imager
$ sudo snap remove rpi-imager

AppImage: der offizielle Weg für alle Distributionen

Das AppImage funktioniert unabhängig von der Distribution – also auch unter Fedora, openSUSE und Co. Ladet es von der offiziellen Download-Seite herunter, macht es ausführbar und startet es, eine Installation ist nicht nötig. Den Platzhalter ersetzt ihr auch hier durch die Versionsnummer aus dem Dateinamen:

$ chmod +x Raspberry_Pi_Imager-v-desktop-x86_64.AppImage
$ ./Raspberry_Pi_Imager-v-desktop-x86_64.AppImage

Beim ersten Start ohne Root-Rechte meckert der Imager und bietet euch die Schaltfläche Autorisierung installieren an. Klickt ihr darauf, legt er (nach Eingabe eures Passworts) eine Polkit-Regel unter /etc/polkit-1/actions/ ab, die genau für diesen Pfad des AppImages gilt. Danach holt er sich die Rechte bei jedem Start selbst.

Verschiebt ihr das AppImage später in einen anderen Ordner, müsst ihr die Autorisierung erneut einrichten. Wer lieber ohne dauerhafte Regel arbeitet, startet das AppImage mit sudo. Dabei gibt es einen Stolperstein, auf den Michael Kofler in seinem Artikel hinweist: sudo sucht nicht im aktuellen Verzeichnis, ihr müsst also einen Pfad angeben.

$ sudo ./Raspberry_Pi_Imager-v-desktop-x86_64.AppImage

Ohne das ./ gibt es nur ein „Befehl nicht gefunden“. Kurios: Genau diesen Befehl ohne Pfad schlägt euch der Imager im Dialog zu den fehlenden Rechten selbst vor. Unter Ubuntu 24.04 lauert zudem eine zweite Falle: Dort stürzt das AppImage direkt beim Start ab, weil Qt eine Bibliothek für X11 fehlt. Im Terminal sieht das so aus:

$ ./Raspberry_Pi_Imager-v2.0.11-desktop-x86_64.AppImage 
Platform: Linux 7.0.0-38-generic (x86_64)
qt.qpa.plugin: From 6.5.0, xcb-cursor0 or libxcb-cursor0 is needed to load the Qt xcb platform plugin.
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "/tmp/.mount_RaspbedIOBeG/usr/plugins/platforms" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vkkhrdisplay, vnc, wayland-brcm, wayland-egl, wayland, xcb.

Abgebrochen (Speicherabzug geschrieben)

Abhilfe schafft das Paket libxcb-cursor0, das ihr ganz normal über die Paketverwaltung nachinstalliert. Danach startet der Imager auch unter Ubuntu 24.04 ohne Murren. Unter Ubuntu 26.04 tritt das Problem nicht mehr auf. Das früher oft empfohlene Paket libfuse2t64 war bei meinem Test dagegen nicht mehr nötig.

$ sudo apt install libxcb-cursor0

Übrigens: Der Hotfix 2.0.11.1 ist bisher nur für Windows, macOS und als .deb-Paket erschienen, als AppImage ist 2.0.11 die neueste Version. Das ist aber kein Beinbruch, denn der Hotfix korrigiert lediglich einen Fehler bei der Anmeldung an Raspberry Pi Connect. Wer Connect nicht nutzt, verpasst also nichts.

Flatpak: bequem, aber nicht vom Hersteller verifiziert

Auf Flathub liegt der Imager als org.raspberrypi.rpi-imager in der aktuellen Version bereit. Das Flatpak bekommt vollen Zugriff auf alle Geräte und spricht UDisks2 an, um die Speichermedien zu beschreiben. Nett für Datenschutzbewusste: Es wird ohne Telemetrie gebaut. Installiert wird es wie gewohnt:

$ flatpak install flathub org.raspberrypi.rpi-imager

Beachtet allerdings, dass die App auf Flathub nicht als verifiziert markiert ist. Flathub nennt zwar Raspberry Pi Ltd als Entwickler, ob die Raspberry Pi das Paket selbst pflegt, lässt sich so aber nicht erkennen. In der Regel ist das kein Problem, ihr solltet es aber wissen.

Raspberry Pi OS

Wer den Imager direkt auf einem Raspberry Pi nutzen möchte, etwa um eine zweite Karte oder eine SSD für einen anderen Pi vorzubereiten, der installiert ihn unter Raspberry Pi OS ganz klassisch aus den Paketquellen. Hier stammt das Paket direkt aus den Quellen der Foundation, anders als bei Ubuntu:

$ sudo apt update && sudo apt install rpi-imager

Ganz ohne zweiten Rechner kommt ihr beim Raspberry Pi 4 und 5 aus: Deren Bootloader kann per Netzwerk-Installation eine abgespeckte Version des Imagers aus dem Netz laden, mit der ihr dann direkt eine SD-Karte oder SSD im Pi beschreibt. Mit Version 2.0.11 wurde dieser Netzwerk-Installer spürbar überarbeitet und verschlankt.

Warum braucht der Imager überhaupt Root-Rechte?

Unter Windows und macOS fällt es kaum auf, unter Linux dagegen schon: Der Imager schreibt direkt auf das Blockgerät, also etwa /dev/sdb oder /dev/mmcblk0, und das darf ein normaler Benutzer nicht. Die Version 2 kümmert sich deshalb selbst darum, sich über pkexec die nötigen Rechte zu holen.

Voraussetzung ist eine passende Polkit-Regel. Beim Arch-Paket und dem offiziellen .deb wird diese mitinstalliert, beim AppImage legt ihr sie über Autorisierung installieren an. Startet ihr den Imager per sudo oder pkexec, landen Einstellungen und Download-Cache trotzdem in eurem Home-Verzeichnis und nicht in /root, denn der Imager erkennt den aufrufenden Benutzer.

Kleiner Tipp für Aufräumer: Die vom AppImage angelegten Regeln heißen com.raspberrypi.rpi-imager.appimage-.policy und liegen unter /etc/polkit-1/actions/. Löscht ihr das AppImage, könnt ihr die dazugehörige Regel dort von Hand entfernen. Auch auf Distributionen mit schreibgeschütztem /usr wie Fedora Silverblue klappt das, da der Imager bewusst nach /etc schreibt.

Das braucht ihr

Für den Einstieg reicht ein Pi 5 mit Netzteil und einer schnellen microSD-Karte. Die Auswahl nach aktuellem Stand (Oktober 2026):

Der Rechner

Raspberry Pi 5 (4 GB)
Reicht für die meisten Projekte: Pi-hole, Home Assistant, kleine Server.

Bei Amazon

Raspberry Pi 5 (8 GB)
Mehr Luft für Desktop, Container und Experimente.

Bei Amazon

Zum Betrieb

Offizielles 27-W-USB-C-Netzteil
Der Pi 5 braucht 5 V mit 5 A, ein schwächeres Netzteil bremst ihn und die USB-Anschlüsse aus.

Bei Amazon

Offizielles Gehäuse
Schlicht, passt genau und hat Platz für den Lüfter.

Bei Amazon

Offizieller Active Cooler
Aufsteckbarer Lüfter mit Kühlkörper, regelt sich nach der Temperatur selbst.

Bei Amazon

Zum Beschreiben mit dem Imager

SanDisk Extreme microSDXC, 128 GB
Schnelle Karte (A2): Schreiben und Prüfen im Imager gehen spürbar flotter.

Bei Amazon

UGREEN-Kartenleser (USB-A und USB-C)
Mit USB 3.0 und bis zu 5 Gbit/s. Ein alter USB-2-Leser bremst jede Karte aus.

Bei Amazon

Alternativen

Samsung EVO Plus microSD, 128 GB
Ebenfalls bewährt, wenn die SanDisk gerade nicht lieferbar ist.

Bei Amazon

Raspberry Pi 500 (deutsches Layout)
Ein Pi 5 mit 8 GB direkt in der Tastatur, microSD mit Raspberry Pi OS liegt bei.

Bei Amazon

Anzeige: Alle Links in diesem Kasten sind Affiliate-Links zu Amazon. Wenn ihr darüber kauft, bekomme ich eine kleine Provision, für euch ändert sich am Preis nichts. Preise nenne ich bewusst nicht, sie schwanken zu stark. Den aktuellen Preis seht ihr direkt bei Amazon.

So schreibt ihr ein Image mit dem Raspberry Pi Imager

Die eigentliche Bedienung ist mit dem neuen Assistenten schnell erklärt. Ihr arbeitet euch von oben nach unten durch fünf Schritte und könnt jederzeit einen Schritt zurückgehen, falls ihr euch verklickt habt. Geschrieben wird erst ganz am Ende nach einer ausdrücklichen Sicherheitsabfrage, vorher passiert mit eurer SD-Karte also nichts:

Gerät wählen: Zuerst sagt ihr dem Imager, für welches Modell das Image gedacht ist, etwa Raspberry Pi 5 oder Raspberry Pi Zero 2 W. Die Liste der Betriebssysteme wird danach passend gefiltert.
Betriebssystem wählen: Hier sucht ihr euch Raspberry Pi OS (mit oder ohne Desktop, 32 oder 64 Bit) oder eine der vielen anderen Distributionen aus. Über Eigenes Image wählt ihr ein lokal gespeichertes Image aus.
Speichermedium wählen: Jetzt kommt die SD-Karte oder der USB-Stick. Mehr dazu gleich im nächsten Abschnitt.
Anpassen: Hostname, Standort, Benutzer und Passwort, WLAN, SSH (per Passwort oder Public Key), Raspberry Pi Connect sowie Schnittstellen wie I2C und SPI. Je nach Betriebssystem schreibt der Imager diese Einstellungen als firstrun.sh, als cloud-init-Konfiguration oder in einem weiteren Format auf die Boot-Partition.
Schreiben: Nach einer Sicherheitsabfrage lädt der Imager das Image herunter, schreibt und verifiziert es. Einmal heruntergeladene Images landen im Cache, beim nächsten Schreiben desselben Images geht es deutlich schneller.

Wer mehrere Pis auf einmal einrichten möchte, der freut sich über die Funktion zum Schreiben einer weiteren Karte am Ende des Assistenten. Damit schreibt ihr dasselbe Image samt Anpassungen gleich noch einmal, ohne euch erneut durch alle Schritte klicken zu müssen. Denkt dann aber daran, den Hostnamen anzupassen.

Mein Tipp für den Headless-Betrieb: Hinterlegt direkt euren öffentlichen SSH-Schlüssel statt eines Passworts. Dann könnt ihr euch sofort nach dem ersten Boot per ssh auf den Pi schalten, ohne jemals ein Passwort eintippen zu müssen. Wer von mehreren Rechnern aus zugreift, trägt einfach mehrere Schlüssel ein.

Setzt ihr einen Pi mit gleichem Hostnamen neu auf, meckert SSH beim nächsten Login über einen geänderten Host-Schlüssel. In diesem Fall steckt kein Angriff dahinter, denn das frisch installierte System hat schlicht neue Schlüssel erzeugt. Mit einem einzigen Befehl ist das Problem schnell behoben.

Achtung: das richtige Laufwerk erwischen

Der wohl wichtigste Punkt überhaupt: Der Imager überschreibt das gewählte Speichermedium komplett und prüft nicht, ob es noch Daten enthält. Michael Kofler kritisiert zu Recht, dass die Symbole für SD-Karten und USB-Geräte in der Auswahl verwirrend sein können und in der Zusammenfassung nicht der konkrete Gerätename wie /dev/sde erscheint.

Klar, der Imager blendet Systemlaufwerke standardmäßig aus, doch eine externe Backup-Platte am USB-Port ist für ihn eben auch nur ein Wechseldatenträger. Unter Linux habt ihr allerdings ein einfaches Mittel, um auf Nummer sicher zu gehen: Schaut vor und nach dem Einstecken der SD-Karte mit lsblk nach, welches Gerät neu hinzugekommen ist.

$ lsblk -o NAME,SIZE,MODEL,TRAN,MOUNTPOINTS
NAME          SIZE MODEL                TRAN   MOUNTPOINTS
sda           4,5T WDC WD50NDZW-11BCSS1 usb    
└─sda1        4,5T                             /mnt/backup
sdb         117,2G Speed Line           usb    
├─sdb1        198K                             
├─sdb2        2,8M                             
└─sdb3        4,6G                             
zram0         3,8G                             [SWAP]
nvme0n1       3,6T CT4000P3PSSD8        nvme   
├─nvme0n1p1   512M                      nvme   /boot
└─nvme0n1p2   3,6T                      nvme   /var/log
                                               /var/cache/pacman/pkg
                                               /home
                                               /.snapshots
                                               /

In meinem Beispiel ist die Sache eindeutig: Unter sdb steckt der USB-Stick „Speed Line“ mit gut 117 GByte und den Reste eines alten ISO-Images. Bei sda handelt es sich dagegen um die externe Backup-Platte, die unter /mnt/backup eingehängt ist. Beide hängen laut Spalte TRAN am USB-Port.

Genau hier lauert die Gefahr, denn für den Imager sind beide Laufwerke gleichermaßen Wechseldatenträger. Größe und Modellname verraten euch, welches Gerät das richtige ist. Zieht zur Sicherheit am besten alle externen Festplatten ab, bevor ihr den Imager startet. Ein paar Sekunden Vorsicht sind allemal besser als eine plattgebügelte Backup-Platte.

Seit Version 2.0.11 sperrt der Imager unter Linux das Laufwerk übrigens exklusiv, solange er darauf schreibt. Kein anderes Programm kann dann gleichzeitig auf die Karte zugreifen und euch das frisch geschriebene Image zerschießen. Vor einer falschen Auswahl schützt euch das natürlich nicht, da hilft nur ein prüfender Blick.

Raspberry Pi Imager im Terminal: der CLI-Modus

Was die meisten Anleitungen nicht erwähnen: Der Imager lässt sich auch komplett ohne grafische Oberfläche nutzen. Das ist praktisch für Skripte, für die Arbeit per SSH oder wenn ihr mehrere Karten vorbereiten wollt. Den CLI-Modus aktiviert ihr mit --cli, danach folgen Image und Zielgerät:

$ sudo rpi-imager --cli raspios.img.xz /dev/sdb

Das Image darf komprimiert sein (seit 2.0.11 auch als mehrteiliges .img.zst), und statt einer lokalen Datei akzeptiert der Imager auch eine HTTP- oder HTTPS-Adresse. Eine Übersicht aller Optionen liefert rpi-imager --cli --help, außerdem bringt das Arch-Paket eine Manpage mit. Die in meinen Augen nützlichsten Optionen:

--sha256 prüft vor dem Schreiben, ob das Image der erwarteten Prüfsumme entspricht.
--disable-verify überspringt die Verifikation nach dem Schreiben (spart Zeit, kostet Sicherheit).
--first-run-script legt ein eigenes firstrun.sh auf das Image.
--cloudinit-userdata und --cloudinit-networkconfig schreiben eigene cloud-init-Konfigurationen mit auf die Karte.
--disable-eject verhindert, dass der Datenträger nach dem Schreiben ausgeworfen wird – praktisch, wenn ihr danach noch Dateien auf die Boot-Partition kopieren wollt.
--quiet gibt nur noch Fehler aus, ideal für Skripte.

Gerade die cloud-init-Optionen sind interessant: Damit habt ihr im Terminal mehr Möglichkeiten als in der grafischen Oberfläche, und das auch für Images, die der Imager im Assistenten nicht mehr anpasst. Für Server ohne Qt-Oberfläche gibt es auf GitHub zudem ein eigenes Paket rpi-imager-cli sowie ein CLI-AppImage, bei denen der Schalter --cli entfällt.

Eigene Image-Listen mit –repo

Noch ein Schmankerl für Bastler, Vereine und Schulen: Mit --repo bringt ihr dem Imager eine eigene Liste von Images bei. Statt die Server von Raspberry Pi abzufragen, liest er dann eine JSON-Datei ein, die entweder im Netz oder lokal auf eurer Platte liegt. Das Format ist im Repository unter doc/json-schema beschrieben.

$ rpi-imager --repo https://example.org/os_list.json

So könnt ihr etwa einem Verein oder einer Schulklasse einen Imager mitgeben, in dem nur die eigenen, vorbereiteten Images auftauchen. Legt euch dafür einfach einen eigenen Starter im Anwendungsmenü an, der den Imager mit dem passenden Parameter aufruft. Den Rest erledigt der Imager dann wie gewohnt.

Telemetrie abschalten

Standardmäßig meldet der Imager bei jedem Schreibvorgang anonym an Raspberry Pi, welches Image ihr ausgewählt habt, dazu die Imager-Version, euer Host-Betriebssystem, die Architektur und die Spracheinstellung. Laut README werden dabei nur Zähler gespeichert, die aggregierten Daten sind öffentlich unter rpi-imager-stats.raspberrypi.com einsehbar.

Wer das trotzdem nicht möchte, schaltet die Statistik in den App-Optionen ab oder startet den Imager einmal mit dem Parameter --disable-telemetry, der die Einstellung dauerhaft speichert. Wie oben erwähnt, ist die Telemetrie beim Flatpak ohnehin nicht einkompiliert. Dort müsst ihr euch also um nichts kümmern.

Häufige Probleme unter Linux

Der Imager meldet, er laufe nicht als Root. Beim AppImage klickt ihr auf Autorisierung installieren oder startet es mit sudo ./…. Bei Distributionspaketen prüft ihr, ob unter /usr/share/polkit-1/actions/ die Datei com.raspberrypi.rpi-imager.policy liegt. Fehlt sie, installiert das Paket neu oder startet den Imager testweise mit sudo.

Das AppImage startet nicht. Prüft zuerst, ob das Ausführbar-Bit gesetzt ist (chmod +x). Unter Ubuntu 24.04 fehlt zudem libxcb-cursor0, ohne das das AppImage direkt beim Start abstürzt. Startet das AppImage testweise im Terminal, dann seht ihr die Fehlermeldung und wisst, welches Puzzlestück noch fehlt.

Ubuntu zeigt die alte Oberfläche. Dann habt ihr die Version aus apt oder dem Snap Store erwischt, die beide noch auf dem Stand von 1.x hängen. Deinstalliert sie und greift stattdessen zum .deb von GitHub, zum AppImage oder zum Flatpak. Danach begrüßt euch auch unter Ubuntu der neue Assistent.

Die SD-Karte taucht nicht auf. Schaut mit lsblk, ob der Kartenleser die Karte überhaupt erkennt. Manche Kartenleser zeigen erst nach erneutem Einstecken ein Gerät an, andere mögen bestimmte Karten schlicht nicht. Taucht die Karte auch in lsblk nicht auf, liegt das Problem nicht beim Imager.

Das Schreiben dauert ewig. Die Verifikation liest das komplette Image nach dem Schreiben noch einmal von der Karte. Bei langsamen Karten oder USB-2-Kartenlesern kann das dauern. Eine schnellere Karte hilft hier mehr als das Abschalten der Prüfung. Schlägt die Verifikation fehl, solltet ihr eure Karte auf Fehler prüfen.

Defekte USB-Sticks oder microSD-Karten. Zeigt der Imager beim Schreiben den Hinweis „Limited by storage device speed“ an, bremst das Speichermedium den Vorgang wesentlich aus. Bei nur wenigen MB/s steckt oft ein altersschwacher Stick oder eine defekte Karte dahinter. Prüft den Datenträger dann auf Fehler, bevor ihr euch über eine abgebrochene Verifikation wundert.

Alternativen zum Raspberry Pi Imager

Natürlich muss es nicht immer der Imager sein. Wer ein Image schon heruntergeladen hat, der kommt unter Linux auch mit Bordmitteln ans Ziel – etwa mit dd, mit der Funktion Laufwerksabbild wiederherstellen in Gnome Disks oder dem GTK4-Tool Impression. Dann fehlt allerdings die komfortable Vorkonfiguration, Hostname, SSH und WLAN richtet ihr von Hand ein.

Wollt ihr umgekehrt ein bestehendes System sichern und das Image möglichst klein halten, dann schaut euch mal PiShrink an. Damit schrumpft ihr ein ausgelesenes Image auf die tatsächlich belegte Größe zusammen und könnt es später wieder mit dem Imager auf eine Karte schreiben.

Besser als dd, aber auch nicht Pflicht

Alles in allem war das Upgrade auf den Raspberry Pi Imager 2.0 in meinen Augen ein klarer Fortschritt. Der Assistent führt auch Einsteiger sicher durch die Einrichtung, und für Linux-User wurde gerade beim Thema Root-Rechte einiges an Gefrickel beseitigt. Arch-User installieren das Programm einfach aus extra und sind fertig.

Ubuntu-User sollten dagegen unbedingt die Paketquellen und den Snap Store links liegen lassen und zum offiziellen Paket greifen. Und wer gerne im Terminal arbeitet, der sollte sich den CLI-Modus mit den cloud-init-Optionen einmal genauer ansehen. Wie bereitet ihr eure SD-Karten vor? Nutzt ihr den Imager oder schwört ihr noch auf dd?

Pulsgeber: TUXEDO-Control-Center-Profile in den GNOME-Schnelleinstellungen

2026-10-05T22:25:18Z

Wer ein Notebook von TUXEDO besitzt, der kennt das TUXEDO Control Center, kurz TCC. Über die grafische App legt ihr fest, wie schnell der Prozessor taktet, wie laut die Lüfter werden dürfen und welches Profil am Netzteil oder im Akkubetrieb gilt. Am besten spielt das Ganze natürlich mit TUXEDO OS zusammen, das genau auf die Geräte von TUXEDO abgestimmt ist.

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

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

Was Pulsgeber macht

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

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

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

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

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

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

Im Video wechsle ich die Profile über die Schnelleinstellungen von GNOME, und das geöffnete TUXEDO Control Center zieht stets mit.

Installation

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

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

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

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

$ gnome-extensions enable pulsgeber@linuxundich.de

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

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

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

Homarr 2.0: Homelab-Dashboard mit Custom Widgets und Workshop

2026-10-03T08:08:33Z

Wer im Homelab ein paar Docker-Container betreibt, braucht früher oder später eine Startseite, die alle Dienste bündelt. Bei mir erledigt das aktuell Homepage, weil es sich so einfach einrichten lässt und viele fertige Widgets mitbringt. Mit Homarr 2.0 schielt nun allerdings ein Konkurrent deutlich in meine Richtung.

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.

Homarr 2.0 in unter zwei Minuten: Das Video der Entwickler zeigt die wichtigsten Neuerungen.

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?