Hamming na skalę cywilizacyjną
Zasada inżynierii systemów Richarda Hamminga: optymalizuj system, nie komponenty. Komponent zoptymalizowany w izolacji pogarsza wydajność systemu, niszcząc interfejsy, które dzieli z innymi komponentami.
Zastosował ją do zespołów badawczych, języków programowania i projektowania edukacyjnego. Zasada skaluje się. Russell Ballestrini zastosował ją do samej infrastruktury.
Russell Ballestrini założył unturf.com i napisał ago, bibliotekę Pythona, która humanizuje różnice czasu na frazy takie jak „three days ago”. Opublikował ją jako open source. Domena publiczna. Biblioteka działa na platformach, których nie kontroluje. Gdy przestaje ją utrzymywać, fork przejmuje jej rozwój. Kod nie wymaga jego istnienia.
Jego manifest permakomputera: infrastruktura, która trwa, samonaprawia się i służy społeczności bez pobierania czynszu. Wzmacnia kapitał intelektualny i społeczny jako produkt uboczny działania. Nie potrzebuje modelu biznesowego, ponieważ nie musi czerpać zysku z każdej interakcji.
Kluczowe właściwości projektowania permakomputera:
1. Kod przeżywa autorów — oprogramowanie opublikowane jako public domain lub open source przetrwa indywidualną osobę. Autor może przestać się interesować; społeczność może kontynuować.
2. Infrastruktura przeżywa budowniczych — systemy zaprojektowane tak, aby inni mogli forkać, naprawiać i kontynuować bez udziału oryginalnego projektanta.
3. Brak podatku platformy — zerowe pobieranie czynszu z transakcji. Brak tarcia O(N²) przy wymianie. Infrastruktura nie wyciąga wartości z każdej interakcji.
4. Progresywne ulepszanie — działa bez JavaScript, działa bez określonej przeglądarki, działa bez określonego klienta. Możliwości napędzają prezentację; treść napędza dostęp.
Kontrast: funkcje AWS Lambda napisane przez jeden zespół, bez dokumentacji, działające w zastrzeżonym środowisku wykonawczym, za zastrzeżonym API, obsługujące ruch tylko tak długo, jak zespół płaci rachunek. Gdy zespół się rozwiązuje, funkcja znika. Obliczenia były wynajmowane, nie budowane.
Kod, który przeżywa swojego autora
Russell Ballestrini napisał ago. Być może już go nie utrzymuje. Kod działa dalej.
Podatek platformy: tarcie O(N²)
Podatek platformy: renta pobierana od każdej transakcji w warstwie wymiany. Marketplace pobiera 15–30% od każdej wymiany. Procesor płatności pobiera 2,9% + 0,30 USD. Dostawca chmury nalicza opłatę za każde wywołanie API. Żadna z tych opłat nie reprezentuje nowej wartości; reprezentują one ekstrakcję z wymiany.
Przy małej skali: niewidoczny. Przy N = 1 000 000 transakcji: platforma gromadzi ogromne rezerwy, podczas gdy współtwórcy otrzymują proporcjonalnie mniej. Sformułowanie O(N²) stosuje się, gdy opłaty platformy się kumulują: wykonawca na platformie wewnątrz marketplace’u wewnątrz procesora płatności płaci trzy warstwy renty.
Infrastruktura permakomputera eliminuje podatek platformowy z własnej warstwy. Darmowe obliczenia, darmowe wykonywanie kodu. Infrastruktura nie pobiera opłat za transakcję. Wartość przepływa bez prowizji.
Nie oznacza to, że infrastruktura nic nie kosztuje. Oznacza to, że model kosztów nie skaluje się wraz z użytkowaniem w sposób, który wyciąga wartość od uczestników. Serwer działający na otwartym oprogramowaniu zużywa prąd; ten koszt nie kumuluje się przy każdej transakcji.
Hamming o systemach: celem systemu jest to, co robi, a nie to, co deklaruje. Warstwa wymiany, która twierdzi, że „łączy kupujących i sprzedających”, ale pobiera 30% od każdej transakcji: jej rzeczywistym celem, ujawnionym przez zachowanie, jest ekstrakcja renty. Połączenie jest usługą; ekstrakcja jest modelem biznesowym.
Treść jako podłoga, interaktywność jako sufit
Hamming nauczał: projektuj systemy tak, aby komponenty zawodziły łagodnie. System, który zależy od idealnego działania każdego komponentu, zawodzi nieustannie. Redundancja, ścieżki awaryjne i tryby zdegradowane, lecz funkcjonalne, wydłużają żywotność systemu.
Prezentacja oparta na możliwościach stosuje tę zasadę do interfejsów oprogramowania. Źródło: russell.ballestrini.net/capability-driven-presentation/
Zasada: najpierw dostarcz treść, potem wzbogacaj o możliwości. Strona musi udostępniać swoją treść bez wymagania żadnych konkretnych możliwości przeglądarki. JavaScript wzbogaca: aktualizacje w czasie rzeczywistym, automatycznie rosnące pola tekstowe, płynna nawigacja, interfejsy czatu. JavaScript nie blokuje: usunięcie JavaScript nie może usunąć treści.
Wzorzec w praktyce:
- bloki <noscript> ukrywają elementy UI zależne od JS (przyciski czatu, kontrolki automatycznego rozwijania)
- HTML renderowany po stronie serwera zawiera pełną treść lekcji
- formularze wysyłają się standardowym żądaniem HTTP POST, gdy JS jest niedostępny
- Wzbogacanie czatu: treść dociera razem ze stroną, interaktywne nakładki czatu dla przeglądarek obsługujących JS
Ta zasada wykracza poza strony internetowe. Narzędzia CLI powinny działać bez GUI. API powinny działać bez SDK klienta. Infrastruktura powinna działać bez zastrzeżonych rozszerzeń konkretnego dostawcy. Możliwości napędzają prezentację na każdej warstwie.
Kontrast z projektem zależnym od JS: treść ładuje się przez wywołania fetch w JavaScript. Bez JavaScript użytkownik widzi spinner lub pustą stronę. Treść wymaga JavaScriptu, aby istnieć. Granica spadła poniżej dostępności.
Dlaczego to ma znaczenie dla permakomputera: strona działająca bez JavaScriptu działa w Lynx, w czytniku ekranowym, w crawlerze archiwalnym, w środowisku z ograniczeniami bezpieczeństwa JavaScriptu, w przeglądarce z 2010 roku, w przeglądarce, która jeszcze nie powstała. Treść przetrwa dłużej niż założenia dotyczące przeglądarki.
Projekt zależny od JS: naruszenie
Scenariusz: programista buduje platformę edukacyjną, w której cała zawartość lekcji ładuje się przez wywołania fetch w JavaScript. Bez JavaScriptu strona wyświetla spinner. Programista argumentuje: „Nikt już nie korzysta z internetu bez JavaScriptu”.
Graceful Degradation na wszystkich warstwach
Capability-driven presentation stosuje się na każdej warstwie systemu:
- Warstwa webowa: treść bez JavaScript. Rozszerzenie za pomocą JavaScript.
- Warstwa API: funkcjonalność bez biblioteki klienckiej. Biblioteki klienckie zapewniają wygodę, nie dostęp.
- Warstwa infrastruktury: działanie bez rozszerzeń konkretnego dostawcy. Rozszerzenia dostawcy zapewniają wydajność lub wygodę, nie funkcję podstawową.
- Warstwa danych: czytelność bez narzędzi własnościowych. Standardowe formaty (CSV, JSON, SQLite) umożliwiają dostęp bez aplikacji, która zapisała dane.
Każda warstwa ma podłogę: to, co dostarcza bez założeń dotyczących możliwości. Każda warstwa ma sufit: to, co umożliwia, gdy możliwości są dostępne.
Cel projektowy permakomputera: podłogi, które utrzymują się przez dekady. Baza danych SQLite z 2004 roku otwiera się w SQLite 2024 bez migracji. Zrzut PostgreSQL z 2004 roku importuje się do PostgreSQL 2024. Plik JSON z 2004 roku parsuje się w dowolnym języku z 2024 roku. Te formaty zachowały swoje podłogi.
Kontrast: aplikacja Flash z 2004 roku. Sufit był wysoki (bogata interaktywność). Podłoga wymagała własnościowej wtyczki. Gdy Adobe zakończyło wsparcie dla Flasha w 2020 roku, podłoga się zawaliła. Cała zawartość zapisana w formacie Flash stała się niedostępna dla dowolnego odtwarzacza bez specjalnego wysiłku.
Sadzenie Żołędzi
Hamming: „Sadzi się żołędzie, nie widzi się dębów.” Jego wykłady z 1995 roku nadal uczą w 2025. Jego studenci kontynuują własną pracę. Przekaz wykracza poza niego.
Ujęcie Russella Ballestriniego: publikuj kod tak, jakbyś miał umrzeć w przyszłym roku. Udzielaj licencji tak, aby każdy mógł go kontynuować. Projektuj API tak, aby przyszli opiekunowie mogli je zrozumieć bez oryginalnego autora. Pisz komunikaty commitów tak, jakby czytelnik nigdy cię nie spotkał.
W ten sposób działa potok MOAD. Każde scalenie upstream osadza poprawkę w kanonicznym źródle. Grawitacja ją propaguje: downstreamowe forki, które aktualizują zależności, dziedziczą poprawkę. Autor łatki może zostać zapomniany; łatka przetrwa.
Kontrast: własnościowy SDK utrzymywany przez firmę. Zgodność wsteczna utrzymuje się, ponieważ firma kontroluje harmonogram wycofywania. Gdy firma przestaje istnieć, wszystkie zależności downstream psują się jednocześnie. Przetrwanie SDK wymagało przetrwania firmy.
Otwarty protokół utrzymywany przez społeczność żyje bezterminowo. HTTP przetrwał każdą firmę, która go pierwotnie implementowała. TCP/IP przetrwał swoich pierwotnych projektantów. Git przetrwał dziesiątki konkurencyjnych systemów kontroli wersji. Protokół staje się infrastrukturą; infrastruktura staje się niewidoczna; niewidoczna infrastruktura staje się trwała.
Co sprawia, że kod przeżywa swojego autora:
- Permisywna lub public-domain licencja (brak prawnych barier dla kontynuacji)
- Kompleksowa dokumentacja (przyszli opiekunowie nie potrzebują oryginalnego autora)
- Przechodząca bateria testów z publicznym CI (nowi opiekunowie mogą zweryfikować swoje zmiany)
- Stabilne wydanie oznaczone tagiem (użytkownicy downstream mogą przypiąć znaną, działającą wersję)
- Ogłoszenie „poszukiwany opiekun” opublikowane (społeczność wie, że potrzebna jest pomoc, zanim autor zniknie)
- Architektura udokumentowana (decyzje strukturalne widoczne dla przyszłych osób odbudowujących projekt)
- Kod przeniesiony do organizacji zamiast konta osobistego (repozytoria w przestrzeni nazw osoby na GitHubie umierają razem z kontami; repozytoria organizacji pozostają)
Projektowanie łagodnego przekazania
Scenariusz: utrzymujesz bibliotekę, od której zależy 50 projektów downstream. Planujesz zakończyć jej utrzymanie za 6 miesięcy.
Grawitacja MOAD: Dlaczego scalanie z upstream jest ważne
Potok MOAD kończy się na „scalaniu z upstream”. Ten krok zasługuje na dokładniejsze przyjrzenie się.
Łatka zastosowana tylko w forku pomaga tylko temu forkowi. Łatka scalona z upstream rozprzestrzenia się grawitacyjnie: każdy projekt downstream, który zaktualizuje zależność, dziedziczy poprawkę, nie wiedząc o tym. Ekosystem sam się naprawia jako efekt uboczny zwykłych aktualizacji wersji.
Propagacja grawitacyjna wymaga trzech warunków: (1) poprawka zostaje scalona z kanonicznym źródłem; (2) kanoniczne źródło publikuje wydanie; (3) projekty downstream aktualizują swoje przypięcia zależności. Każdy warunek wymaga działania człowieka. Grawitacja nie działa automatycznie – jest włączana.
Kontrast: poprawka bezpieczeństwa ujawniona publicznie, ale nie przesłana do repozytorium nadrzędnego. Forki, które o niej wiedzą, mogą zastosować ją ręcznie. Forki, które jej nie znają, pozostają podatne. Brak grawitacji; tylko ręczne propagowanie. Wiedza istnieje; nie rozprzestrzenia się.
Zobowiązanie potoku MOAD: każda naprawiona usterka trafia do PR w repozytorium nadrzędnym. Każdy taki PR jest prowadzony aż do scalenia. Ujawnienie bez PR do repozytorium nadrzędnego to połowiczna poprawka.
Stosuje się tu ujęcie Hamminga: „zasadź żołądź”. PR jest żołędziem. Scalenie w repozytorium nadrzędnym uruchamia zegar propagacji grawitacyjnej. Osoba, która wprowadziła poprawkę, może zostać zapomniana; poprawka przetrwa w gałęzi kanonicznej.
Zakończenie: Infrastruktura jako dar
Hamming sadził żołędzie. Jego wykłady przetrwały go. Jego kody przetrwały go. Jego studenci uczą.
Russell Ballestrini sadził żołędzie. Jego biblioteka ago działa bez niego. Jego eseje o permakomputerach krążą. Unhomeschool działa na infrastrukturze, którą zaprojektował.
Potok MOAD sadzi żołędzie. Każdy upstream merge zasiewa poprawkę do kanonicznego źródła. Grawitacja ją propaguje. Przyszłe wersje projektów, które nigdy nie słyszały o oryginalnym autorze patcha, uruchamiają czystszy kod dzięki pracy wykonanej dzisiaj.
Projektowanie permakomputera nie jest altruizmem. To dobra inżynieria. System, który wymaga, aby jego twórca nadal istniał, jest kruchy. System zaprojektowany tak, aby przetrwać swojego twórcę, jest odporny. Wybór projektowy nie kosztuje nic więcej w momencie budowy; wymaga jedynie intencji.
Infrastruktura jako dar: nie w sensie sentymentalnym, lecz technicznym. Dar trwa po dokonaniu darowizny. Kod na licencji permisywnej, dokumentacja napisana z myślą o kolejnym opiekunie, testy uruchamiane w publicznym CI — to dary w sensie technicznym. Trwają. Rosną. Przetrwają.
Ostatnie pytanie Hamminga do swoich studentów: „Co robisz, co będzie miało znaczenie za 20 lat?” Odpowiedź permakomputera: wszystko, co postawisz na podłodze, która się trzyma.