choom: Terminal-Sharing à la tmate, aber schlank — und auf dem Weg zu E2E

tmate ist genial und gefährlich zugleich: ein voller tmux-Fork in ~50k Zeilen C, der auf dem Relay als root läuft. Vor einer Weile habe ich eine schlanke Python-Reimplementierung gebaut, die nur den Sharing-Kern behält. Jetzt habe ich sie nach Rust portiert — eine einzige statische ~4-MB-Binary, unprivilegiertes SSH-Relay, kompromisslos auf Sicherheit getrimmt. Was choom kann, wie man meinen öffentlichen Server choom.sh nutzt, warum „trust the operator" bauartbedingt gilt — und wie ein E2E-Client das aufbricht.

Es gibt diesen einen Moment beim Remote-Support, den jeder kennt: Jemand sitzt vor einem kaputten Terminal, beschreibt am Telefon umständlich, was auf dem Schirm steht, und tippt dann doch wieder das Falsche. Was ich in dem Moment will, ist keine 478-MB-Electron-Bildschirm-Sharing-Software — ich will sein Terminal sehen, am besten mitschreiben können, und zwar in dem Augenblick, in dem es brennt. Genau dafür gibt es tmate . tmate ist großartig. tmate ist aber auch ein Stück Software, dem ich nicht mehr blind vertrauen wollte. Dieser Beitrag erzählt, warum ich mir stattdessen mein eigenes Werkzeug gebaut habe — choom1 —, was es kann, wie man es benutzt, und wo seine ehrliche Grenze liegt.

ZeroClaw 0.7.5 → 0.8.0: Das Upgrade, das den `<tool_call>`-Spam beendet hat

Eine schwierige, brechende Pre-1.0-Migration: Schema V3, Multi-Agent-Runtime und ein neues On-Disk-Layout — angetrieben von einem einzigen, hartnäckigen Bug. Mein KI-Agent kippte rohe <tool_call>-Blöcke in Matrix, die nie ausgeführt wurden. Warum v0.8.0 der eigentliche Fix war, was alles dabei zerbrach und welche drei Fehler erst zur Laufzeit auftauchten.

In meinem Lab läuft seit Wochen ein KI-Agent mit — ZeroClaw , im Chat nur Claw —, der die Cluster überwacht, mir auf Matrix Bescheid gibt und Reparaturen als Radicle-Patches vorschlägt statt sie selbst durchzudrücken. Über genau einen Bug bin ich dabei so lange gestolpert, dass er mich am Ende zu einer der unangenehmsten Migrationen des ganzen Setups getrieben hat: dem Sprung von v0.7.5 auf v0.8.0. Das ist ein brechendes Pre-1.0-Release — ein von Grund auf neu geschriebenes Config-Schema, eine Multi-Agent-Runtime und ein neues On-Disk-Layout. Dieser Beitrag erzählt, warum ich diese Migration trotzdem unbedingt wollte, was dabei alles zerbrochen ist und welche Fehler mir erst zur Laufzeit um die Ohren geflogen sind.

Das Lab wird multi-cluster — wiederholbar föderiert, ehrlich evaluiert

Aus einem handverdrahteten Cluster plus Wegwerf-Test wurde ein wiederholbares Muster: ein Cluster pro Befehl, Apps im cluster-scope, Flux-Tenants, eine aufgeräumte Headscale-Domain — und Föderation statt Node-Mesh. Inklusive der ehrlichen Vorgeschichte (warum ClusterMesh rausflog), einer nüchternen Stabilitäts-Bewertung und dem, was als Nächstes fällig ist: Monitoring, Alerting, Backup und HA für die Föderations-Wurzel.

Die letzten Tage im Lab waren ein Strukturschnitt. Lange gab es genau einen ernsthaften Cluster — hydra, bare-metal — und daneben einen Wegwerf-Test, von dem die ClusterMesh-Episode erzählte. Inzwischen ist daraus ein wiederholbares Muster geworden: ein Cluster pro Befehl, Anwendungen im cluster-scope, Flux-Tenants, eine aufgeräumte Tailnet-Domain — und eine Föderation, die bewusst kein Pod-Mesh ist. Dieser Beitrag fasst die Änderungen zusammen, spricht ehrlich über die Probleme dahinter und bewertet, wie produktionstauglich das Ganze wirklich ist.

fr0st — mein NixOS-Flake von der Wurzel bis zum Wallpaper

Sechs Maschinen, zwei Betriebssysteme, ein Repository: fr0st ist mein persönliches flake-parts-Flake, das ThinkPads, einen Desktop, ein MacBook und VMs aus derselben Quelle deklariert. Eine ausführliche Tour durch die Architektur — die lib.system-Fabrik, die rekursive Modul-Discovery mit eigenem Options-Namespace, die Profile-Komposition, das Single-User-Identitätsmodell, Secure Boot via Lanzaboote, verschlüsselte Roots via disko, Remote-Installs mit nixos-anywhere, das SOPS-Schlüsselregister, eigene Pakete und Overlays, und am Ende der Desktop, den das alles ergibt.

Mein Lab ist ein GitOps-Monorepo, aus dem Flux Kubernetes-Cluster reconciled. Aber die Maschinen, von denen aus ich auf dieses Lab schaue — die ThinkPads, der Desktop, das MacBook, ein paar VMs —, haben ihre eigene deklarative Wurzel. Sie heißt fr0st, ist ein flake-parts -Flake, und dieser Beitrag nimmt sie von der Wurzel bis zum Wallpaper auseinander.

Frost auf dem Asphalt, der graue Himmel vor dir

Das Repo ist öffentlich über meinen Radicle -Seed-Node erreichbar:

1# klassisch:
2git clone https://seed.this-is-fine.io/zVi9VheaDwbEgCUQUQ9sLwpHuaMo.git ~/.config/nix
3# oder via Radicle:
4rad clone rad:zVi9VheaDwbEgCUQUQ9sLwpHuaMo

Stöbern lässt es sich im Web unter radicle.network/nodes/seed.this-is-fine.io .

Eine Postgres-Plattform statt zehn Datenbanken — CloudNativePG im Lab

Synapse, Mastodon, Harbor, Pocket-ID, Headscale: fast jeder zustandsbehaftete Dienst im Lab will Postgres. Früher hieß das zehn handgepflegte Datenbanken. Heute ist es ein Operator und pro Dienst ein dreizeiliges Cluster-Manifest — mit synchroner Replikation über drei Instanzen, VolumeSnapshot-Backups, automatischem Failover und Prometheus-Metriken out of the box. Wie CloudNativePG aus einer Bürde eine Plattform macht.

Wenn ich die zustandsbehafteten Dienste in meinem Lab durchgehe, fällt ein Muster auf: Synapse , Mastodon , Harbor, Pocket-ID , Headscale — sie alle wollen Postgres. Früher bedeutete das eine Handvoll handgepflegter Datenbanken, jede mit eigener Backup-Logik, eigenem Failover-Plan (also keinem) und eigener Überwachung (auch keiner). Heute ist Postgres in meinem Lab eine Plattform: ein Operator, und pro Dienst ein winziges deklaratives Cluster-Manifest. Das ist CloudNativePG .