SCD-Deck: drei Desktop-Decks für Linux Mint – und warum sie Befehle nur kopieren

Das Problem#

Auf meinem Linux-Arbeitsrechner landen ständig Befehle, die ich brauche, aber nicht auswendig kenne: ein Diagnose-Befehl für den Netzwerkzustand, ein Git-Kommando für einen bestimmten Workflow, ein Docker-Aufruf für ein Projekt. Bisher lief das so: ich google nach dem Befehl, kopiere ihn, füge ihn ins Terminal ein und passe die Parameter an.

Daraus entstand die Idee: nicht mehr google, sondern nachschlagen. Und zwar so, dass die Befehle da sind, wo ich ohnehin arbeite – am Bildschirmrand, nicht in einem Terminal, das ich erst öffnen muss.

Die Architektur#

Drei eigenständige Desktop-Decks, die sich bewusst nicht in ein App-Grid, ein Dock oder eine Startmenü-Integration einordnen. Sie schweben am Bildschirmrand und tun genau das, wofür sie gebaut wurden.

Deck	Aufgabe	Befehle
System Deck	liest und diagnostiziert Zustand, ohne Shell und ohne sudo	121 Befehle in 17 Kategorien
Command Deck	kopiert Befehle, führt sie aber nie aus	93 Befehle in 8 Kategorien
Daily Deck	öffnet Programme, Pfade, SSH und Medien	36 Befehle in 6 Kategorien

Inhaltlich decken sie System, Hardware, Speicher, Netzwerk und Sicherheit ab, dazu Git, Node, Docker und Deploy, Programme, Verzeichnisse, SSH und Medien.

Die Entscheidungen, die alles bestimmt haben#

Python 3 und GTK3 als Systempakete#

Beide kommen aus der Distribution, beide brauchen keine zusätzliche Installation. Damit gibt es keine pip install-Ketten, die nach einem Update brechen, und keine Abhängigkeiten, die ich später nachpflegen muss. Für ein Werkzeug, das ich täglich nutze, ist das der Unterschied zwischen „ich benutze es" und „ich muss es erst reparieren".

Befehle kopieren statt ausführen#

Der entscheidende Schritt. Das Command Deck gibt einen Befehl zum Kopieren aus, führt ihn aber nicht aus. Kein Shell-Aufruf, kein sudo, kein Netzwerkzugriff aus dem Programm heraus. Ein System-Deck, das Befehle sammelt und anzeigt, ist ein Werkzeug; ein System-Deck, der Befehle ausführt, ist ein Werkzeug mit offener Tür für Fehlbedienung. Ich wollte die kleinere Variante.

Für alles, was Diagnose erfordert, liest und misst das System Deck direkt – ohne eine Shell zu starten. Damit bekommt man den Zustand, ohne jemanden zu erlauben, beliebig etwas zu tun.

Ortsunabhängigkeit#

Jedes Deck ermittelt seinen eigenen Pfad. Kein Installationsverzeichnis, kein $PATH-Eintrag, keine fest kodierten Pfade. Ein Deck lässt sich kopieren, verschieben oder vom USB-Stick starten und funktioniert.

Backup vor dem Überschreiben#

Jeder Installer legt vorher ein Backup an und überschreibt nichts. Bei einem Werkzeug, das man täglich benutzt und gern selbst anpasst, ist das keine Feinheit, sondern Bedingung.

Was ich dabei gelernt habe#

Die richtige Menge an Funktionalität ist eine Designentscheidung. Der Umfang ist deshalb in Kategorien und Befehlszahlen sortiert, weil 250 Befehle in einer flachen Liste nicht nutzbar wären. Erst die Gliederung macht ein Nachschlagewerk.

Systempakete sind eine unterschätzte Architekturentscheidung. „Keine externe Abhängigkeit, keine installierten Pakete“ klingt nach Verzicht. Tatsächlich ist es Robustheit.

Sicherheit ist hier billig. Kein Shell, kein sudo, kein Netz – das sind drei Zeilen in den Anforderungen und ein großer Unterschied im Fehlerfall.

Grenzen und offene Punkte#

Ehrlich dazugesagt: Ein solches Werkzeug ist plattformgebunden. Es läuft unter Linux Mint und ist auf andere Oberflächen nicht ohne Anpassung übertragbar. Der Umfang ist außerdem bewusst auf System-Diagnose und Entwicklerbefehle beschränkt – für fachliche Prozesse aus anderen Domänen ist es nicht gedacht.

Für wen das nicht gedacht ist#

Für alle, die ein Werkzeug wollen, das selbstständig „repariert“. Dafür ist es nicht gebaut. Wenn du eine Anwendung brauchst, die in deinem Umfeld selbst aktiv wird – Anlagen verwalten, Bestände führen, Prozesse abbilden –, ist das eine andere Aufgabe als ein Nachschlagewerk. Dafür gibt es den Weg über die Haas-Arts-Website.