1 line
No EOL
1.7 KiB
JavaScript
1 line
No EOL
1.7 KiB
JavaScript
repo={"frontmatter": {"draft":false,"glassblowers":["cristobalsciutto.md"],"iscjklanguage":false,"title":"Resilient Infrastructure"}, "content": "\nFor protocols to be resilient, they must be maintained. Simple tools can be\ninterrogated. Simple tools can be tweaked. Worse is better.\n\nSoftware must be executed on a substrate, a computational abstraction on top of\nhardware. If that substrate shifts from under the software, the software stops\nrunning. It must be \"ported\" to new hardware via a new abstraction. Longevity\nthus implies constant maintenance.\n\nThe easier to port, the more resilient software becomes. Sometimes porting\nbecomes impossible, and then software dies. This is what happened to Adobe\nFlash, until it was ported to the internet browser (flash.pm). Choosing a\nsimple abstraction on top of hardware, despite being inefficient is often worth\nit. This is the approach taken by [100 rabbits with Uxn](https://100r.co/site/uxn_design.html). They write:\n\n\"As it stands today, modern software is built with extreme short-sightedness,\ndesigned to be run on disposable electronics and near impossible to maintain.\nWe decided to not participate. Our aim is to create a machine that focuses on\nanswering the handful of little tasks we need, which is centered around\nbuilding playful audio/visual experiences.\n\nUxn was created explicitly to host software on pre-existing platforms, the\ndesign was advised primarily by relative software complexity, not by how fast\nit could run on new hardware standards. Features were weighted against the\nrelative difficulty they would add for programmers implementing their own\nemulators.\"\n", "path": "shard/maintenance.md", "relpermalink": "/shard/maintenance/" } |