30 lines
1.5 KiB
Markdown
30 lines
1.5 KiB
Markdown
+++
|
|
title = "Resilient Infrastructure"
|
|
glassblowers = ["cristobalsciutto.md"]
|
|
+++
|
|
|
|
For protocols to be resilient, they must be maintained. Simple tools can be
|
|
interrogated. Simple tools can be tweaked. Worse is better.
|
|
|
|
Software must be executed on a substrate, a computational abstraction on top of
|
|
hardware. If that substrate shifts from under the software, the software stops
|
|
running. It must be "ported" to new hardware via a new abstraction. Longevity
|
|
thus implies constant maintenance.
|
|
|
|
The easier to port, the more resilient software becomes. Sometimes porting
|
|
becomes impossible, and then software dies. This is what happened to Adobe
|
|
Flash, until it was ported to the internet browser (flash.pm). Choosing a
|
|
simple abstraction on top of hardware, despite being inefficient is often worth
|
|
it. This is the approach taken by [100 rabbits with Uxn](https://100r.co/site/uxn_design.html). They write:
|
|
|
|
"As it stands today, modern software is built with extreme short-sightedness,
|
|
designed to be run on disposable electronics and near impossible to maintain.
|
|
We decided to not participate. Our aim is to create a machine that focuses on
|
|
answering the handful of little tasks we need, which is centered around
|
|
building playful audio/visual experiences.
|
|
|
|
Uxn was created explicitly to host software on pre-existing platforms, the
|
|
design was advised primarily by relative software complexity, not by how fast
|
|
it could run on new hardware standards. Features were weighted against the
|
|
relative difficulty they would add for programmers implementing their own
|
|
emulators."
|