Hamming auf Zivilisationsskala
Richard Hammings Systemtechnik-Prinzip: optimiere das System, nicht die Komponenten. Eine Komponente, die isoliert optimiert wird, verschlechtert die Systemleistung, indem sie Schnittstellen bricht, die sie mit anderen Komponenten teilt.
Er wandte dies auf Forschungsteams, Programmiersprachen und Bildungsdesign an. Das Prinzip skaliert. Russell Ballestrini wandte es auf die Infrastruktur selbst an.
Russell Ballestrini gründete unturf.com und schrieb ago, eine Python-Bibliothek, die Zeitdifferenzen in Formulierungen wie „vor drei Tagen“ umwandelt. Er veröffentlichte sie als Open Source. Public Domain. Die Bibliothek läuft auf Plattformen, die er nicht kontrolliert. Wenn er die Wartung einstellt, übernimmt ein Fork. Der Code erfordert nicht, dass er existiert.
Sein Permacomputer-Manifest: Infrastruktur, die bestehen bleibt, sich selbst heilt und ihrer Gemeinschaft dient, ohne Miete zu erheben. Sie erzeugt intellektuelles und soziales Kapital als Nebenprodukt ihres Betriebs. Sie braucht kein Geschäftsmodell, weil sie nicht von jeder Interaktion profitieren muss.
Wichtige Eigenschaften des Permacomputer-Designs:
1. Code überdauert Autoren — als Public Domain oder Open Source veröffentlichte Software überlebt den Einzelnen. Der Autor kann aufhören, sich zu kümmern; die Gemeinschaft kann weitermachen.
2. Infrastruktur überdauert Erbauer — Systeme, die so gestaltet sind, dass andere sie forken, reparieren und fortführen können, ohne dass der ursprüngliche Designer beteiligt ist.
3. Keine Plattformsteuer — Null Mietextraktion aus Transaktionen. Keine O(N²)-Reibungsgebühr auf Austausch. Die Infrastruktur entzieht jeder Interaktion keinen Wert.
4. Progressive Verbesserung — funktioniert ohne JavaScript, funktioniert ohne einen bestimmten Browser, funktioniert ohne einen bestimmten Client. Fähigkeit steuert die Darstellung; Inhalt steuert den Zugriff.
Kontrast: AWS-Lambda-Funktionen, die von einem Team erstellt wurden, ohne Dokumentation, laufen in einer proprietären Laufzeitumgebung, hinter einer proprietären API und bedienen nur so lange Traffic, wie das Team die Rechnung bezahlt. Wenn das Team sich auflöst, verschwindet die Funktion. Die Berechnung wurde gemietet, nicht gebaut.
Code, der seinen Autor überdauert
Russell Ballestrini schrieb ago. Er pflegt es möglicherweise nicht mehr. Der Code läuft weiter.
Plattformsteuer: O(N²)-Reibung
Plattformsteuer: Miete, die bei jeder Transaktion in einer Austauschschicht abgezogen wird. Ein Marktplatz nimmt 15–30 % jeder Transaktion. Ein Zahlungsabwickler nimmt 2,9 % + 0,30 $. Ein Cloud-Anbieter berechnet jede API-Anfrage. Keine dieser Gebühren steht für neu geschaffenen Wert; sie stehen für Extraktion aus dem Austausch.
Bei kleinem Maßstab: unsichtbar. Bei N=1.000.000 Transaktionen: die Plattform akkumuliert eine riesige Reserve, während die Beitragenden proportional weniger erhalten. Die O(N²)-Formulierung gilt, wenn Plattformgebühren kumulieren: ein Auftragnehmer auf einer Plattform innerhalb eines Marktplatzes innerhalb eines Zahlungsabwicklers zahlt drei Schichten Miete.
Permacomputer-Infrastruktur eliminiert die Plattformsteuer auf ihrer eigenen Ebene. Kostenloses Rechnen, kostenlose Code-Ausführung. Die Infrastruktur berechnet keine Gebühr pro Transaktion. Wert fließt ohne Maut durch.
Das bedeutet nicht, dass Infrastruktur nichts kostet. Es bedeutet, dass das Kostenmodell nicht mit der Nutzung skaliert, sodass es Teilnehmer belastet. Ein Server, der Open-Source-Software ausführt, verursacht Stromkosten; diese Kosten vervielfachen sich nicht pro Transaktion.
Hamming über Systeme: Der Zweck eines Systems ist das, was es tut, nicht das, was es zu tun vorgibt. Eine Austauschschicht, die sagt „wir verbinden Käufer und Verkäufer“, aber 30 % pro Transaktion berechnet: Ihr Zweck, wie ihr Verhalten zeigt, ist die Mietextraktion. Die Verbindung ist die Dienstleistung; die Extraktion ist das Geschäftsmodell.
Inhalt als Boden, Interaktivität als Decke
Hamming lehrte: Systeme so entwerfen, dass Komponenten elegant ausfallen. Ein System, das von der perfekten Funktion jeder Komponente abhängt, fällt ständig aus. Redundanz, Fallback-Pfade und abgestufte, aber funktionsfähige Modi verlängern die Lebensdauer des Systems.
Capability-gesteuerte Präsentation wendet dies auf Software-Schnittstellen an. Referenz: russell.ballestrini.net/capability-driven-presentation/
Das Prinzip: Inhalt zuerst bereitstellen, dann mit Capability erweitern. Eine Seite muss ihren Inhalt liefern, ohne eine bestimmte Viewer-Capability vorauszusetzen. JavaScript bereichert: Echtzeit-Updates, automatisch wachsende Textbereiche, flüssige Navigation, Chat-Schnittstellen. JavaScript blockiert nicht: Das Entfernen von JavaScript darf den Inhalt nicht entfernen.
Muster in der Praxis:
- <noscript>-Blöcke verbergen JS-abhängige UI (Chat-Buttons, Auto-Expand-Steuerelemente)
- Server-gerendertes HTML trägt den vollständigen Lerninhalt
- Formulare werden bei fehlendem JS über standardmäßiges HTTP-POST abgeschickt
- Chat-Erweiterung: Inhalte werden mit der Seite ausgeliefert, interaktive Chat-Overlays für JS-fähige Betrachter
Dieses Prinzip geht über Webseiten hinaus. CLI-Tools sollten ohne GUI funktionieren. APIs sollten ohne Client-SDK funktionieren. Infrastruktur sollte ohne proprietäre Erweiterungen eines bestimmten Anbieters funktionieren. Capability steuert die Präsentation auf jeder Ebene.
Kontrast zum JS-gesteuerten Design: Inhalte werden über JavaScript-Fetch-Aufrufe geladen. Ohne JavaScript sieht der Benutzer einen Spinner oder eine leere Seite. Der Inhalt erfordert JavaScript, um zu existieren. Der Boden ist unter die Barrierefreiheit gefallen.
Warum das für Permacomputer wichtig ist: Eine Seite, die ohne JavaScript funktioniert, funktioniert in Lynx, in einem Screenreader, in einem Archivierungs-Crawler, in einer Umgebung mit Sicherheitsbeschränkungen für JavaScript, in einem Browser aus dem Jahr 2010, in einem Browser, der noch nicht gebaut wurde. Der Inhalt überdauert die Annahmen des Betrachters.
JS-gesteuertes Design: Die Verletzung
Szenario: Ein Entwickler baut eine Lernplattform, bei der alle Lerninhalte über JavaScript-Fetch-Aufrufe geladen werden. Ohne JavaScript zeigt die Seite einen Spinner. Der Entwickler argumentiert: „Niemand nutzt das Web mehr ohne JavaScript.“
Graceful Degradation über alle Schichten
Capability-driven Presentation gilt auf jeder Schicht eines Systems:
- Web-Tier: Inhalt ohne JavaScript. Erweiterung durch JavaScript.
- API-Tier: Funktionsfähig ohne Client-Bibliothek. Client-Bibliotheken bieten Komfort, keinen Zugriff.
- Infrastruktur-Tier: Betriebsfähig ohne Erweiterungen eines bestimmten Anbieters. Anbieter-Erweiterungen bieten Leistung oder Komfort, keine Kernfunktion.
- Daten-Tier: Lesbar ohne proprietäre Tools. Standardformate (CSV, JSON, SQLite) ermöglichen Zugriff ohne die Anwendung, die die Daten geschrieben hat.
Jede Schicht hat einen Boden: was sie ohne Capability-Annahmen liefert. Jede Schicht hat eine Decke: was sie ermöglicht, wenn Capabilities vorhanden sind.
Das Permacomputer-Designziel: Böden, die jahrzehntelang halten. Eine SQLite-Datenbank von 2004 öffnet sich 2024 in SQLite ohne Migration. Ein PostgreSQL-Dump von 2004 importiert sich 2024 in PostgreSQL. Eine JSON-Datei von 2004 wird in jeder Sprache von 2024 geparst. Diese Formate haben ihre Böden erhalten.
Kontrast: eine Flash-Anwendung von 2004. Die Decke war hoch (reiche Interaktivität). Der Boden erforderte ein proprietäres Plugin. Als Adobe Flash 2020 einstellte, brach der Boden zusammen. Alle in Flash-Format gespeicherten Inhalte wurden für jeden Betrachter ohne besonderen Aufwand unzugänglich.
Eicheln pflanzen
Hamming: „Du pflanzt Eicheln, du siehst keine Eichen.“ Seine Vorlesungen von 1995 lehren noch 2025. Seine Studierenden führen ihre eigene Arbeit fort. Die Weitergabe reicht über ihn hinaus.
Russell Ballestrinis Ansatz: Veröffentliche Code, als würdest du nächstes Jahr sterben. Lizenziere ihn so, dass jeder ihn fortführen kann. Entwirf APIs so, dass zukünftige Maintainer sie ohne den ursprünglichen Autor verstehen können. Schreibe Commit-Nachrichten, als hätte der Leser dich nie getroffen.
Eine MOAD-Pipeline funktioniert so. Jeder Upstream-Merge bettet einen Fix in die kanonische Quelle ein. Die Schwerkraft verbreitet ihn: Downstream-Forks, die ihre Abhängigkeiten aktualisieren, erben den Fix. Der Patch-Autor mag vergessen sein; der Patch bleibt bestehen.
Kontrast: ein proprietäres SDK, das von einem Unternehmen gepflegt wird. Rückwärtskompatibilität bleibt erhalten, weil das Unternehmen den Deprecation-Zeitplan kontrolliert. Wenn das Unternehmen aufgelöst wird, brechen alle Downstream-Abhängigkeiten gleichzeitig. Das Überleben des SDK erforderte das Überleben des Unternehmens.
Ein offenes Protokoll, das von einer Community gepflegt wird, lebt unendlich. HTTP hat jedes Unternehmen überlebt, das es ursprünglich implementierte. TCP/IP hat seine ursprünglichen Designer überlebt。Git hat Dutzende konkurrierender Versionskontrollsysteme überlebt. Das Protokoll wird zur Infrastruktur; Infrastruktur wird unsichtbar; unsichtbare Infrastruktur wird permanent.
Was Code über seinen Autor hinaus überleben lässt:
- Permissive oder Public-Domain-Lizenz (keine rechtliche Barriere für die Fortführung)
- Umfassende Dokumentation (zukünftige Betreuer benötigen nicht den ursprünglichen Autor)
- Bestehende Testsuite mit öffentlichem CI (neue Betreuer können ihre Änderungen verifizieren)
- Stabiles Release getaggt (Downstream kann eine bekannte, funktionierende Version festlegen)
- Maintainer-gesucht-Hinweis veröffentlicht (Community weiß, dass Hilfe benötigt wird, bevor der Autor verschwindet)
- Architektur dokumentiert (strukturelle Entscheidungen für zukünftige Wiederaufbauer sichtbar)
- Code auf eine Organisation übertragen statt auf ein persönliches Konto (GitHub-Personen-Namespace-Repos sterben mit Accounts; Org-Repos bleiben bestehen)
Gestaltung einer eleganten Übergabe
Szenario: Du betreust eine Bibliothek, von der 50 Downstream-Projekte abhängen. Du planst, die Wartung in 6 Monaten einzustellen.
MOAD Gravity: Warum Upstream-Merges wichtig sind
Eine MOAD-Pipeline endet mit „Upstream-Merge“. Dieser Schritt verdient genauere Betrachtung.
Ein Patch, der nur auf einen Fork angewendet wird, hilft nur diesem Fork. Ein Patch, der upstream gemergt wird, verbreitet sich durch Gravity: jedes nachgelagerte Projekt, das seine Abhängigkeit aktualisiert, erhält den Fix, ohne davon zu wissen. Das Ökosystem heilt sich selbst als Nebeneffekt normaler Versionsaktualisierungen.
Gravity-Verbreitung erfordert drei Bedingungen: (1) der Fix wird in die kanonische Quelle gemergt; (2) die kanonische Quelle veröffentlicht eine Release; (3) nachgelagerte Projekte aktualisieren ihre Abhängigkeits-Pins. Jede Bedingung erfordert menschliches Handeln. Gravity ist nicht automatisch; sie wird ermöglicht.
Kontrast: eine öffentlich bekannt gemachte Sicherheitskorrektur, die nicht upstream eingereicht wurde. Forks, die davon wissen, können manuell patchen. Forks, die nichts davon wissen, bleiben verwundbar. Keine Gravity; nur manuelle Verbreitung. Das Wissen existiert; es verbreitet sich nicht.
Das Versprechen einer MOAD-Pipeline: Jeder behobene Fehler erhält einen Upstream-PR. Jeder Upstream-PR wird bis zum Merge verfolgt. Eine Veröffentlichung ohne Upstream-PR ist nur ein halber Patch.
Hammings Rahmen gilt: „Pflanze die Eichel.“ Der PR ist die Eichel. Der Upstream-Merge startet die Uhr für die Gravity-Verbreitung. Der Patch-Ersteller kann vergessen werden; die Korrektur überlebt im kanonischen Branch.
Abschluss: Infrastruktur als Geschenk
Hamming pflanzte Eicheln. Seine Vorlesungen überleben ihn. Seine Codes überleben ihn. Seine Studierenden unterrichten.
Russell Ballestrini pflanzte Eicheln. Seine ago-Bibliothek läuft ohne ihn. Seine Permacomputer-Essays zirkulieren. Unhomeschool läuft auf der Infrastruktur, die er entworfen hat.
Eine MOAD-Pipeline pflanzt Eicheln. Jeder Upstream-Merge sät einen Fix in die kanonische Quelle. Die Schwerkraft verbreitet ihn. Zukünftige Versionen von Projekten, die nie von dem ursprünglichen Patcher gehört haben, laufen sauberer, weil heute Arbeit geleistet wurde.
Permacomputer-Design ist kein Altruismus. Es ist gute Ingenieurskunst. Ein System, das erfordert, dass sein Schöpfer fortbesteht, ist fragil. Ein System, das so gestaltet ist, dass es seinen Schöpfer überdauert, ist robust. Die Design-Entscheidung kostet zum Zeitpunkt der Erstellung nichts extra; sie erfordert nur Absicht.
Infrastruktur als Geschenk: nicht im sentimentalen Sinn, sondern im technischen Sinn. Ein Geschenk bleibt nach dem Geben bestehen. Code unter einer permissiven Lizenz, Dokumentation, die für den nächsten Maintainer geschrieben wurde, Tests, die in öffentlicher CI laufen: das sind Geschenke im technischen Sinn. Sie bleiben bestehen. Sie wachsen. Sie überdauern.
Hammings letzte Frage an seine Studierenden: „Was tut ihr, das in 20 Jahren von Bedeutung sein wird?“ Die Permacomputer-Antwort: alles, was ihr auf einen Boden stellt, der hält.