An approach to computing and sustainability inspired from permaculture — Strange Loop 2023¶

Előadó: Devine Lu Linvega (Hundred Rabbits) | Dátum: 2023-09-22 | Hossz: ~55 perc

Összegzés¶

Devine Lu Linvega, a Hundred Rabbits design- és kutatóstúdió társtulajdonosa egy egészen szokatlan perspektívából közelíti meg a számítástechnikát: egy 33 láb hosszú vitorláson él párjával immár kilenc éve, és ebből a szélsőségesen korlátozott környezetből — négy darab 6 voltos akkumulátor, 200 watt napelem, szűkös vízkészlet — gondolja újra, mit is jelent fenntartható módon programozni. Az előadás központi metaforája Saint-Exupéry rókája, amelyik minden bokorról csak egy bogyót eszik, hogy egyik bokor se pusztuljon ki — szemben a modern szoftverfejlesztés "mindent azonnal" mentalitásával.

Linvega nem akadémikus, hanem illusztrátor, zenész és autodidakta programozó, aki saját bevallása szerint is "szörnyű programozó" — viszont éppen ez a kívülállóság ad neki szabadságot arra, hogy radikálisan más szemmel nézzen a számítógépekre. Az előadás három pilléren nyugszik: a komplexitás definícióján (a lehető legkevesebb utasítás, szabály és kivétel egy adott állapot eléréséhez), az elegancia mint "a hiány értékének megfogalmazása" fogalmán, és a szabotázs mint "a hatékonyság visszavonása" gondolatán — vagyis amikor tudatosan lassítunk, hogy a rendszer emberi léptékű és érthető maradjon.

Az előadás lényege, hogy a szoftver nem egy letölthető app, hanem egy probléma megértésének és megoldásának teljes íve — és ha ezt elveszítjük, ha kész megoldásokat vásárolunk Stack Overflow-ról anélkül hogy a mögöttes tudást birtokolnánk, akkor a tudás vákuumát hozzuk létre. Linvega szerint a megoldás nem a "scale up" (több akkumulátor, gyorsabb gép), hanem a "scale down": saját, minimális virtuális gép építése, amely pontosan akkora, amekkora a megoldandó problémához kell — és amelyet a jövőbeli önmagunk is képes újraimplementálni.

Főbb Témák¶

Permakultúra a számítástechnikában¶

Az előadás címe szándékosan provokatív és homályos — Linvega maga is bevallja, hogy húsz iteráció után már ő sem tudta pontosan, mit jelent. A "fenntarthatóság" alatt nem a környezetvédelmi klisét érti, hanem egy gyakorlat fenntartásának képességét: azt, hogy hosszú távon képesek legyünk ugyanazt a tevékenységet folytatni. A "permakultúra" pedig egy olyan rendszer metaforája, amely erősíti az ökoszisztémát, ahelyett hogy kizsigerelné.

Ez a megközelítés éles ellentétben áll a modern szoftverfejlesztés "solution shopping" mentalitásával, ahol az emberek kész megoldásokat vásárolnak anélkül, hogy értenék a probléma teljes ívét. Linvega szerint a "just use library function X" típusú Stack Overflow-válaszok nem hordozható tudást eredményeznek, és a tudás fokozatos eltűnéséhez vezetnek. A mítosz, miszerint "óriások vállán állunk", valójában azt jelenti, hogy olyan magasan vagyunk, hogy onnan már lehetetlen kormányozni.

A vitorlás mint kutatólaboratórium¶

Linvega és párja, Rekka kilenc éve élnek egy 33 láb (~10 méter) hosszú vitorláson. Ez a környezet kíméletlenül láthatóvá teszi a korlátokat — nincs elrejtve a hulladék, a melléktermék, az energiafogyasztás. A hajón négy 6 voltos akkumulátor és körülbelül 200 watt napelem áll rendelkezésre — ezek kemény határok. És bár az ember első ösztöne az lenne, hogy "tegyünk még hozzá" (több vizet, több napelemet), egy hajón ennek azonnali ára van: több napelem = nagyobb szélfogás = nagyobb eséllyel borul fel a hajó; több víztartály = lassabb mozgás = nehezebb elmenekülni a viharok elől. Minden trade-off.

Amikor a tengerre költöztek, megpróbálták replikálni a szárazföldi életüket: iOS fejlesztés, 3D játékok — és az egész gyorsan összeomlott, mert a modern fejlesztői toolchain egyszerűen lemerítette az akkumulátoraikat. Felmerült, hogy a számítógépek talán alapvetően összeegyeztethetetlenek a nomád életmóddal. Ehelyett azonban elkezdték visszafelé követni a számítástechnika történetét, hogy megtalálják azt a pontot, ahol a rendszerek még kompatibilisek az ő korlátaikkal.

A feledésbe merült számítástechnika¶

Az előadás egyik legmeghökkentőbb állítása, hogy a technológiatörténet tele van kiváló ötletekkel, amelyek nem azért tűntek el, mert rosszak voltak, hanem társadalmi dinamika és politika miatt. Linvega szerint nincsenek számítástechnika-történet órák, és ez mítoszokat szül: az emberek azt hiszik, az eltűnt technológiák azért haltak ki, mert rosszak voltak, pedig ez szinte soha nem igaz.

Konkrét példák: - HyperCard: emulátorban gyorsabban futott és kevesebb akkumulátort fogyasztott, mint a natív modern rajzprogramok - Think Pascal: egy szinte elfeledett rendszer, amely arányos (nem monospace) betűtípust használt — Linvega annyira megszerette, hogy visszatérve a monospace fontokhoz hiányolta - IRC vs Slack: a Slack használhatatlan a hajón, az IRC viszont tökéletesen működik

A felismerés: "ami korábban működött, az még mindig létezik — csak megváltoztattuk az ökoszisztémát, amelyet célba veszünk". A régi szoftverek emulálhatók, beágyazhatók, továbbra is használhatók.

Szoftver-megőrzés: a sötét középkor küszöbén¶

Linvega sokkoló statisztikát idéz: a Video Game History Foundation szerint a 2010 előtt írt kereskedelmi játékok 87%-a ma már elérhetetlen. Ez a számítástechnika mint szakma kudarca — olyan emberek, akik egész felnőtt életüket egy játék megalkotására tették fel, öt évvel később már lejátszhatatlan. Ő maga is éveket töltött iOS játékok és Unity projektek fejlesztésével, amelyeket ma már ki sem tud nyitni. Minden alkalommal, amikor egy ökoszisztéma összeomlott, úgy érezte, kudarcot vallott — mert olyan komplex rendszert célzott meg, amit egyénileg képtelen lett volna reprodukálni, tehát a műve "nem is igazán az övé volt".

A helyzet iróniája, hogy még a megőrzéssel foglalkozó szakemberek is olyan platformokat használnak (Twitter/Mastodon), amelyek gyorsabban rohadnak el, mint ahogy meg tudnánk őrizni a tartalmaikat. Linvega egy általa használt PNG képről mesél, amelyet egy azóta törölt Mastodon-bejegyzésbe ágyaztak — még azok is, akiknek "jobban kellene tudniuk", ezeken a törékeny platformokon kommunikálnak.

A digitális megőrzés négy stratégiája: 1. Migráció (kód átportolása) 2. Emuláció (hardver implementálása szoftverben, pl. NES emulátor) 3. Enkapszuláció (pl. Docker) 4. UVM (Universal Virtual Machine) — a kezdetektől olyan célplatformot tervezni, amely könnyen újraimplementálható

Linvega az utóbbit részesíti előnyben.

Az Another World és a minimális virtuális gép¶

Az előadás egyik leginspirálóbb példája az Another World (Out of This World) nevű játék, amely egy mindössze ~20 opkódból álló virtuális gépre épült. A játék azért élte túl az évtizedeket, mert a VM specifikációja elérhető volt, visszafejtették, közkinccsé vált, és az emberek szórakozásból írnak hozzá emulátorokat — hiszen "olyan kicsi, hogy könnyű megírni". A játékot átportolták PICO-8-ra, és gyakorlatilag örökké fennmarad, mert az embereknek személyes érdekük fűződik hozzá, hogy kis emulátorokat írjanak.

Egy másik példa Alan Kay "chifir" számítógépe és a "Uniform Tablets of Computation" című tanulmány, amely egy szuper-kis virtuális gépet javasolt a Smalltalk-72 futtatásához. Bár valószínűleg soha nem implementálták, az ötlet — "olyan, mint az Another World, de Smalltalk-ra" — mély benyomást tett Linvegára.

Uxn: a saját virtuális gép¶

Linvega és párja saját virtuális gépet építettek, hogy minden projektjüket — játékot, weboldalt, dokumentációt, teljes toolchain-t — egyetlen, minimális rendszeren futtathassák. A cél: soha többé ne írjanak Unity játékot, és minden projektjük logikája egy vékony emulációs rétegen keresztül legyen átvihető más platformokra.

A tervezési döntések: - 32 opkód — egy bájton belül 5 bit az operációnak, 3 bit egyéb célokra - Stack machine — a Joy programozási nyelv és Chuck Moore (a Forth megalkotója) design-filozófiája inspirálta - Csak short és byte típusok — nincs float, nincs komplex adatszerkezet - Önhostolt — az assembler saját magában van megírva, ugyanazon a VM-en fut, mint a programok

Linvega hangsúlyozza, hogy nem a stack machine az egyetlen út — léteznek list machine-ek, tag machine-ek, interaction net-ek, Warren machine-ek —, de számukra ez volt a legkényelmesebb. A Joy nyelv "spaghetti stack" (konz-cellákból álló verem) megközelítése bizonyos műveleteket (pl. három elem forgatása mindössze három cím megváltoztatásával) rendkívül gyorssá tesz.

"Rossz" programozási nyelv tervezése¶

Linvega elutasította a "jó programozási nyelv" hagyományos kritériumait (felskálázhatóság, a nyelv mindig jobban tudja, divatos esztétika, könyvtárak és csomagkezelők), és szándékosan "rossz" nyelvet tervezett. Az ő kritériumai: - Egy-az-egyhez leképezés assembly-re — nincs fordító, nincs absztrakciós réteg; amit írsz, az pontosan az, ami fut - Kényelmes assembly — nem akart napi nyolc órában 6502 assembly-t írni, de nem is akart C-ben programozni; a cél egy olvasható, negyedik generációs-szerű szintaxis volt, amely közvetlenül assembly-re fordul

A nyelv érdekessége, hogy a hexadecimális értékek közvetlenül érvényes tokenek — "ez egy opkód, ami pontosan ezt a kimenetet produkálja".

Assembly szintű validáció és optimalizálás¶

Linvega olyan eszközöket épített az assembly szintjén, amelyekről sokan azt gondolják, hogy assembly-ben lehetetlenek:

Linter: két opkód kombinációját automatikusan felismeri és egyszerűsíti (pl. swap+pop = nip; jump+return = egyszerű jump vagy átrendezés, hogy a kód "átessen" a következő függvénybe)
Arity checking: bár nincsenek típusok, a verem mélységének változását ellenőrzi minden operátornál, és összeveti a deklarált elő- és utófeltétellel — ez nem erős típusellenőrzés, de rengeteg hibát elkap
Pure function ellenőrzés: a tiszta függvények (amelyeknek nincs mellékhatásuk a definíciójukon kívül) detektálása lehetővé teszi az összes I/O és kiszámíthatatlan művelet elkülönítését
Stack state assertion: a program bármely pontján deklarálható, hogy milyen állapotban kell lennie a veremnek

Ezek a validációs technikák azt demonstrálják, hogy assembly-ben is lehet viszonylag biztonságos programokat írni — csak más megközelítés kell.

Önmódosító kód mint minta, nem mint antipattern¶

A modern szoftverfejlesztésben az önmódosító kód tabu — a Harvard architektúra és a security best practice-ek évtizedek óta tiltják. Linvega ezzel szemben tudatosan "belehajolt" az önmódosításba, mert a Forth-ben a változók gyorsan globális állapothoz vezetnek, ami legalább annyira veszélyes.

Az ő megközelítése: - Értékek gyorsítótárazása magában a kódban — egy függvény belépési pontján a program "a saját jövőjébe írja" a szükséges értéket. Amikor a programszámláló később eléri ezt a pontot, az érték már ott van literálként beégetve, nincs szükség hat elem mélységből kihalászni a veremből - A verem hatodik eleménél valami baj van — ha idáig jutsz, rosszul tervezted a programot; az önmódosítás elegánsabb megoldás lehet - Biztonsági keretek — az arity checker biztosítja, hogy az önmódosító részeket más függvények ne módosíthassák

A számítógép mint alkotóeszköz, nem fogyasztási platform¶

Linvegát a számítógép mint alkotóeszköz érdekli — nem szolgáltatások, nem appok, hanem nyílt specifikációk és a saját szoftver megírásának tudása. Nem nevez meg technológiákat, mert nem eladni akar valamit, hanem arra biztat, hogy a hallgató írja meg a saját implementációját.

A "megoldások vásárlása" (solution shopping) tudásvákuumot hoz létre: amikor az emberek egyik megoldásról a másikra ugranak, anélkül hogy értenék a probléma "teljes történeti ívét", a mögöttes tudás eltűnik. A szoftver nem csak egy letölthető app — hanem magában foglalja a probléma megértését és megoldásának teljes narratíváját.

Smalltalk-80 és a komplexitás kézzelfogható skálája¶

Linvega lenyűgöző viszonyítási pontot talált: a Smalltalk-80 körülbelül 12 kilobájt kód, és a Blue Book szerint egy emberév munka implementálni. Ez egy kézzelfogható komplexitás-index. Innen kiindulva érdemes feltenni a kérdést: milyen egy "egy hetes számítógép"? Vagy egy "egy hónapos számítógép"?

A cél egy olyan rendszer tervezése, amelyet a jövőbeli önmagunk is képes újraimplementálni — ez az igazi elegancia és fenntarthatóság mércéje. Linvega személy szerint az "egy hetes számítógép" mellett tette le a voksát: "egy hónaposnál már utálnám magam, ha újra kéne implementálnom".

Felkészülési kultúra és limit-tudatosság¶

Az előadásban megjelenik egy japán kabalafigura, a "bōsai" (felkészülési) orrszarvú, amely a japán földrengés-készültségi kultúrát szimbolizálja — a bejárati ajtó mellett mindig ott van egy táska vízzel, WC-papírral, elsősegély-felszereléssel. Ez a fajta rugalmasság (resilience) analóg azzal, amit Linvega a szoftverben keres.

A korlátok ismerete teszi lehetővé a tervezést. Ha csapvíz van, végtelennek tűnik a víz; ha víztartály, akkor pontosan látod, mennyi maradt. A modern techcégek üzleti modellje éppen a korlátok elrejtésére épül — és ez megfoszt a tervezés képességétől. Azok, akik instabil internettel, régi eszközökkel, off-grid környezetben élnek, tömegesen maradnak le, amikor olyan rendszereket tervezünk, amelyek feltételezik a leggyorsabb gépet és a 24/7 kapcsolatot.

Játékos kiterjesztések: jelnyelv, ábécé, bináris fonetika¶

Az előadás utolsó része a játékos kísérletezésről szól. Linvega és párja: - Jelnyelvet hoztak létre az assembly nyelv kommunikálására - Saját ábécét terveztek Bruce Alan Martin hexadecimális karakterkészlete (heximal glyphs) alapján, így minden opkódnak saját írott karaktere van - Bináris adatok fonetikus kommunikációját vizsgálták — Daniel S. Wilkinson sémáját használva, ahol egy short érték mássalhangzó-magánhangzó sorozatként olvasható ki

Mindez részben praktikus okokból született: amikor a Raspberry Pi fájlszerver elromlott, és nem javították meg, egyszerűen hangosan kibetűzték egymásnak az asseteket. Egy sprite például így hangzana: "badis zov luum dab dab".

Kulcs Üzenetek¶

A fenntarthatóság nem környezetvédelmi buzzword, hanem egy gyakorlat hosszú távú folytathatósága. Ha a toolchain-ed lemeríti az akkumulátort, a gyakorlat nem fenntartható — függetlenül attól, mennyire "zöld" a szoftver.
A régi technológiák nem azért haltak ki, mert rosszak voltak, hanem társadalmi-politikai okokból. A számítástechnika-történet ismerete nélkül újra és újra feltaláljuk ugyanazt, csak rosszabbul.
A korlátok ismerete nem hátrány, hanem a tervezés alapfeltétele. Aki nem ismeri a korlátait, nem tud tervezni. A modern tech stack-ek szándékosan elrejtik ezeket.
A komplexitás mérhető: hány utasítás, szabály, kivétel kell egy állapot eléréséhez. Keressük a minimumot.
Az igazi elegancia a hiány értékének megfogalmazása. Nem az a kérdés, mit tudsz hozzáadni, hanem hogy mit tudsz elvenni anélkül, hogy a rendszer összeomlana.
A szoftvermegőrzés a mi felelősségünk, a piac nem fogja megoldani. A kereskedelmi játékok 87%-a már elveszett; az UVM (Universal Virtual Machine) megközelítés — egy könnyen újraimplementálható, minimális célplatform — lehet az egyik kiút.
A "scale down" legalább olyan értékes, mint a "scale up". Linvega boldogan rajzolt fekete-fehérben, és a régi rendszerek emulálva gyorsabbak voltak, mint a modern natív alkalmazások.
A szabotázs — a hatékonyság tudatos visszavonása — politikai aktus. Ahogy a ludditák a gépek tönkretételével emberségesebb munkakörülményeket követeltek, úgy a tudatosan "lassú" szoftver is állásfoglalás a komplexitás diktatúrája ellen.
Írd meg a saját rendszeredet. Linvega szándékosan nem nevez meg technológiákat, mert a cél nem egy újabb framework adoptálása, hanem az, hogy a hallgató megértse a problémát és saját implementációt írjon — akkor is, ha az "rossz" és "amatőr". A tudás, amit közben szerzel, többet ér, mint bármelyik kész megoldás.