Hamming i civilisationens skala
Richard Hammings systemtekniska princip: optimera systemet, inte komponenterna. En komponent som optimeras isolerat försämrar systemets prestanda genom att bryta gränssnitt som den delar med andra komponenter.
Han tillämpade detta på forskningsteam, programmeringsspråk och utbildningsdesign. Principen skalas. Russell Ballestrini tillämpade den på själva infrastrukturen.
Russell Ballestrini grundade unturf.com och skrev ago, ett Python-bibliotek som humaniserar tidsdifferenser till fraser som 'three days ago'. Han publicerade det som öppen källkod. Public domain. Biblioteket körs på plattformar han inte kontrollerar. När han slutar underhålla det tar en fork över. Koden kräver inte att han existerar.
Hans permacomputer-manifest: infrastruktur som består, självläker och tjänar sitt samhälle utan att ta ut hyra. Den bygger intellektuellt och socialt kapital som en biprodukt av sin drift. Den behöver ingen affärsmodell eftersom den inte behöver tjäna pengar på varje interaktion.
Nyckelegenskaper hos permacomputer-design:
1. Kod överlever författare — programvara som publiceras som public domain eller öppen källkod överlever individen. Författaren kan sluta bry sig; gemenskapen kan fortsätta.
2. Infrastruktur överlever byggare — system utformade så att andra kan förgrena, åtgärda och fortsätta utan den ursprungliga designerns inblandning.
3. Ingen plattformsskatt — noll hyresuttag från transaktioner. Ingen O(N²)-friktionsavgift på utbyten. Infrastrukturen extraherar inte värde från varje interaktion.
4. Progressiv förbättring — fungerar utan JavaScript, fungerar utan en specifik webbläsare, fungerar utan en specifik klient. Funktionalitet styr presentation; innehåll styr åtkomst.
Kontrast: AWS Lambda-funktioner skapade av ett team, utan dokumentation, körda i en proprietär runtime, bakom ett proprietärt API, som bara betjänar trafik så länge teamet betalar räkningen. När teamet upplöses försvinner funktionen. Beräkningen var hyrd, inte byggd.
Kod som överlever sin författare
Russell Ballestrini skrev ago. Han kanske inte längre underhåller det. Koden kör vidare.
Plattformsskatt: O(N²)-friktion
Plattformsskatt: hyra som tas ut från varje transaktion i ett utbyteslager. En marknadsplats tar 15–30 % av varje utbyte. En betalningsförmedlare tar 2,9 % + 0,30 $. En molnleverantör debiterar för varje API-anrop. Inga av dessa avgifter representerar nytt värde som skapats; de representerar uttag från utbytet.
I liten skala: osynlig. Vid N=1 000 000 transaktioner: plattformen samlar en enorm reserv medan bidragsgivarna får proportionellt mindre. O(N²)-formuleringen gäller när plattformsavgifter ackumuleras: en entreprenör på en plattform inuti en marknadsplats inuti en betalningsförmedlare betalar tre lager av hyra.
Permacomputer-infrastruktur eliminerar plattformsskatt från sitt eget lager. Gratis beräkning, gratis kodexekvering. Infrastrukturen tar inte betalt per transaktion. Värde flödar igenom utan tull.
Detta betyder inte att infrastrukturen är kostnadsfri. Det betyder att kostnadsmodellen inte skalas med användning på ett sätt som extraherar från deltagarna. En server som kör öppen källkod kostar el; den kostnaden ökar inte per transaktion.
Hamming om system: ett systems syfte är vad det gör, inte vad det säger att det gör. Ett utbyteslager som säger "vi kopplar samman köpare och säljare" men tar 30 % per transaktion: dess syfte, som avslöjas av dess beteende, är hyresuttag. Kopplingen är tjänsten; uttaget är affärsmodellen.
Innehåll som golv, interaktivitet som tak
Hamming lärde ut: designa system så att komponenter fallerar med värdighet. Ett system som kräver att varje komponent fungerar perfekt fallerar konstant. Redundans, reservvägar och nedgraderade men funktionella lägen förlänger systemets livslängd.
Capability-driven presentation tillämpar detta på mjukvarugränssnitt. Referens: russell.ballestrini.net/capability-driven-presentation/
Principen: leverera innehåll först, förbättra med kapacitet. En sida måste kunna leverera sitt innehåll utan att kräva någon specifik visningsförmåga. JavaScript berikar: realtidsuppdateringar, automatiskt växande textområden, smidig navigering, chattgränssnitt. JavaScript spärrar inte: att ta bort JavaScript får inte ta bort innehållet.
Mönster i praktiken:
- <noscript>-block döljer JS-beroende gränssnitt (chattknappar, auto-expand-kontroller)
- Server-renderad HTML bär hela lektionsinnehållet
- Formulär skickas via vanlig HTTP POST när JS inte är tillgängligt
- Chat-förbättring: innehåll levereras med sidan, interaktiva chattöverlägg för JS-kapabla visare
Denna princip sträcker sig bortom webbsidor. CLI-verktyg bör fungera utan ett GUI. API:er bör fungera utan ett klient-SDK. Infrastruktur bör fungera utan en specifik leverantörs proprietära tillägg. Kapacitet styr presentation på varje lager.
Kontrast med JS-styrd design: innehåll laddas via JavaScript fetch-anrop. Utan JavaScript ser användaren en snurrande ikon eller en tom sida. Innehållet kräver JavaScript för att existera. Golvet sjönk under tillgänglighet.
Varför detta är viktigt för permacomputer: en sida som fungerar utan JavaScript fungerar i Lynx, i en skärmläsare, i en arkiveringscrawler, i en miljö där JavaScript har en säkerhetsrestriktion, i en webbläsare från 2010, i en webbläsare som ännu inte har byggts. Innehållet överlever visningsantagandena.
JS-styrd design: Överträdelsen
Scenario: en utvecklare bygger en lärplattform där allt lektionsinnehåll laddas via JavaScript fetch-anrop. Utan JavaScript visar sidan en snurrande ikon. Utvecklaren argumenterar: 'Ingen använder webben utan JavaScript längre.'
Graceful Degradation Across Layers
Capability-driven presentation gäller på varje lager i ett system:
- Web tier: innehåll utan JavaScript. Förbättring med JavaScript.
- API tier: funktionellt utan ett klientbibliotek. Klientbibliotek ger bekvämlighet, inte åtkomst.
- Infrastructure tier: operativt utan en specifik leverantörs tillägg. Leverantörstillägg ger prestanda eller bekvämlighet, inte kärnfunktion.
- Data tier: läsbar utan proprietära verktyg. Standardformat (CSV, JSON, SQLite) möjliggör åtkomst utan applikationen som skrev datan.
Varje lager har ett golv: vad det levererar utan antaganden om kapacitet. Varje lager har ett tak: vad det möjliggör när kapacitet finns.
Permacomputer-designmålet: golv som håller i årtionden. En SQLite-databas från 2004 öppnas i 2024 års SQLite utan migrering. Ett PostgreSQL-dump från 2004 importeras i 2024 års PostgreSQL. En JSON-fil från 2004 tolkas i vilket språk som helst från 2024. Dessa format har behållit sina golv.
Kontrast: en Flash-applikation från 2004. Taket var högt (rik interaktivitet). Golvet krävde ett proprietärt plugin. När Adobe avvecklade Flash 2020 rasade golvet. Allt innehåll som lagrats i Flash-format blev oåtkomligt för alla visare utan särskilda åtgärder.
Plantera ekollon
Hamming: ”Du planterar ekollon, du ser inte ekarna.” Hans föreläsningar från 1995 fortsätter att undervisa år 2025. Hans studenter fortsätter sitt eget arbete. Överföringen sträcker sig bortom honom.
Russell Ballestrinis ramverk: publicera kod som om du ska dö nästa år. Licensiera den så att vem som helst kan fortsätta den. Designa API:er så att framtida underhållare kan förstå dem utan den ursprungliga författaren. Skriv commit-meddelanden som om läsaren aldrig har träffat dig.
En MOAD-pipeline fungerar på detta sätt. Varje uppströms-merge bäddar in en fix i den kanoniska källkoden. Gravitationen sprider den: nedströms-forkar som uppdaterar sina beroenden ärver fixen. Patcharen kan glömmas bort; patchen överlever.
Kontrast: ett proprietärt SDK som underhålls av ett företag. Bakåtkompatibilitet upprätthålls eftersom företaget kontrollerar avvecklingsschemat. När företaget upplöses bryts alla nedströms-beroenden samtidigt. SDK:ets överlevnad krävde företagets överlevnad.
Ett öppet protokoll som underhålls av en gemenskap lever på obestämd tid. HTTP har överlevt varje företag som ursprungligen implementerade det. TCP/IP har överlevt sina ursprungliga designers. Git har överlevt dussintals konkurrerande versionshanteringssystem. Protokollet blir infrastruktur; infrastrukturen blir osynlig; osynlig infrastruktur blir permanent.
Vad gör att kod överlever sin författare:
- Permissiv eller public-domain-licens (ingen juridisk barriär för fortsättning)
- Omfattande dokumentation (framtida underhållare behöver inte den ursprungliga författaren)
- Godkänd testsvit med offentlig CI (nya underhållare kan verifiera sina ändringar)
- Stabil release taggad (nedströmsanvändare kan låsa en känd fungerande version)
- Underhållare-efterfrågan publicerad (communityn vet att hjälp behövs innan författaren försvinner)
- Arkitektur dokumenterad (strukturella beslut synliga för framtida återuppbyggare)
- Kod överförd till en organisation istället för ett personligt konto (GitHub-repon i personnamn dör med kontot; org-repon består)
Designing a Graceful Handoff
Scenario: du underhåller ett bibliotek som 50 nedströmsprojekt är beroende av. Du planerar att sluta underhålla det om 6 månader.
MOAD Gravity: Varför upstream-merge är viktigt
En MOAD-pipeline slutar med "upstream merge". Det steget förtjänar att undersökas.
En patch som bara tillämpas på en fork hjälper bara den forken. En patch som mergeas upstream sprids genom gravitation: varje nedströmsprojekt som uppdaterar sin beroende ärver fixen utan att veta om det. Ekosystemet läker sig självt som en bieffekt av vanliga versionsuppdateringar.
Gravitationsspridning kräver tre villkor: (1) fixen mergeas in i den kanoniska källan; (2) den kanoniska källan publicerar en release; (3) nedströmsprojekt uppdaterar sina beroendepinnar. Varje villkor kräver mänsklig handling. Gravitation sker inte automatiskt; den möjliggörs.
Kontrast: en säkerhetsfix som offentliggjorts men inte skickats uppströms. Forks som känner till den kan patcha manuellt. Forks som inte känner till den förblir sårbara. Ingen gravitation; endast manuell spridning. Kunskapen finns; den sprids inte.
En MOAD-pipelines åtagande: varje fel som åtgärdas får en uppströms-PR. Varje uppströms-PR följs upp tills den mergas. Avslöjande utan uppströms-PR är bara en halv patch.
Hammings ramverk gäller: ”plantera ekollonen.” PR:en är ekollonen. Uppströms-mergen startar klockan för gravitationens spridning. Patcharen kan glömmas bort; fixen överlever i den kanoniska grenen.
Avslutning: Infrastruktur som gåva
Hamming planterade ekollon. Hans föreläsningar överlever honom. Hans koder överlever honom. Hans studenter undervisar.
Russell Ballestrini planterade ekollon. Hans ago-bibliotek kör utan honom. Hans permacomputer-essäer cirkulerar. Unhomeschool kör på den infrastruktur han designade.
En MOAD-pipeline planterar ekollon. Varje uppströms merge sår en fix i den kanoniska källkoden. Gravitationen sprider den. Framtida versioner av projekt som aldrig hört talas om den ursprungliga patcharen kör renare kod tack vare arbete som görs idag.
Permacomputer-design är inte altruism. Det är god ingenjörskonst. Ett system som kräver att dess skapare består är bräckligt. Ett system som är designat för att överleva sin skapare är robust. Designvalet kostar inget extra vid konstruktionstillfället; det kräver bara avsikt.
Infrastruktur som gåva: inte i sentimental mening, utan i teknisk mening. En gåva består efter givandet. Kod under en tillåtande licens, dokumentation skriven för nästa underhållare, tester som körs i offentlig CI: dessa är gåvor i teknisk mening. De består. De växer. De överlever.
Hammings sista fråga till sina studenter: 'Vad gör du som kommer att spela roll om 20 år?' Permacomputer-svaret: allt du placerar på ett golv som håller.