Warum ein Desktop über SSH.
Eine grafische Umgebung auf einem entfernten Server klingt nach einer Lösung auf der Suche nach einem Problem. Hier steht das ehrliche Argument dafür — einschließlich der Fälle, in denen du diese Seite schließen und bei deinem Terminal bleiben solltest.
«Das kann ich alles längst mit ssh und vim»
Kannst du. Wirklich alles auf dieser Seite geht mit einer SSH-Sitzung, einer Shell und einem Editor, den du ohnehin beherrschst. Wenn du einen einzigen Server betreust, in vim zu Hause bist und deine Arbeit in ein Terminal passt — dann ist das hier nichts für dich, und uns ist lieber, du bleibst bei deinem Setup.
Die grafische Schicht ist nicht da, weil das Terminal zu wenig könnte. Sie ist da, weil ein Terminal eine sequenzielle Oberfläche ist und manche Aufgaben nicht sequenziell sind. Eine Übertragung beobachten, während du ein Log liest, während du eine Konfiguration änderst — das sind drei Fenster in jedem Desktop und drei tmux-Panes plus eine Menge Disziplin im Terminal.
Wo sich die grafische Schicht wirklich lohnt
Vier Situationen, angefangen bei denen, die uns am häufigsten begegnen.
- Dateien verschieben — und dabei zusehen. Ein Verzeichnis mit scp von A nach B zu kopieren, gibt dir einen blinkenden Cursor und Hoffnung. Der Explorer macht es mit einer Warteschlange, einer Live-Prozentanzeige je Übertragung und einer Umbenennung statt einer stillen Überschreibung, wenn am Ziel schon etwas mit diesem Namen liegt. Bei 4 GB über eine langsame Leitung ist «läuft das noch?» eine echte Frage.
- Code lesen, den du nicht geschrieben hast. Eine bekannte Datei zu ändern, ist ein Fall für vim. Eine fremde Codebasis zu verstehen — zwischen Dateien springen, einem Include folgen, über einen ganzen Baum suchen — ist ein Fall für einen Dateibaum und Tabs. Genau das gibt dir ein Monaco-Editor auf dem entfernten Dateisystem, ohne dass du lokal irgendetwas auscheckst.
- Auf einem Server landen, den du noch nie gesehen hast. Das ist das stärkste Argument. Termal erkennt, was auf der Maschine läuft — Plesk, cPanel, schlichtes nginx oder Apache —, listet die ausgelieferten Websites mit der PHP-Version auf, unter der jede tatsächlich läuft, zeigt laufende Dienste und Container und findet die Logdateien. Dasselbe Bild von Hand zusammenzutragen heißt ein Dutzend Befehle und zu wissen, wo jede Distribution was versteckt.
- Aus der Netzwerkposition des Servers heraus testen. Eine interne Route, die auf dem Server und sonst nirgends antwortet, ist aus einem Terminal heraus unhandlich zu prüfen. Der HTTP-Client führt curlauf dem Server aus und legt Header und Body sauber aus. Der Browser geht weiter: standardmäßig surft er von deinem eigenen Rechner aus, aber du kannst seinen Netzwerkausgang auf den Server umstellen — der Verkehr läuft dann durch einen SOCKS5-Tunnel über die SSH-Verbindung, die du ohnehin hast, und ein Hinweis in der Werkzeugleiste sagt dir, in welchem der beiden Modi du gerade bist. Mit angedockten Entwicklerwerkzeugen je Tab wird aus einer nur intern erreichbaren Seite etwas, das du anschaust, statt etwas, das du erschließt.
Und das alles über eine Verbindung
Das ist der architektonisch entscheidende Teil, und deshalb ist der Desktop nicht bloß eine Hülle über einem Haufen SSH-Aufrufe.
Termal OS hält einen Pool wiederverwendbarer SSH-Verbindungen — eine pro Server, mit Keepalive, und alles läuft darüber: Metriken, Dateiexplorer, Terminal, Editor, das Mitlesen der Logs. Der Dateimanager öffnet keine zweite Sitzung. Kein zusätzlicher Port, kein Agent, keine zweite Authentifizierung, nichts, was auf der Maschine installiert wird. Aus Sicht des Servers bist du ein einzelner SSH-Login, der gewöhnliche Dinge tut.
Genau diese Beschränkung sorgt auch dafür, dass der Desktop auf Hosting funktioniert, wo du weder root bist noch etwas installieren darfst — Shared Hosting, verwaltetes Hosting, die Maschine eines Kunden. Ein grafisches Admin-Panel, das einen Daemon bräuchte, wäre dort nutzlos.
Was tatsächlich im Desktop steckt
Ein Fenstermanager mit Taskleiste, Startmenü und Symbolen auf dem Desktop — und 23 Anwendungen. Die, die die Arbeit machen:
- Explorer — SFTP-Explorer: kopieren, verschieben, hochladen, einen Ordner als Archiv herunterladen, Rechte, Drag and Drop, Übertragungswarteschlange mit Fortschritt.
- Terminal — eine echte PTY-Shell, kein Kästchen zum Absetzen von Befehlen.
- Termal Code — Monaco (der Editor aus VS Code) mit Dateibaum und Tabs, Bearbeitung direkt auf dem entfernten Dateisystem.
- Browser — mehrere Tabs, Lesezeichen, Downloads, Quelltextansicht und Entwicklerwerkzeuge je Tab.
- Monitor, Prozesse, Logs — Live-Metriken, eine Prozessliste, aus der du Prozesse beenden kannst, und Log-Mitlesen mit automatischem Finden der üblichen Dateien von Apache, nginx, PHP, MySQL und syslog.
- Web-Anfrage, Zip, Git, FTP, Papierkorb — die kleinen Werkzeuge, die dich sonst mitten in der Arbeit zurück in die Shell schicken.
- Copilot — Fragen in normaler Sprache, beantwortet mit einem Befehl und einer Erklärung. Nichts läuft, bevor du klickst, und alles über deinen eigenen API-Schlüssel.
Dazu kommen ein Mail-Programm, Notizen, ein Taschenrechner, ein Umrechner, eine Farbpipette und ein paar Spiele. Dreizehn der dreiundzwanzig sind standardmäßig aus — dauerhaft da sind nur App Store, Einstellungen, Explorer und Papierkorb —, denn ein erster Start, der den Dateiexplorer unter einem Spielemenü begräbt, wäre selbst schon ein Argument gegen die ganze Idee. Schalt ein, was du benutzt.
Der Teil, den Entwickler sich ansehen sollten
Der Desktop ist erweiterbar, und das Erweiterungsmodell ist das Interessanteste an der Codebasis.
Eine Fremdanwendung läuft in einem abgeschotteten iframe. Sie kommt weder an das Dateisystem noch an das Netzwerk oder die Zwischenablage direkt heran. Jeder privilegierte Aufruf geht als Nachricht an den Host, der ihn gegen die Rechte prüft, die die Anwendung in ihrem Manifest deklariert hat — und davon gibt es nur sechs: fs.read, fs.write, net, storage, clipboard, webview. Sie werden dir bei der Installation gezeigt. Die Regel im Kopfkommentar der Laufzeitumgebung selbst ist unmissverständlich: dem iframe wird nie vertraut, der Host prüft alles.
Das wiegt hier schwerer als in den meisten Plugin-Systemen, denn diese Anwendungen laufen gegen Server, für die du SSH-Zugang erteilt hast. Ein App Store, in dem ein Plugin still deine Schlüssel lesen könnte, wäre nicht zu rechtfertigen.
Und das SDK ist keine separate, abgespeckte API, die man für Außenstehende drangeschraubt hat: der eingebaute Taschenrechner wird über Termal.app() registriert — denselben öffentlichen Einstiegspunkt, den eine Fremdanwendung benutzt. Acht vollständige Beispielanwendungen liegen dem SDK bei, von einer Notiz-App über einen Webview-Container bis zu einem Server-Widget.
Die vollständige Referenz — Manifest, Laufzeitumgebung, Dialoge, Dateiauswahl, Speicher, Netzwerk, Webview, Zwischenablage, Fenstersteuerung, Übersetzungen, Paketierung — steht auf der Seite zum Termal App Studio.
Was es nicht ist
- Kein Ersatz für dein Terminal. Es enthält eins, und du wirst es benutzen. Wenn deine Arbeit ohnehin in eine Shell passt, bringt dir der Desktop nichts, was du bräuchtest.
- Kein Remote-Desktop-Protokoll. Kein X11, kein VNC, kein RDP und kein Displayserver auf deiner Seite der Leitung. Der Fenstermanager läuft lokal in der App; über die SSH-Verbindung gehen nur Datei-, Shell- und Metrikverkehr.
- Nicht dauerhaft im Betrieb. Die Erfassung läuft bei geschlossenem Fenster weiter, aber die Anwendung muss auf einem Rechner laufen, der wach ist. Klapp den Laptop zu, und sie hört auf — siehe den Vergleich mit Netdata, wo das am meisten wiegt.
- Nicht für tausend Server. Ein paar bis ein paar Dutzend. Nur Linux über SSH: kein SNMP, kein Windows, keine Netzwerkerkennung.