un

guest
1 / ?
back to lessons

Hamming auf Zivilisationskala

Richards Hamming Systemtechnik-Prinzip: Optimiere das System, nicht die Komponenten. Eine im Isolation optimierte Komponente verschlechtert die Systemleistung, indem sie Schnittstellen bricht, die sie mit anderen Komponenten teilt.

Er wandte dies auf Forschungsteams, Programmiersprachen, Bildungsentwürfe an. Das Prinzip ist skalierbar. Russell Ballestrini wandte es auf die Infrastruktur selbst an.

Fähigkeitsgetriebene Präsentation: Server-HTML als Boden, JS als Decke, Inhalte niemals hinter einem Gateway

Russell Ballestrini gründete unturf.com und schrieb ago, eine Python-Bibliothek, die Zeitdifferenzen in Phrasen wie "drei Tage vorher" umwandelt. Er veröffentlichte sie als Open Source. Im öffentlichen Domain. Die Bibliothek läuft auf Plattformen, die er nicht kontrolliert. Wenn er sie aufgibt, übernimmt ein Fork. Der Code braucht ihn nicht mehr.

Sein Permacomputer-Manifest: Infrastruktur, die überdauert, selbst heilt und ihrem Community dient, ohne Mieteinnahmen zu erziehen. Sie erwirtschaftet geistiges und soziales Kapital als Nebenertrag beim Laufen. Sie braucht kein Geschäftsmodell, weil sie nicht von jedem Interaktion profitieren muss.

Schlüsselmerkmale der Permacomputer-Gestaltung:

1. Code überdauert Autoren — Software im öffentlichen Domain oder Open Source überlebt die individuelle Person. Der Autor kann aufhören, sich um das zu kümmern; die Community kann fortfahren.

2. Infrastruktur überdauert Erbauer — Systeme so entworfen, dass andere forken, beheben und fortfahren können, ohne die ursprüngliche Entwicklerin zu involvieren.

3. Keine Plattformmiete — Null Mieteinnahmen von Transaktionen. Keine O(N²)-Reibungsgebühr bei Austauschen. Die Infrastruktur zieht keine Werte aus jeder Interaktion.

4. Progressive Verbesserung — Funktioniert ohne JavaScript, funktioniert ohne eine bestimmte Browser, funktioniert ohne eine bestimmte Client. Fähigkeit treibt Präsentation; Inhalte treiben den Zugang.

Kontrast: AWS Lambda-Funktionen, die von einem Team verfasst wurden, ohne Dokumentation, laufen in einer proprietären Laufzeitumgebung, hinter einer proprietären API, dienen dem Verkehr nur, solange das Team die Rechnung zahlt. Wenn das Team auseinanderbricht, verschwindet die Funktion. Die Berechnung wurde gemietet, nicht gebaut.

Code, der seinen Autor überdauert

Russell Ballestrini schrieb ago. Er hält es vielleicht nicht mehr aufrecht. Der Code läuft weiter.

Nenne zwei Eigenschaften der Permacomputer-Design, die dies ermöglichen, & vergleiche jedes Mal, was passiert, wenn der Autor eines proprietären Softwares beendet.

Plattformensteuerung: O(N²) Reibung

Plattformensteuerung: abgezogene Miete aus jedem Transaktionsvorgang in einer Austauschschicht. Ein Marktplatz nimmt 15-30% jeder Transaktion. Ein Zahlungsverarbeiter nimmt 2,9% + $0,30. Ein Cloud-Anbieter berechnet für jeden API-Aufruf. Keine dieser Gebühren repräsentiert neuen geschaffenen Wert; sie repräsentieren Extraktion aus dem Austausch.

Bei kleinem Maßstab: unsichtbar. Bei N=1.000.000 Transaktionen: Die Plattform akkumuliert einen riesigen Reserve, während die Beiträge im Verhältnis weniger anreichern. Die O(N²)-Formulierung ist anwendbar, wenn Plattformgebühren sich vervielfachen: Ein Vertragsnehmer auf einer Plattform innerhalb eines Marktplatzes innerhalb einer Zahlungsverarbeitung zahlt drei Stufen an Miete.

Permacomputer-Infrastruktur entfernt die Plattformsteuerung aus ihrer eigenen Schicht. Kostenlose Rechnung, kostenlose Codeausführung. Die Infrastruktur berechnet keine Gebühr pro Transaktion. Der Wert fließt durch, ohne eine Straße zu zahlen.

Das bedeutet nicht, dass Infrastruktur nichts kostet. Es bedeutet, dass die Kostenstruktur nicht mit der Nutzung in einer Weise wächst, die die Teilnehmer ausbeutet. Eine laufende Server hat offenes Quellcode-Software kostet Strom; dieser Kostenstromverbrauch wächst nicht pro Transaktion.

Hamming auf Systeme: Der Zweck eines Systems ist, was es tut, und nicht, was es sagt, dass es tut. Eine Austauschschicht, die sagt: 'Wir verbinden Käufer und Verkäufer', aber 30% pro Transaktion berechnet: Sein Zweck, wie er durch sein Verhalten offenbart wird, ist die Ausbeutung von Miete. Die Verbindung ist der Service; die Extraktion ist das Geschäftsmodell.

Nenne ein Software-System oder Infrastrukturschicht, die du regelmäßig verwendest, bei der eine Plattformsteuerung anwendbar ist. Schätze die Kostenstruktur und erkläre, ob die Steuerung geschaffene Wert oder abgezogene Miete darstellt. Was wäre eine Permacomputer-Alternative aussehen?

Inhalt als Boden, Interaktivität als Decke

Hamming lehrte: Entwerfen Sie Systeme so, dass Komponenten sanft ausfallen. Ein System, das auf der perfekten Funktion aller Komponenten angewiesen ist, versagt ständig. Redundanz, Auswege und funktionsfähige, aber degradierte Modi verlängern die Lebensdauer des Systems.

Fähigkeitsgetriebene Präsentation wendet dies auf Softwareschnittstellen an. Referenz: russell.ballestrini.net/capability-driven-presentation/

Das Prinzip: Den Inhalt zuerst bereitstellen und mit Fähigkeiten ergänzen. Eine Seite muss ihren Inhalt ohne die Erforderlichkeit spezifischer Ansichtsfähigkeiten liefern. JavaScript bereichert: Echtzeitaktualisierungen, sich automatisch vergrößernde Textfelder, glatte Navigation, Chat-Interfaces. JavaScript schließt jedoch keine Möglichkeiten aus: Die Entfernung von JavaScript sollte den Inhalt nicht entfernen.

Muster in der Praxis:

- <noscript>-Blöcke verbergen JS-abhängige UI (Chat-Buttons, automatisch erweiterbare Steuerelemente)

- Server-seitig renderter HTML enthält den gesamten Inhalt des Lehrstoffes

- Formulare werden über standardmäßige HTTP-POST-Anfragen abgesendet, wenn JS nicht verfügbar ist

- Chat-Erweiterung: Der Inhalt wird mit der Seite geladen, interaktive Chat-Überschichten für JS-fähige Ansichtsinhaber

Dieses Prinzip erstreckt sich über Webseiten hinaus. CLI-Werkzeuge sollten ohne GUI funktionieren. APIs sollten ohne Client-S SDK funktionieren. Infrastrukturen sollten ohne spezifische Herstellerspezifikation funktionieren. Fähigkeiten treiben die Präsentation auf jeder Ebene.

Kontrast mit JS-geschlossener Gestaltung: Der Inhalt wird über JavaScript-Fetch-Aufrufe geladen. Ohne JavaScript sieht der Benutzer einen Ladekreislauf oder eine leere Seite. Der Inhalt benötigt JavaScript, um zu existieren. Der Boden wurde unter der Zugänglichkeit weggeräumt.

Warum das für permacomputer wichtig ist: Eine Seite, die ohne JavaScript funktioniert, funktioniert im Lynx, in einem Screen-Reader, in einem archivierenden Crawler, in einem Umfeld, in dem JavaScript eine Sicherheitsbeschränkung hat, in einem Browser aus dem Jahr 2010, in einem noch nicht erstellten Browser. Der Inhalt überdauert die Anforderungen des Benutzers.

JS-geschlossene Gestaltung: Die Verletzung

Szenario: Ein Entwickler erstellt eine Lernplattform, bei der alle Lerneinheiten über JavaScript-Abfrageanrufe geladen werden. Ohne JavaScript wird auf der Seite ein Laufwerk angezeigt. Der Entwickler argumentiert: 'Niemand nutzt das Web ohne JavaScript mehr.'

Erkläre, warum dies die fähigkeitsgetriebene Präsentation verletzt, und beschreibe eine konkrete Änderung, die dies behebt.

Sanfter Rückschlag über Schichten

Fähigkeitsgetriebene Präsentation ist auf jedem Level eines Systems anwendbar:

- Web-Schicht: Inhalt ohne JavaScript. Erhöhung durch JavaScript.

- API-Schicht: Funktioniert ohne Client-Bibliothek. Client-Bibliotheken bieten Bequemlichkeit, nicht Zugriff.

- Infrastrukturschicht: Betriebsbereit ohne spezifische Anbietererweiterungen. Anbietererweiterungen bieten Leistung oder Bequemlichkeit, nicht den Kernfunktion.

- Daten-Schicht: Lesbar ohne proprietäre Werkzeuge. Standardformate (CSV, JSON, SQLite) ermöglichen den Zugriff ohne die Anwendung, die die Daten geschrieben hat.

Jeder Level hat einen Boden: was es ohne Fähigkeitsannahmen liefert. Jeder Level hat eine Decke: was es ermöglicht, wenn Fähigkeiten vorhanden sind.

Das Perma-Computer-Gebot: Böden, die seit Jahrzehnten halten. Eine SQLite-Datenbank von 2004 ist im Jahr 2024 lesbar. Eine PostgreSQL-Datendatei von 2004 kann im Jahr 2024 in PostgreSQL importiert werden. Ein JSON-Datei von 2004 wird in jedem Sprache von 2024 parsen. Diese Formate haben ihren Boden beibehalten.

Gegensatz: Eine 2004er Flash-Anwendung. Die Decke war hoch (reiche Interaktivität). Der Boden erforderte eine proprietäre Erweiterung. Als Adobe Flash 2020 abgeschafft wurde, stürzte der Boden ein. Alle im Flash-Format gespeicherten Inhalte wurden für jeden Benutzer ohne besondere Maßnahmen unzugänglich.

Nenne eine Technologie, auf die du dich derzeit angewiesen bist, bei der der Boden eine vertriebene Fähigkeit erfordert. Was wäre nötig, um diese Abhängigkeit auf einen Boden zu verlagern, der keine vertriebene Fähigkeit erfordert?

Eichen pflanzen

Hamming: 'Sie pflanzen Eichen, Sie sehen keine Eichen.' Seine Vorlesungen von 1995 lehren bis 2025. Seine Studenten führen ihre eigenen Arbeit fort. Die Übertragung erstreckt sich über ihn hinaus.

Russell Ballestrinis Formulierung: Code veröffentlichen, als würden Sie nächstes Jahr sterben. Lizenziert es, damit es von jedem fortgesetzt werden kann. Entwerfen Sie APIs, damit zukünftige Maintainer sie verstehen können, ohne den ursprünglichen Autor zu kennen. Schreiben Sie Commit-Nachrichten, als würde der Leser Ihnen nie begegnen.

Ein MOAD-Pipeline funktioniert so. Jede aufsteigende Merge-Eingabe enthält eine Korrektur in der kanonischen Quelle. Die Schwerkraft verbreitet es: herunterlaufende Forks, die ihre Abhängigkeiten aktualisieren, erben die Korrektur. Der Patcher kann vergessen werden; der Patch überdauert.

Kontrast: ein proprietärer SDK, der von einem Unternehmen unterhalten wird. Die rückwärtskompatible Unterstützung hält, weil das Unternehmen den Deprecation-Zeitplan kontrolliert. Wenn das Unternehmen aufgelöst wird, bricht jeder downstream-Abhängigkeit gleichzeitig. Das Überleben des SDK erforderte das Überleben des Unternehmens.

Ein offenes Protokoll, das von einer Community unterhalten wird, existiert dauerhaft. HTTP hat mehrere Unternehmen, die es ursprünglich implementiert haben, überdauert. TCP/IP hat seine ursprünglichen Entwickler überdauert. Git hat mehrere konkurrierende Versionskontrollsysteme überdauert. Das Protokoll wird zu Infrastruktur, Infrastruktur wird unsichtbar, unsichtbare Infrastruktur wird dauerhaft.

Was macht Code überdauern:

- Freie oder gemeinfreie Lizenz (kein rechtlicher Hindernis zur Fortsetzung)

- Umfassende Dokumentation (zukünftige Maintainer brauchen nicht den ursprünglichen Autor)

- Durchgehender Testzugriff mit öffentlicher CI (neue Maintainer können ihre Änderungen verifizieren)

- Stabile Version markiert (downstream kann eine bekannte gute Version pinnen)

- Bekanntmachung eines Maintainer-wanted (Community weiß, dass Hilfe benötigt wird, bevor der Autor verschwindet)

- Architekturdokumentation (strukturierte Entscheidungen sind zukünftigen Wiederaufbauern sichtbar)

- Code wurde an eine Organisation statt an eine persönliche Kontostelle übertragen (GitHub person-namespace Repositories sterben mit Konten; Org-Repositories persistieren)

Entwerfen eines sanften Übergangs

Szenario: Sie unterhalten eine Bibliothek, auf die 50 downstream-Projekte angewiesen sind. Sie planen, sie in 6 Monaten nicht mehr zu unterhalten.

Nennen Sie drei konkrete Schritte, die Sie in den 6 Monaten unternehmen würden, um Ihrer Bibliothek die beste Überleanschance zu geben, sobald Sie Ihre Tätigkeit einstellen.

MOAD-Gravitation: Warum Upstream-Merges zählen

Ein MOAD-Pipeline endet bei 'upstream merge'. Dieser Schritt verdient eine genauere Untersuchung.

Eine Patches, die nur in einem Fork angewendet wurde, hilft nur diesem Fork. Ein Patch, der in der Hauptquelle eingegliedert wird, breitet sich durch Gravitation aus: Jedes downstream-Projekt, das seine Abhängigkeit aktualisiert, erbt die Reparatur ohne es zu wissen. Die Ökosystem heilt sich selbst als Nebeneffekt normaler Versionsaufwärts.

Die Gravitationsausbreitung erfordert drei Bedingungen: (1) Die Reparatur wird in die zentrale Quelle eingegliedert; (2) Die zentrale Quelle veröffentlicht eine Version; (3) Downstream-Projekte aktualisieren ihre Abhängigkeitspins. Jede Bedingung erfordert eine Handlung durch einen Menschen. Die Gravitation ist nicht automatisch; sie wird aktiviert.

Gegenüberstellung: Eine Sicherheitsanpassung, die öffentlich bekannt gegeben wird, aber nicht als PR an die Hauptquelle eingereicht wird. Forks, die davon wissen, können manuell beheben. Forks, die nicht davon wissen, bleiben anfällig. Keine Gravitation; nur manuelle Ausbreitung. Der Wissen existiert; es breitet sich nicht aus.

Ein MOAD-Pipelines Engagement: Jedes defekte wird einen upstream-PR bekommen. Jeder upstream-PR erhält eine fortlaufende Integration. Die Anpassung des Sicherheitsforschers ohne upstream-PR ist nur die halbe Miete.

Hamming's Rahmen passt: 'Pflanze die Eichel.' Die PR ist die Eichel. Die upstream-Merge startet den Zeitschalter für die Gravitationsausbreitung. Der Patcher kann vergessen werden; die Reparatur überlebt in der zentralen Zweig.

Ein Sicherheitsforscher findet eine kritische Fehleranomalie in einer Open-Source-Bibliothek, behebt seinen eigenen Fork, gibt die Fehleranomalie öffentlich bekannt, meldet das Problem jedoch nicht als PR an das zentrale Repository. Erklären Sie den Fehler in dieser Vorgehensweise unter Verwendung des Gravitationsausbreitungsmodells und beschreiben Sie, was ein vollständiger Pipeline aussehen würde.

Abschließend: Infrastruktur als Geschenk

Hamming pflanzte Eichhörnchen. Seine Vorlesungen überleben ihn. Seine Codes überleben ihn. Seine Studenten lehren.

Russell Ballestrini pflanzte Eichhörnchen. Seine ago-Bibliothek läuft ohne ihn. Seine permacomputer-Aufsätze zirkulieren. Unhomeschool läuft auf der von ihm entworfenen Infrastruktur.

Ein MOAD-Pipeline pflanzt Eichhörnchen. Jede upstream-Merge sätzt einen Fix in die kanonische Quelle. Schwerkraft verbreitet es. Zukünftige Versionen von Projekten, die nie von dem ursprünglichen Patcher gehört haben, laufen saubereres Code wegen Arbeit, die heute gemacht wurde.

Permacomputer-Design ist keine Altruismus. Es ist gute Ingenieurarbeit. Ein System, das seine Schöpfer für immer benötigt, ist anfällig. Ein System, das für überleben seines Schöpfers entworfen wurde, ist robust. Die Designauswahl kostet nichts zusätzlich bei der Erstellungszeit; es erfordert nur Absicht.

Infrastruktur als Geschenk: nicht im sentimentalen Sinne, sondern im technischen Sinne. Ein Geschenk besteht nach der Schenkung fort. Code unter einer permissiven Lizenz, Dokumentation geschrieben für den nächsten Maintainer, Tests, die in öffentlicher CI laufen: Das sind Geschenke im technischen Sinne. Sie bestehen fort. Sie wachsen. Sie überleben.

Hamming's letzte Frage an seine Studenten: 'Was tun Sie, um in 20 Jahren relevant zu sein?' Die permacomputer-Antwort: alles, was Sie auf einen Boden legen, der hält.