Ein Desktop für eine Person
(isene.org)- Nach 25 Jahren wurden die meisten Alltagsprogramme durch selbst entworfene Werkzeuge ersetzt; Erweiterungen und Bugfixes wurden an Claude Code delegiert, wodurch bisherige Universal-Tools nach und nach ersetzt wurden
- Die gesamte Umgebung ist in eine Basis auf CHasm aufgeteilt, die ohne libc in reinem x86_64-Assembler Pixel und Tastatureingaben verarbeitet, sowie in Fe₂O₃ als Rust-Anwendungsschicht auf crust
- In der CHasm-Schicht wurden i3-wm durch tile, kitty durch glass, zsh und rsh durch bare sowie less durch show ersetzt
- In der Fe₂O₃-Schicht wurde VIM, das 25 Jahre lang genutzt wurde, innerhalb von 72 Stunden nach dem ersten Commit durch scribe ersetzt; auch Dateimanager, E-Mail, RSS, Kalender, Astronomie-Panel und Film-Tools wurden durch Werkzeuge ersetzt, die zum persönlichen Workflow passen
- BYOS (Build Your Own Software) ist dank Rust, Claude Code und gut dokumentierter TUI-Programmierprobleme zu einer realistischeren Option geworden, sodass sich passgenaue Werkzeuge für eine Person im Wochenendtakt austauschen lassen
Eine selbst gebaute Desktop-Umgebung
- Zum ersten Mal seit 25 Jahren wurden fast alle Alltagsprogramme durch selbst entworfene Werkzeuge ersetzt
- Die bisherigen Universal-Tools wurden nicht auf einmal komplett ausgetauscht, sondern nach und nach einzeln durch besser passende Alternativen ersetzt
- Die Entwicklung erfolgte, indem Erweiterungen und Bugfixes an Claude Code delegiert wurden: kurze Anweisungen geben, währenddessen etwas anderes tun und anschließend das Ergebnis übernehmen
- Die gesamte Umgebung ist in zwei Schichten aufgeteilt
CHasm-Schicht: Assembler-basierte Werkzeuge
- Der Fenstermanager wurde von i3-wm auf tile umgestellt
- Statusleiste und Tray wurden von i3bar und conky auf strip und asmites umgestellt
- Die Bildschirmsperre wurde von i3lock auf bolt umgestellt
- Der Terminal-Emulator wurde von kitty auf glass umgestellt
- Die Login-Shell wurde über zsh und rsh schließlich zu bare
- Der Dateibetrachter wurde von less auf show umgestellt
Fe₂O₃-Schicht: Werkzeuge auf Basis von Rust und crust
- Der Texteditor wurde von VIM auf scribe umgestellt
- Der Dateimanager wurde über ranger und RTFM schließlich zu pointer
- E-Mail, RSS und Chat wurden von mutt, newsbeuter und verschiedenen Web-Logins auf kastrup umgestellt
- Der Kalender wurde von Google und MS im Web auf tock umgestellt
- Das Astronomie-Panel wurde von astropanel auf astro umgestellt
- Das Tool für Filme und Serien wurde von IMDB-terminal auf watchit umgestellt
- Als externe Werkzeuge bleiben bislang nur WeeChat für IRC und andere Chats sowie Firefox als einziges regelmäßig genutztes GUI-Programm
scribe ersetzte VIM in 72 Stunden
- vim war seit 2001 über 25 Jahre hinweg das Kernwerkzeug für E-Mails, Texte, Blogbeiträge, Code, HyperList und das Schreiben von Büchern
- Das Muskelgedächtnis war so tief verankert, dass selbst in beliebigen Texteingabefeldern im Browser
:weingegeben wurde - Der erste Commit von scribe erfolgte am 1. Mai um 00:09, und am Nachmittag des 3. Mai hatte es vim ersetzt
- scribe ist wie vim ein modaler Editor, entfernt aber 90 % der nie genutzten Funktionen und enthält nur Features, die auf den persönlichen Workflow zugeschnitten sind
- standardmäßiges Soft-Wrapping
- ein fokussierter Lesemodus im Stil von Limelight
- KI direkt im Prompt, ohne den Buffer zu verlassen
- HyperList-Bearbeitung mit vollständigem Syntax-Highlighting
- Unterstützung für das Verschlüsselungsformat der Ruby HyperList app
- persistente Register, die zwischen gleichzeitigen Sitzungen geteilt werden
- Es sind keine revolutionären Funktionen, aber alle sind exakt auf den persönlichen Workflow abgestimmt
- Früher musste man, selbst wenn die gewünschte Funktion klar war, Monate, Jahre oder vielleicht für immer darauf warten, dass ein anderer Entwickler dieselbe Idee hatte und sie in ein Tool einbaute; jetzt ist die gewünschte Verbesserung nur noch Minuten entfernt
Die Kosten für persönliche Werkzeuge sind gesunken
- Früher war es ein Projekt von mehreren Jahren, einen eigenen Editor, Dateimanager oder Fenstermanager zu bauen
- Schon RTFM richtig umzusetzen dauerte mehrere Jahre und war mit erheblichem Aufwand verbunden
- Für die meisten Menschen, selbst für Programmierer, lohnte sich das wirtschaftlich nicht
- Typisch war, Teile davon zu bauen und nach dem Ende des Wochenendes wieder zu vorhandenen Tools zurückzukehren
- Heute sind die Kosten dafür, „das wirklich gewünschte Tool selbst zu bauen“, dank Rust, Claude Code und ausreichend gut dokumentierter TUI-Programmierprobleme stark gesunken
- Entscheidend ist nicht KI oder Rust an sich, sondern dass der Abstand zwischen „Ich wünschte, mein Editor könnte X“ und „Hier ist ein Editor, der X kann“ klein genug geworden ist, um in einige fokussierte Abende Arbeit zu passen
Software nicht für die Auslieferung, sondern für eine Person
- Diese Software wurde nicht dafür gebaut, von anderen genutzt zu werden
- Sie ist für eine Person gemacht und auf deren Art abgestimmt, die Hände zu benutzen, über E-Mails nachzudenken und sich die Darstellung eines Kalenders zu wünschen
- Andere Nutzer würden vermutlich unzählige scharfe Kanten finden, aber für die persönliche Nutzung fallen sie nicht auf, weil sie exakt dazu passt
- Der Code und die Ideen sind nicht neu; Menschen mit besserem Geschmack, mehr Disziplin und mehr Talent haben so etwas bereits getan
- Der Kernpunkt ist, dass es jetzt tatsächlich möglich geworden ist, eine Desktop-Computing-Umgebung für genau eine Person zu bauen
- Es geht nicht mehr nur darum, Werkzeuge anderer zu konfigurieren, sondern darum, einzelne Werkzeuge des eigenen Lebens so zu ersetzen, dass sie Wochenende für Wochenende genau wie gewünscht funktionieren
- Es ist kein heroisches Zehnjahresprojekt mehr, sondern eher ein realer Austauschprozess, der sich im Takt von Wochenenden umsetzen lässt
Die Freude an Design für genau einen Nutzer
- Wenn man für sich selbst baut, muss man nicht über Konfigurierbarkeit für die Vorlieben anderer nachdenken
- Es besteht keine Notwendigkeit, Randfälle zu unterstützen, die man selbst nie erlebt
- Es ist nicht nötig, Dokumentation für nicht existierende Nutzer zu schreiben
- Man muss im Issue-Tracker nicht darüber streiten, ob die Defaults richtig sind, denn der gewünschte Wert ist sofort der richtige Default
- Das
\\?-Cheatsheet des Editors zeigt die selbst gelernten Tasten in der bevorzugten Reihenfolge und mit den Bindings, die man selbst für sinnvoll hält - Es ist Design ohne Komitee, und weil es nur einen Zielnutzer gibt, fallen Entscheidungen in Sekunden
- Ein großer Teil der Softwarekomplexität entsteht dadurch, Nutzer zu berücksichtigen, die man nicht selbst ist; nimmt man das weg, bleiben kleine, schnelle und exakt passende Werkzeuge übrig
BYOS als Option
- Wenn man sich wünscht, dass Editor, Dateimanager, Statusleiste oder Shell nur in einer einzigen Hinsicht anders funktionieren, ist die Antwort nicht mehr nur, ein Plugin zu schreiben, eine obskure Konfigurationssprache zu lernen oder den bestehenden Weg hinzunehmen
- Als dritte Option wird Build Your Own Software (BYOS) zu einem realistischeren Weg
- Selbst wenn nicht der ganze Desktop ersetzt wird, kann es ein Wochenende wert sein, auch nur ein einziges Werkzeug im täglichen Workflow exakt passend zu machen
1 Kommentare
Hacker-News-Kommentare
Ich habe in den letzten Monaten viel über dieses Thema nachgedacht und es vor ein paar Monaten in einem Blogpost als „Extremely Personal Software“ bezeichnet: https://redfloatplane.lol/blog/14-releasing-software-now/
2026 könnte mehr neue Software für nur 1 bis 10 Personen geschrieben werden als in jedem früheren Jahr, und es ist gut möglich, dass das auch in den folgenden Jahren so weitergeht
Ein großer Teil dieser Software wird praktisch versteckte Software sein, weil die Kosten, es einem Agenten zu sagen, viel niedriger sind als die Kosten, einen Entwurfsplan zu erstellen, und Menschen deshalb Dinge nur für sich selbst bauen
In den nächsten Jahren wird Interoperabilität wichtig werden, und ich frage mich, ob sich das auf Agent-/LLM-Ebene durch ständige Anweisungen wie „nimm normalerweise sqlite, Klartext und offene Standards“ lösen lässt
Für viele Leute wird Observability und Betrieb ebenfalls ziemlich wichtig werden, weil sie zwar persönliche Software wollen, sich aber nicht für Wartung und Betrieb interessieren
Seit BASIC in den 1960ern und danach mit zahllosen Lehr-Programmiersprachen einschließlich Logo von Feurzeig/Papert/Solomon wiederholt sich auf fast seltsame Weise der Versuch, Anfängern das Erstellen von Software zu ermöglichen
Dabei ging es nicht darum, zukünftige Profientwickler einzuarbeiten, sondern darum, das „persönlich“ im Personal Computer mit Bedeutung zu füllen
Es bedeutet, dass es dein Computer ist und du deine eigene Software darauf bringen kannst, und eigentlich bieten sogar Taschenrechner so etwas
Wir entdecken die Grundlagen immer wieder neu
Ohne AI hätte ich das nie gemacht und auch nie die Zeit dafür gehabt
Jetzt habe ich maßgeschneiderte Apps mit verschiedenen Funktionen, die kommerzielle Produkte nicht ohne Weiteres liefern können, und für nicht-kommerzielle Nutzung eröffnen sich viele Möglichkeiten
Freie Software könnte das eines Tages vielleicht auch bieten, aber wahrscheinlich später
Dabei habe ich technisch auch viel gelernt und konnte Gebiete erkunden, die für mich Neuland waren, zu kontrollierbaren Kosten
Ich plane, noch mehr solcher Apps zu bauen, und besonders meine Koch-App hat andere Apps am Markt sofort ersetzt, weil sie meine Anforderungen exakt erfüllt
Auch die Betriebsseite ist interessant, denn die meisten Nutzer betreiben Betriebssoftware nicht selbst, also musste ich darüber gesondert nachdenken
Tailscale und Cloudflare waren ziemlich nützlich, und dafür gibt es eindeutig einen Markt
Noch weiter gedacht könnte es dazu kommen, dass Computer Einweg-Software für einmalige Aufgaben einer einzelnen Person schreiben und sie über eine Oberfläche ausführen, die genau zu jeder Aufgabe passt, nur ein einziges Mal
Das ganze Konzept, dass Nutzer lernen müssen, wie man Software bedient, etwa indem sie Shortcuts auswendig lernen, könnte wie Lochkarten verschwinden
Wie in Star Trek könnte man einfach dem „Computer“ Arbeit geben, während die innere Funktionsweise und die Software für uns unsichtbar bleiben und wir nur mit den Ergebnissen zu tun haben
Es ist schwer, alle Implikationen zu überblicken, aber es lässt einen definitiv alt fühlen, und eine interessante Zeit steht bevor
Ich denke auch, dass dein Gefühl stimmt, dass Dinge wie APIs und Validierungsschichten viel wichtiger werden
Einige interne Tools waren es wert, als Bibliotheken gebaut zu werden, und wenn die erste Bibliothek gut ist und ein ausreichendes Testpaket existiert, wird das Portieren in mehrere Sprachen sehr einfach
Andersherum gedacht wird es auch leichter, wenn jemand maßgeschneiderte Tools auf diese Bibliotheken aufsetzt
Wirklich eine spannende Zeit für Computing
https://maggieappleton.com/home-cooked-software
Mir ist klar geworden, dass ich derselben Philosophie folge
Ich benutze suckless-Tools und habe st, dwm und anderes stark angepasst, sodass es sich jetzt wie ein Zuhause anfühlt
Im Moment implementiere ich sogar meinen eigenen git-Manager, damit er sich gut in meinen Workflow integriert
Bis zu Assembler gehe ich zwar nicht, aber ich mag den Ansatz wirklich, und ich mache mit Ruby fast dasselbe
Mein Window Manager, meine Shell, mein Terminal, mein Editor, mein Dateimanager und mein Popup-Menü, etwas wie dmenu, sind komplett in reinem Ruby geschrieben, einschließlich Font-Rendering und X11-Bindings
Das alles begann schon vor den Verbesserungen mit Claude, deshalb ist der Großteil noch von Hand geschriebener Code, aber dieses Verhältnis verändert sich gerade
Es ist chaotisch und fehlerhaft, und es hat „falsche Features“, die für mich passen, für andere aber schmerzhaft wären
Wie im Originalpost empfehle ich niemandem, meinen Code direkt selbst zu benutzen, und genau das ist unglaublich befreiend
Insgesamt decken diese Projekte, abgesehen von Kernel, Browser und Xorg, den größten Teil dessen ab, was ich benutze
Sogar Xorg ist sehr verlockend, aber damit das in den Zeitplan passt, müssten LLMs wohl deutlich besser werden
Da das meiste für mich selbst ist, muss es nicht poliert sein, und solange es für mich besser passt als die Alternativen, sind Bugs in Ordnung
Ich glaube stark, dass mehr Menschen so etwas tun sollten. Es ist eine großartige Lernerfahrung, und man bekommt tatsächlich ein System, das nur die Features hat, die man wirklich will und nutzt
In Zukunft wird das noch einfacher werden
Wirklich cool, aber ich frage mich, wie viel Zeit das tatsächlich gekostet hat und was es gekostet hat
Claude Code ist nicht kostenlos, und auch wenn es sehr schnell ist, ist es eher so, als würde man einen ziemlich teuren Roboter-Auftragnehmer nach Stunden engagieren
[1]: https://fortune.com/2026/04/28/nvidia-executive-cost-of-ai-is-greater-than-cost-of-employees/
[2]: https://www.briefs.co/news/uber-torches-entire-2026-ai-budget-on-claude-code-in-four-months/
Mit der günstigsten Stufe von Claude Pro, pi.dev+GPT-5.5 und in letzter Zeit etwas deepseek-v4 über openrouter für ungefähr zwei Wochen habe ich meine eigene angepasste Version gebaut
Die Funktionsgleichheit liegt derzeit bei etwa 90 %, und in einigen Punkten hat sie das Original bereits übertroffen
Für ungefähr 20 Euro werde ich bald einen Abo-Dienst ersetzen, der 60 Euro pro Jahr kostet
Ich habe keinen einzigen Moment darüber nachgedacht, wie andere Leute das betreiben würden, und es gibt weder Login noch Sicherheit noch irgendetwas davon
Denn es wird zu 100 % hinter einem Tailscale-Knoten ohne externen Zugriff laufen
Auch Release- und Deployment-Prozesse sind genau so, wie ich sie mag; andere vielleicht nicht, aber das muss mich nicht kümmern. Es ist meins
Vor ein paar Monaten habe ich auf dieselbe Weise auch Hazel[0] ersetzt
Das MVP hat wahrscheinlich nur einen Abend gedauert, und es hübsch zu machen hat locker etwa eine Woche gebraucht
Jetzt habe ich eine eigene macOS-App, die exakt das tut, wofür ich Hazel brauchte, sie gehört für immer mir, und ich kann Features hinzufügen oder entfernen, wie ich will
[0] https://www.noodlesoft.com/whats-new-in-hazel-6/
Irgendfür musste ich es ja verwenden
Zeitlich habe ich für das gesamte CHasm- und Fe2O3-Softwarepaket am 2026-03-29 angefangen und in meiner eigenen Zeit wahrscheinlich etwa 60 Stunden investiert
Allerdings habe ich auch ein ziemlich spezialisiertes Claude-Code-Setup für meine Bedürfnisse, das ich seit letztem Sommer in mehr als 70 Claude-Code-Projekten verfeinert habe
Ich habe einen tmux-Wrapper für genau eine Person
Von jedem meiner Geräte aus kann ich über Tailscale auf jedem anderen Gerät Claude Code, codex, opencode oder einfach nur eine Shell steuern, und noch häufiger nutze ich es auf einem exe.dev-Server
Ich setze Sitzungen oft auf dem Handy fort und benutze gelegentlich sogar Sprache
Es gibt Buttons, um Dateien anzusehen, die ein Agent im Textstream erwähnt hat, oder Links zu öffnen, und auch Buttons für genau die git-Aktionen, die ich brauche
Es gibt außerdem einen Button, um zwischen yolo mode und normal mode umzuschalten
Im Grunde ist es eine sehr einfache UI für alles, was ich tatsächlich benutze, und sie ist auch auf dem Handy leicht zu bedienen
Vielleicht noch wichtiger ist, dass es überhaupt keine UI für Dinge gibt, die ich persönlich nicht benutze
Auf all meinen Maschinen liegt dieses harness-harness-Repository, sodass ich, wenn etwas geändert werden muss, einfach einen Tab öffne, es per Prompt bauen lasse und die Änderung sofort übernehme
Alles schön und gut, aber vielleicht ist es schlecht, dass es mir ermöglicht, in jeder wachen Minute zu arbeiten
Unter Windows verwende ich einen „Ein-Personen“-whisper-Wrapper und greife per SSH darauf zu; dank der ARC-Grafikkarte im Laptop funktioniert das ganz ordentlich
Es wäre schön, wenn ich das auch beim SSH-Zugriff vom Smartphone aus könnte
Wirklich interessant
Ein Teil der Menschen, die Dinge bauen, wird etwas erschaffen, das nicht nur ihrem eigenen Geschmack, sondern auch dem eines kleinen Publikums entspricht
Ein Teil dieses Publikums wird weiter wachsen und große Player erschüttern können
Die kapitalintensiven Teile des Softwarebaus schmelzen weg und werden zu Betriebskosten in Form nutzungsbasierter Token-Kosten und der eigenen Zeit
Das wird den Möglichkeitsraum stark öffnen und eine riesige neue Allmende schaffen
Wenn die Herstellung so billig ist, gibt es keinen Grund, es nicht als Open Source zu veröffentlichen
Wenn dir der Open Source Code anderer gefällt, du ihn aber nicht komplett übernehmen willst, kannst du einfach einem Agenten sagen: „Nimm diese Idee und baue sie in meins ein“
Das ist auch eine neue Art, über Code nachzudenken
Wenn wir in ein Zeitalter reichhaltiger und häufig maßgeschneiderter Software eintreten, wird der Wert von Software als Unternehmen sinken
Es wird viele großartige Apps geben und viele schreckliche Apps
Außerdem bleibt zu beobachten, wie gesprächig das Internet bald werden wird
Viele dieser Apps werden wahrscheinlich einfach APIs aufrufen und sich gegenseitig anpingen
Leicht themenfremde Frage, aber ich frage mich, welchen Wert es hat, ein Bild eines Laptops auf einem Schreibtisch zu generieren
Es ist nicht besonders relevant, und man hätte stattdessen einen Screenshot des tatsächlichen Setups einfügen oder etwas Eigenständigeres nehmen können, so wie es offenbar in einigen Repositories gemacht wurde
Solche stimmungsmäßig ähnlichen Bilder findet man leicht, daher frage ich mich, ob ich einen Witz verpasst habe
Großartig! Und ich hasse es
Der Ersteller würde wohl selbst zugeben, dass es beim Bau dieses Softwarepakets auch Freude gab, aber es ist vermutlich eine andere Art von Freude als die, die viele Leute hier wiedererkennen würden
Wie beim „small web“ oder anderen Gegenkulturen des Internets hoffe ich, Teil einer Gruppe von Kritikern zu sein, die es auf die alte Weise macht
Ich stelle mir vor, jemand zu sein, der die Trümmer wegräumt, nachdem andere mit voller Wucht auf AI-assistiertes Alles gesetzt und dabei kritisches Denken, Programmierfähigkeit, Unix-Kommandozeilenwissen und Ähnliches verloren haben
Ich verstehe den Reiz, bei AI und personalisierter Software all-in zu gehen, bis zu einem gewissen Grad. Es wirkt ziemlich cyberpunkig
Aber aus Sicht von Open-Source-Software finde ich, dass die Nachteile die Vorteile überwiegen
Wichtige Prinzipien wie gemeinschaftliches Eigentum und Verpflichtung fehlen, und dieser Ansatz ist geradezu radikal unsozial
Wartbarkeitsprobleme sind unvermeidlich, ganz zu schweigen von der Abhängigkeit von Big Tech
Soll jeder machen, wie er will, aber das ist nicht mein Weg
Die einen sind Menschen, für die „das Ding einfach nur existieren muss“, die anderen wollen, dass es nicht nur existiert, sondern es auch selbst bauen und verstehen
Die erste Gruppe hat gerade eine großartige Zeit
Die zweite Gruppe, also Leute wie du und ich, wie oben beschrieben, bleibt wachsam und skeptisch
Es ist ein bisschen paradox. Wir haben jahrelang Sci-Fi und Cyberpunk gesehen und gelesen und von genau so einer Welt geträumt
Wann hat man jemals ein Mitglied der Enterprise-Crew Code schreiben sehen? Man sagte dem Computer einfach „schreib eine Subroutine“, und das war's. Eine coole Welt
Aber jetzt, wo sie da ist, ist das Handwerk in Gefahr, und ich bin von der Idee „frag einfach und geh wieder“ nicht uneingeschränkt begeistert
Ich fürchte auch, kritisches Denken, rohe Fähigkeiten und Gestaltungssinn zu verlieren
Ich stelle mir ebenfalls vor, in 2, 3, 5 oder 10 Jahren zu den wenigen zu gehören, die ihre Selbstwahrnehmung und ihr Handwerk nicht an Technologiefürsten abgetreten haben
Aber ich frage mich auch, ob das am Ende überhaupt wichtig ist
„Source Code“ könnte schließlich zu einer tiefen Abstraktion werden, über die niemand mehr nachdenkt
Genauso wie 99 % von uns sich nicht darum kümmern oder wissen müssen, was der Maschinencode, den wir letztlich ausgeben, genau tut oder wie er aussieht
Trotzdem werde ich mein Denken vorerst bewahren
Wenn ich denke „Ich wünschte, mein E-Mail-/Browser-/Kalender-/usw.-Programm würde X tun“, dann lag es in Wirklichkeit oft an einer Protokollgrenze darunter
Deshalb müsste man selbst dann, wenn man alle Software selbst baut, bei der Interaktion mit der Außenwelt immer noch Kompromisse eingehen