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

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

Microsoft entdeckt den Linux-Desktop

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

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

Was der Defender auf dem Linux-Desktop kann

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

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

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

Für wen ist das Ganze gedacht?

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

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

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

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

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

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

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

Plasma 6.8: Tschüss, X11

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

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

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

KDE: The Documentary

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

Video wird erst nach Klick von YouTube geladen.

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

Spenden zum Geburtstag

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

KDE und ich

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

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

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

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

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

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

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

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

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

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

Wer wird gesucht?

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

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

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

Räusper. Ich auch.

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

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

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

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

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

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

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

Jetzt läuft, mit Liedtext

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

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

Alle Räume an einem Ort

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

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

Die ganze Musiksammlung

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

Teil des GNOME-Desktops

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

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

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

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

Installation

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

flatpak install --user gnomos-*.flatpak

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

Noch nicht fertig

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

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

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

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.

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.

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?

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

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

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

Was Pulsgeber macht

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

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

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

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

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

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

Installation

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

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

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

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

$ gnome-extensions enable pulsgeber@linuxundich.de

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

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

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

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

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.

llmfit nimmt euch diese Recherche ab. Das Open-Source-Tool liest die vorhandene Hardware aus und stellt sie einer Datenbank mit Sprachmodellen gegenüber. Heraus kommt eine ziemlich konkrete Antwort darauf, was auf der eigenen Maschine überhaupt sinnvoll laufen kann.

Welche Modelle passen zu meiner Hardware?

Nach dem Start erfasst llmfit zunächst die eigene Hardware: Prozessor, Arbeitsspeicher, Grafikkarte und verfügbarer VRAM. Anschließend stellt das Programm die vorhandenen Ressourcen den unterstützten Modellen gegenüber und sortiert die Liste nach einem Score.

Praktisch ist das vor allem deshalb, weil nicht nur die reine Modellgröße zählt. Ein Modell kann theoretisch in den vorhandenen Speicher passen und in der Praxis trotzdem quälend langsam laufen. llmfit schätzt deshalb ab, wie gut ein Modell zur Hardware passt und welche Geschwindigkeit beziehungsweise welcher Speicherbedarf zu erwarten ist.

Wie sehr sich das je nach Rechner unterscheidet, sieht man schon an zwei Geräten aus meinem Fundus. Auf dem Notebook mit dedizierter GTX 1050 sind die 4 GByte VRAM die harte Grenze. Auf einem Rechner mit Iris-Xe-Grafik teilen sich Prozessor und Grafikeinheit dagegen denselben Speicher – plötzlich steht fast überall „Perfect“.

Dabei berücksichtigt das Programm auch unterschiedliche Quantisierungen. Gerade bei lokal betriebenen Modellen landet man schnell bei Begriffen wie Q4, Q5 oder Q8. Vereinfacht gesagt wird dabei die Genauigkeit der Modellgewichte reduziert, um Speicherplatz und Rechenleistung zu sparen. Dafür muss man je nach Stufe gewisse Einbußen bei der Qualität in Kauf nehmen.

Relevant ist das vor allem bei GGUF-Modellen, die bei lokaler Inferenz häufig zum Einsatz kommen. llmfit bezieht die verschiedenen Quantisierungsstufen in seine Bewertung ein und kann dadurch auch Modelle vergleichen, die in mehreren Varianten vorliegen.

Wer sich unter Linux bisher mit Werkzeugen wie Inxi einen Überblick über die eigene Hardware verschafft hat, kennt das Prinzip bereits. llmfit geht allerdings einen Schritt weiter und setzt die ermittelten Daten direkt in Beziehung zu möglichen KI-Modellen.

Installation unter Arch Linux

Update 29.09.2026: Das Rad der Zeit dreht sich konstant, und bei Arch dreht es sich bekanntlich immer ein wenig schneller. Als ich mit dem Schreiben des Artikels angefangen habe, gab es für Arch ein AUR-Paket von llmfit. Aufgrund der Turbulenzen und Angriffe auf das AUR versuche ich es inzwischen jedoch zu meiden.Inzwischen ist das llmfit-Paket in den offiziellen Arch-Paketquellen angekommen. Zur Installation genügt daher: sudo pacman -S llmfit

Unter Arch Linux liegt uv direkt in den offiziellen Paketquellen. Die Installation ist damit erfreulich unspektakulär:

sudo pacman -S uv

Anschließend lässt sich llmfit mit uv als Tool installieren:

uv tool install -U llmfit

Danach steht llmfit direkt als Kommando zur Verfügung.

Wer das Programm zunächst nur ausprobieren möchte, kann alternativ uvx verwenden. Dabei wird llmfit ausgeführt, ohne es dauerhaft als Tool zu installieren:

uvx llmfit

Damit ist unter Arch Linux also kein zusätzlicher Installer für uv notwendig.

Installation unter Ubuntu

Unter Ubuntu ist der Weg etwas anders. Hier lässt sich uv je nach Ubuntu-Version und verwendeten Paketquellen nicht einfach über apt installieren. Der von den uv-Entwicklern bereitgestellte Installer ist daher eine unkomplizierte Möglichkeit.

Mit curl geht das so:

curl -LsSf https://astral.sh/uv/install.sh | sh

Alternativ lässt sich das Installationsskript mit wget herunterladen und ausführen:

wget -qO- https://astral.sh/uv/install.sh | sh

Danach solltet ihr zunächst prüfen, ob uv verfügbar ist:

uv --version

Anschließend funktioniert die Installation von llmfit genauso wie unter Arch Linux:

uv tool install -U llmfit

Zum Ausprobieren ohne dauerhafte Installation steht auch unter Ubuntu uvx zur Verfügung:

uvx llmfit

Wer uv nicht verwenden möchte, kann alternativ die fertigen Binärdateien aus den GitHub Releases von llmfit herunterladen.

llmfit wieder loswerden

Falls euch das Werkzeug doch nicht überzeugt: Der Weg zurück ist kurz, hat unter Arch aber einen Haken. Das Tool selbst verschwindet mit

uv tool uninstall llmfit

und ob noch etwas übrig ist, verrät

uv tool list

Wer llmfit nur mit uvx ausprobiert hat, hat ohnehin nie etwas dauerhaft installiert. Die heruntergeladenen Pakete liegen dann trotzdem im Cache von uv. Den leert ihr mit

uv cache clean

Und jetzt zum Haken: Wer uv über die Paketverwaltung installiert hat, ist versucht, einfach

sudo pacman -Rns uv

zu tippen. Pacman räumt dabei aber nur das eigene Paket ab. Was uv selbst im Heimatverzeichnis angelegt hat, kennt die Paketverwaltung nicht – und ohne uv lässt sich uv tool uninstall auch nicht mehr aufrufen. Deinstalliert also erst das Tool und dann uv, nicht umgekehrt.

Wo die Reste liegen, zeigen euch

uv tool dir
uv cache dir

Üblicherweise sind das ~/.local/share/uv/tools und ~/.cache/uv. Ist uv schon weg und llmfit noch da, bleibt nur das Aufräumen von Hand:

rm -r ~/.local/share/uv

Vorsicht dabei: Damit fliegen alle mit uv installierten Tools und die von uv verwalteten Python-Versionen mit raus, nicht nur llmfit.

Unter Ubuntu, wo uv über das Installationsskript kommt, gibt es kein uv self uninstall. Dort räumt ihr nach dem uv tool uninstall die beiden Startprogramme selbst weg:

rm ~/.local/bin/uv ~/.local/bin/uvx

Die TUI ist mehr als eine einfache Modellliste

Die Terminal-Oberfläche ist für mich einer der interessanteren Teile von llmfit. Statt nur eine Liste auszugeben, kann man sich durch die Ergebnisse bewegen, suchen und zu jedem Modell weitere Informationen abrufen.

Mit / sucht ihr nach einem bestimmten Modell, die Pfeiltasten beziehungsweise j und k dienen zur Navigation, und h öffnet die Hilfe. Bei knapp 10.000 Einträgen in der Liste ist die Suche tatsächlich kein Luxus.

Interessant sind außerdem die integrierten Benchmark-Funktionen. Mit b lassen sich Community-Benchmarks aufrufen, während I einen Inference-Benchmark mit der eigenen Hardware startet. Damit wird aus einer reinen Schätzung langsam eine Messung mit echten Werten.

Das erinnert ein wenig an klassische Systemwerkzeuge. Wer beispielsweise Mission Center unter GNOME nutzt, bekommt dort CPU, RAM, GPU und weitere Ressourcen grafisch präsentiert. llmfit schaut dagegen gezielt auf die Frage, was sich mit diesen Ressourcen an lokaler KI anfangen lässt.

Schätzwerte statt Marketing-Versprechen

Natürlich sollte man die Angaben von llmfit nicht mit einem echten Benchmark verwechseln. Eine theoretische Berechnung kann nur abschätzen, wie schnell ein bestimmtes Modell auf einer bestimmten Hardware laufen könnte.

Ganz nett ist in dem Zusammenhang die Hardware-Simulation. Damit dreht man testweise an RAM, VRAM und Kernanzahl und sieht, wie sich die Bewertung verschiebt. Wer mit dem Gedanken an einen Speicherriegel oder eine neue Grafikkarte spielt, bekommt so zumindest eine Hausnummer.

Genau deshalb sind die mittlerweile integrierten Benchmarks interessant. llmfit kann ein Modell herunterladen, es über einen unterstützten Runtime-Provider starten und anschließend die tatsächliche Geschwindigkeit auf der eigenen Hardware messen. Die Ergebnisse werden lokal gespeichert.

Wer möchte, kann seine Messwerte anschließend über

llmfit bench --share

mit der Community teilen. Die Ergebnisse werden dabei als GitHub Pull Request eingereicht. Auf diese Weise entsteht nach und nach eine Datenbasis aus echten Messungen und nicht nur aus theoretischen Berechnungen.

Gerade bei lokaler KI finde ich diesen Ansatz sinnvoll. Denn die Angabe „passt in den VRAM“ sagt noch nicht besonders viel darüber aus, ob man mit dem Modell tatsächlich vernünftig arbeiten kann.

Auch als Kommandozeilenwerkzeug nutzbar

Wer mit einer TUI wenig anfangen kann, muss llmfit nicht interaktiv bedienen. Das Programm lässt sich auch komplett über die Kommandozeile verwenden.

Zum Beispiel liefert

llmfit recommend

eine Empfehlung für die vorhandene Hardware. Mit

llmfit recommend --json

lassen sich die Ergebnisse als JSON ausgeben. Das ist natürlich deutlich interessanter, wenn ihr llmfit in eigene Skripte oder andere Werkzeuge einbauen wollt.

Auch ein Webinterface beziehungsweise eine API lässt sich starten:

llmfit serve --host 0.0.0.0 --port 8787

Für Container gibt es außerdem ein fertiges Image:

ghcr.io/alexsjones/llmfit

Damit läuft llmfit beispielsweise auch auf einem Server oder in einer bestehenden Docker-Umgebung. Wer seine Container regelmäßig aktuell hält, kennt das Spiel vielleicht schon von Dockcheck.

Und womit läuft das Modell dann?

Eine Unterscheidung solltet ihr dabei im Hinterkopf behalten: llmfit ist selbst keine KI-Runtime. Das Programm hilft bei Auswahl und Bewertung eines Modells, die eigentliche Inferenz erledigen andere Werkzeuge.

Unterstützt werden unter anderem Ollama, llama.cpp, MLX, Docker Model Runner und LM Studio. Dadurch kann llmfit beispielsweise ein Modell über einen vorhandenen Ollama- oder llama.cpp-Stack benchmarken.

Für Linux ist Ollama sicherlich eine der einfacheren Möglichkeiten, lokale Modelle zum Laufen zu bekommen. Wer mehr Kontrolle über die eigentliche Inferenz haben möchte, landet dagegen schnell bei llama.cpp. Beide Projekte verfolgen etwas unterschiedliche Ansätze, lassen sich aber gut mit dem Hardware-Check von llmfit kombinieren.

Interessant für lokale KI

llmfit schließt für mich eine Lücke zwischen „Ich möchte lokale KI ausprobieren“ und „Ich muss mich erst einmal durch die Hardwareanforderungen von dutzenden Modellen arbeiten“. Das ist deutlich hilfreicher als eine allgemeine Liste der „besten“ lokalen Modelle. Denn am Ende zählt nicht, welches Modell auf irgendeinem Testsystem gut abschneidet, sondern welches auf eurer Hardware mit eurem Anwendungsfall vernünftig funktioniert.

Die Schätzungen ersetzen natürlich keinen eigenen Test. Genau dafür sind die integrierten Benchmarks da, und die will ich mir als Nächstes vornehmen: eigene Messungen auf verschiedenen Geräten, und dann der Abgleich, wie gut die Vorhersagen von llmfit mit der Realität zusammenpassen.

Gerade für Entwickler dürfte das Werkzeug interessant sein. Wer einen lokalen KI-Assistenten zum Programmieren einsetzen möchte, findet zuerst heraus, welche Modelle zur vorhandenen Hardware passen, und experimentiert anschließend mit den tatsächlich erreichbaren Geschwindigkeiten.

Weitere Informationen, die aktuelle Dokumentation und den Quellcode findet ihr auf GitHub.

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