Kitty Coziness

Bitmap-Fonts sind gestochen scharf, und keine Vector-Schrift kommt da heran. Kitty ist mein liebster Terminal-Emulator — nur sein Maintainer will Bitmap-Fonts partout nicht unterstützen. Also habe ich einen alten AUR-Patch nach Nix portiert und auf eine aktuelle Kitty-Version gehoben: ein Override, das den Python-Matcher zum Opt-in überredet und die Zell-Metriken aus dem Strike statt aus font-units rechnet. Dazu fontconfig-Pinning, damit Cozette deterministisch auf den 13px-Strike auflöst.

Ich liebe Bitmap-Fonts. Nicht aus Nostalgie, sondern weil sie auf meinem Display schlicht besser aussehen: gestochen scharf, jedes Pixel von Hand gesetzt, kein Antialiasing-Matsch, keine Sub-Pixel-Lotterie. Bei der richtigen Größe ist eine gute Bitmap-Schrift in einem Terminal so ruhig und lesbar, dass keine Vector-Font dagegen anstinken kann — die muss bei kleinen Pixelgrößen immer raten, wo die Kante hin soll, und rät selten so gut wie ein Mensch, der den Glyph Pixel für Pixel hingelegt hat. Meine Lieblingsschrift ist Cozette : eine 13px-Bitmap im Geist von Tamzen und Creep, kompakt, mit großem Unicode-Block.

Ein CI-Broker für Radicle, der wirklich baut — die Reise durch jede Wand

Vor zwei Wochen stand der Plan: ein CI-Broker, der auf Patch-Events meiner Radicle-Seed-Node hört, in-cluster baut und signiert. Das Diagramm war sauber. Die Realität war ein wochenlanger Kampf mit cib-Entrypoints, Flux, das meine Shell-Variablen auffraß, stale :latest-Tags, rootless buildah, das in Kubernetes prinzipiell nicht geht, und einem binfmt_misc-Handler, der auf Kernel 6.x immer wieder verschwand. Hier ist jede Wand, gegen die ich gelaufen bin — und wie der Broker am Ende doch baut.

In Radicle CI — eine Pipeline, die auf Patches reagiert habe ich den Plan beschrieben: Meine Seed-Node läuft in-cluster und führt einen Event-Stream — jede neue Patch-Ref, jedes COB-Update wird sichtbar. Ein CI-Broker abonniert diesen Stream, übersetzt ein Patch-Event in einen Build und schreibt das Ergebnis zurück auf den Patch. Sauberes Diagramm, klare Idee, ein offenes Trust-Problem, das ich für lösbar hielt.

Was dieser Beitrag erzählt, ist die Lücke zwischen dem Diagramm und einem grünen Häkchen. Sie war größer, als mir lieb war. Zwischen „der Broker ist deployt" und „der Broker baut wirklich ein signiertes Image" lagen rund zwei Dutzend Commits, die fast alle fix: heißen — und jeder davon steht für eine Wand, gegen die ich gelaufen bin. Das hier ist die ehrliche Version: kein Architektur-Pitch, sondern ein Reisebericht durch Entrypoints, die nicht stimmen, durch Flux, das meine Shell-Variablen frisst, durch rootless buildah, das in Kubernetes prinzipiell nicht funktioniert, und durch einen Kernel, der meinen QEMU-Handler immer wieder vergaß.

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.