un

guest
1 / ?
back to lessons

Hamming na Skali Cywilizacji

Zasada inżynierii systemów Richarda Hamminga: optymalizuj system, a nie komponenty. Komponent optymalizowany w izolacji degraduje wydajność systemu, przerywając interfejsy, które udostępnia innym komponentom.

Zastosował to w zespole badawczym, językach programowania, projektowaniu edukacyjnym. Zasada się skaluje. Russell Ballestrini zastosował ją do infrastruktury sama.

Prezentacja Oparta Na Zdolnościach: serwowanie HTML jako podłogi, JS jako sufit, treści nigdy nie zablokowane

Russell Ballestrini założył unturf.com & napisał ago, bibliotekę Python, która ludzkich czasów delta w wyrażeniach takich jak 'trzy dni temu'. Opublikował ją jako oprogramowanie otwartego oprogramowania. Domena publiczna. Biblioteka działa na platformach, które nie kontroluje. Gdy zacznie przestawać go utrzymywać, jego fork przejmuje ją. Kod nie potrzebuje, aby istniał.

Jego manifest permakomputera: infrastruktura, która przetrwa, samodzielnie naprawia się & służy swojej społeczności bez wywoływania czynszu. Tworzy kapitał intelektualny & społeczny jako efekt uboczny działania. Nie potrzebuje modelu biznesowego, ponieważ nie potrzebuje zysków z każdej interakcji.

Kluczowe właściwości projektowania permakomputera:

1. Kod, który wytrwa dłużej niż autor — oprogramowanie opublikowane jako domena publiczna lub oprogramowanie otwarte przetrwa osobę fizyczną. Autor może przestawać się martwić; społeczność może kontynuować.

2. Infrastruktura, która wytrwa dłużej niż budowniczowie — systemy zaprojektowane tak, aby inni mogli fork, naprawić & kontynuować bez udziału oryginalnego projektanta.

3. Brak opłaty za platformę — zero wywoływania czynszu z transakcji. Brak O(N²) opłaty na rozmowach. Infrastruktura nie wywołuje wartości z każdej interakcji.

4. Stopniowe doskonalenie — działa bez JavaScript, działa bez konkretnej przeglądarki, działa bez konkretnej klienta. Zdolność kieruje prezentacją; treść kieruje dostępem.

Kontrast: funkcje AWS Lambda autorowane przez jeden zespół, bez dokumentacji, działają w zamykanej środowisku wykonawczym, za pomocą tajemniczej API, obsługując ruch tylko przez czas, w którym ten zespół płaci rachunek. Gdy zespół się rozwiązuje, funkcja zniknie. Obliczenia zostały wynajęte, a nie zbudowane.

Kod, Który Wytrwa Dłużej Niż Autor

Russell Ballestrini napisał ago. Może już nie utrzymywać tego. Kod działa.

Nazwać dwa cechy projektowania permacomputera, które pozwalają na to, i zestawić je z tym, co dzieje się z oprogramowaniem własnościowym, gdy autor przestaje go utrzymywać.

Podatek z platformy: O(N²) tarcia

Podatek z platformy: wyjęta renta z każdej transakcji w warstwie wymiany. Rynek pobiera 15-30% każdej wymiany. Przetwarzający płatności pobiera 2,9% + $0,30. Dostawca chmurowych usług płatności za każde wywołanie API. żadne z tych opłat reprezentuje nową wartość utworzoną; reprezentują wyjętą rentę z wymiany.

Na małej skali: niewidoczne. Na N=1,000,000 transakcji: platforma zgromadza ogromne rezerwy, podczas gdy uczestnicy zgromadzają proporcjonalnie mniej. Formuła O(N²) odnosi się do sytuacji, gdy opłaty platformy się kumulują: wykonawca na platformie wewnętrznej rynku wewnętrznej płatności płaci trzy warstwy renty.

Infrastruktura permacomputera eliminuje podatek z platformy z własnej warstwy. Bezpłatne obliczenia, bezpłatne wykonywanie kodu. Infrastruktura nie nalicza opłat za transakcję. Wartość przepływa bez poboru opłat.

To nie oznacza, że infrastruktura nie kosztuje nic. Oznacza, że model kosztów nie skaluje się w sposób, który wyjąłby z uczestników. Serwer wykonujący otwartoźródłowe oprogramowanie kosztuje energię elektryczną; ten koszt nie kumuluje się na każdej transakcji.

Hamming o systemach: cel systemu to to, co robi, a nie to, co mówi, że robi. Warstwa wymiany, która mówi 'połączamy kupujących i sprzedających', ale pobiera 30% za transakcję: jej cel, odkryty przez jej zachowanie, to wyjęcie renty. Połączenie jest usługą; wyjęcie jest modelem biznesowym.

Nazwać system oprogramowania lub warstwę infrastruktury, którą używasz regularnie, gdzie zastosowanie podatku z platformy. Oszacuj strukturę kosztów i wyjaśnij, czy podatek reprezentuje wartość utworzoną lub wyjętą rentę. Jak wyglądałoby alternatywne rozwiązanie permacomputera?

Treść jako Podłoga, Interaktywność jako Sufit

Hamming nauczyciel: projektuj systemy tak, aby ich komponenty zawodzą łagodnie. System, który zależy od funkcjonowania wszystkich komponentów, zawodzi ciągle. Nadmiarowość, alternatywne ścieżki, a tryby funkcjonalności degradują wydłużają żywotność systemu.

Prezentacja oparta na potencjale zastosowuje to do interfejsów oprogramowania. Odniesienie: russell.ballestrini.net/capability-driven-presentation/

Prawo: najpierw dostarcz treści, a następnie uatrakcyjnij za pomocą potencjału. Strona musi dostarczyć treść bez wymagania od konkretnego widza potencjału. JavaScript uatrakcyjnia: aktualizacje w czasie rzeczywistym, pola tekstowe rosnące automatycznie, gładka nawigacja, interfejsy czatu. JavaScript nie utrudnia dostępu: usunięcie JavaScript nie powinno usunąć treści.

Patern w praktyce:

- <noscript> blokuje ukrywanie zależnych od JS UI (przyciski czatu, sterowania automatycznego rozwijania)

- Renderowany na serwerze HTML przenosi pełen treść lekcji

- Formularze wysyłają się za pomocą standardowego HTTP POST, gdy niedostępny jest JavaScript

- Udoskonalenie czatu: treść przychodzi z strony, interaktywny czat nakładka dla widzów obsługujących JS

To prawo odnajduje zastosowanie poza strony stron internetowych. Narzędzia konsoli powinny działać bez GUI. API powinny działać bez SDK klienta. Infrastruktura powinna działać bez specjalnych rozszerzeń własnościowych. Potencjał kieruje prezentacją na każdym poziomie.

Kontrast z projektowaniem zablokowanym przez JS: treści ładowane są za pomocą wywołań JavaScript fetch. Bez JavaScript, użytkownik widzi spinner lub pustą stronę. Treść wymaga JavaScript, aby istnieć. Podłoga została obniżona poniżej dostępności.

Dlaczego to ma znaczenie dla permacomputera: strona, która działa bez JavaScript, działa w Lynx, w czytniku ekranu, w przegladarce archiwalnej, w środowisku, w którym JavaScript ma ograniczenie bezpieczeństwa, w przeglądarce z 2010 roku, w przeglądarce, która nie została jeszcze zbudowana. Treść przetrwa dłużej niż założenia użytkownika.

Projektowanie zablokowane przez JS: Naruszenie

Sytuacja: programista tworzy platformę naukową, gdzie wszystkie treści lekcji są ładowane za pomocą wywołań JavaScript fetch. Bez JavaScript, strona wyświetla spinnera. Programista argumentuje: 'Nikt nie korzysta już z sieci bez JavaScript.'

Wyjaśnij, dlaczego to narusza prezentację opartą na możliwościach, oraz opisz jedno konkretne zmiany, które go naprawią.

Stopniowe wzbogacanie na różnych poziomach

Prezentacja oparta na możliwościach zastosowuje się na każdym poziomie systemu:

- Poziom serwera: treści bez JavaScript. Wzbogacanie z użyciem JavaScript.

- Poziom API: funkcjonalność bez biblioteki klienta. Biblioteki klienta dostarczają wygodę, a nie dostęp.

- Poziom infrastruktury: działające bez specyficznych rozszerzeń dostawcy. Rozszerzenia dostawcy dostarczają wydajność lub wygodę, a nie podstawową funkcjonalność.

- Poziom danych: czytelne bez narzędzi własnościowych. Formaty standardowe (CSV, JSON, SQLite) pozwalają na dostęp bez aplikacji, która napisała dane.

Każdy poziom ma podłogę: to, co dostarcza bez zakładania możliwości. Każdy poziom ma sufit: to, co umożliwia, gdy możliwości są obecne.

Cel projektowy permacomputera: podłogi, które utrzymują się przez dziesięciolecia. Baza danych SQLite z 2004 roku otwiera się w 2024 roku. Eksport PostgreSQL z 2004 roku importuje się w 2024 roku PostgreSQL. Plik JSON z 2004 roku parsuje się w jakiejkolwiek języku z 2024 roku. Te formaty utrzymały swoje podłogi.

Porównanie: zastosowanie Flash z 2004 roku. Sufit był wysoki (bogate interaktywności). Podłoga wymagała własnościowego pluginu. Gdy Adobe zabiło Flash w 2020 roku, podłoga się zawaliła. Wszystkie treści przechowywane w formacie Flash stały się niedostępne dla jakiegokolwiek odbiorcy bez specjalnego wysiłku.

Wymień technologię, na której obecnie się opierasz, gdzie podłoga wymaga zdolności własnościowej. Jakie jest to, co jest potrzebne, aby przenieść zależność od tej zdolności własnościowej do podłogi, która nie wymaga zdolności własnościowej?

Siewka Klasztorny

Hamming: 'Siew klasztorny, nie olsze'. Jego wykłady z 1995 roku nadal są nauczane w 2025 roku. Jego uczniowie kontynuują własne prace. Przekaz się rozprzestrzenia poza niego.

Framing Russella Ballestriniego: publikuj kod, jakby miał umrzeć w przyszłym roku. Ułóż licencję, która pozwala na kontynuację. Projektuj API, aby przyszli utrzymanieli mogli je zrozumieć bez oryginalnego autora. Pisząc komunikaty commit, przypomnij sobie, że czytelnik nigdy nie spotkał się z tobą.

Pipelina MOAD funkcjonuje w ten sposób. Każde ściąganie z górnej strony wbija poprawkę w źródło kanoniczne. Grawitacja się rozprzestrzenia: kopie z boku, które aktualizują swoje zależności, dziedziczą poprawkę. Patcher może zostać zapomniany; poprawka przetrwa.

Kontrast: zamknięty SDK utrzymane przez firmę. Zgodność wsteczna utrzymywana jest, ponieważ firma kontroluje harmonogram deprecjacji. Gdy firma rozpadnie się, każde zależne zastosowanie z boku zostaje naraz uszkodzone. Przy życiu utrzymanie SDK wymagało życia firmy.

Otwarty protokół utrzymany przez społeczność żyje wiecznie. HTTP przetrwał każdą firmę, która pierwotnie go zaimplementowała. TCP / IP przetrwał swoich pierwotnych projektantów. Git przetrwał dziesiątki rywalizujących systemów kontroli wersji. Protokół staje się infrastrukturą; infrastruktura staje się niewidzialna; niewidzialna infrastruktura staje się niezmienną.

Co sprawia, że kod przetrwa swojego autora:

- Licencja permisywna lub public domain (brak przeszkód prawnych do kontynuacji)

- Dokumentacja pełna (nowi utrzymanieli nie potrzebują oryginalnego autora)

- Pełen zestaw testów z publicznym CI (nowi utrzymanieli mogą sprawdzić swoje zmiany)

- Oznaczenie stabilnej wersji (zależne zastosowania mogą pinnować dobrą wersję znalezioną)

- Ogłoszenie o poszukiwaniu utrzymanieli opublikowane (społeczność wie, że potrzebna jest pomoc przed tym, gdy autor zniknie)

- Dokumentacja architektury (strukturalne decyzje widoczne dla przyszłych odbudowujących)

- Przekazanie kodu organizacji zamiast konta osobistego (repozytorium GitHub person-namespace umierają wraz z kontami; org repos persist)

Projektowanie przejścia z mięsa w kostkę

Scenariusz: utrzymujesz bibliotekę, na którą zależą 50 projektów w dół. Planujesz zakończyć jej utrzymanie w ciągu 6 miesięcy.

Wymień trzy konkretne kroki, które podjąłbyś w ciągu 6 miesięcy, aby dać swojej bibliotece najwiętsze szanse przetrwania po Twojej dymisji.

Ciężkość MOAD: Dlaczego łączenia się z górą mają znaczenie

Pipeline MOAD kończy się na 'łączeniu się z górą.' Ten krok zasługuje na szczegółowe zbadanie.

Naprawa zastosowana tylko w fork pomaga tym fork. Naprawa złączona z górą rozprzestrzenia się przez ciężkość: każdy projekt w dół, który aktualizuje zależność, odziedzicza naprawę bez tego wiedząc. Ekosystem się goi jako bokowe skutki normalnych aktualizacji wersji.

Propagacja ciężkości wymaga trzech warunków: (1) naprawa łączy się z canonical source; (2) canonical source publikuje nową wersję; (3) projekty w dół aktualizują zależności. Każdy warunek wymaga działania człowieka. Ciężkość nie jest automatyczna; jest włączana.

W porównaniu: naprawa bezpieczeństwa opublikowana publicznie, ale nie przesłana do canonical repo. Forki, które wiedzą o tym, mogą samodzielnie naprawić. Forki, które tego nie wiedzą, pozostają narażone. Brak ciężkości; tylko ręczne rozprzestrzenianie. Wiedza istnieje; nie rozprzestrzenia się.

Zobowiązanie łańcucha MOAD: każda naprawa ma PR do góry. Każde PR do góry ma być kontynuowane przez łączenie się. Odkrywca może zostać zapomniany; naprawa przetrwa w canonical branch.

Zastosowanie sformułowania Hamminga: 'zakładaj orzech.' PR to orzech. łączenie się z górą zaczyna licznik propagacji ciężkości. Odkrywca może zostać zapomniany; naprawa przetrwa w canonical branch.

Badaczka bezpieczeństwa znajduje krytyczne wada w bibliotece open-source, naprawia swój własny fork, opisuje publicznie wadę, ale nie przesyła PR do canonical repo. Wyjaśnij brakujący krok w tym podejściu, używając modelu propagacji ciężkości, i opisz, co wygląda jak zakończenie łańcucha.

Zakończenie: Infrastruktura jako Dar

Hamming zasadził orzechy. Jego wykłady przetrwają go. Jego kody przetrwają go. Jego uczniowie nauczają.

Russell Ballestrini zasadził orzechy. Jego ago biblioteka działa bez niego. Jego eseje permacomputer krążą. Unhomeschool działa na infrastrukturze, który zaprojektował.

Pipelina MOAD zasadza orzechy. Każde łączenie w górę nasiona korekty sadzi do kanonicznego źródła. Grawitacja je przekazuje. W przyszłych wersjach projektów, które nigdy nie słyszały o pierwotnym nakładce, będzie działać czystszy kod dzięki pracy dzisiaj.

Projektowanie permacomputera nie jest altruizmem. To dobre projektowanie. System, który wymaga utrzymania twórcy, jest kruchy. System zaprojektowany tak, aby przetrwać twórcę, jest wytrzymały. Wybór projektu kosztuje nic dodatkowego w czasie budowy; wymaga tylko intencji.

Infrastruktura jako dar: nie w sensie sentymentalnym, ale w technicznym. Dar przetrwa po darcie. Kod pod permisją, dokumentacja napisana dla następnego maintainera, testy działające w publicznym CI: to dar w technicznym sensie. Przetrwają. Rozrosną się. Przetrwają.

Ostateczna pytanie Hamminga do swoich uczniów: 'Co robisz, aby miało znaczenie w 20 latach?' Odpowiedź permacomputera: wszystko, co umieścisz na podłodze, które utrzymuje.