A number of computing projects I've seen, from open hardware to Urbit
to Gemini itself, have an ancillary goal to build a system a user
could one day pass on to his or her grandchildren. Many posts on
Gemini discuss the idea of a single computer that could last 50 years
or more. For the purpose of this post, I'll refer to these ideas as
"long-term computing".
Many long-term computing projects picture a machine that can be used
daily or a few times a week, with equivalent parts being replaced as
necessary to keep the machine running and software updates probably
only consisting of security updates or critical bug fixes. I think of
this subset of long-term computing as "durable computing", since the
idea is that the software or hardware can withstand decades of con-
tinuous use. The updateable aspect of durable computing, however, is
a nuance not to be ignored.
Imagine that I have a long-term computing device whose power port
fails after a year of use, but I don't bother to buy another one and
I toss it into my closet. Forty years later, as I'm preparing to sell
the house, I find the device again. If it's truly long term, I should
still be able to find parts for it, but it hasn't been booted once in
forty years.
Once I get it up and running again, can I use it for anything pro-
ductive? Can I connect it to other devices and communicate with them,
for example? Updates would probably be required, sure. But could I
apply one massive update with all the deltas needed to get it cur-
rent, or would I need to apply a chain of separate updates? If I need
a chain of updates, what do I do if one of the updates isn't online
anymore? Is there a legacy mode I can use on other devices? Ideally,
even with a decades-long gap, I'd want to be able to bring this old
device to a state where I can use it similarly to most other com-
puters.
I like to think of this scenario as "time-capsule computing". Both
durable computing and time-capsule computing have the goal of tech-
nology being able to work decades into the future, but the difference
is what happens in the interim: durable computing focuses on con-
tinued usage throughout that time period, whereas time-capsule com-
puting allows for long periods of no use at all.
Retro computing circles often seem to confuse or even conflate these
ideas. The task of building a computer or an OS that can simply last
for half a century is not the same as the task of building a computer
or an OS that can be used with exactly the same components half a
century later. The former can morph into an entity completely unlike
the latter, à la the Ship of Theseus paradox. But many enthusiasts of
old hardware are often a mix of people who want to use Commodore 64s
in everyday life and people who want to try to port a (stripped-down)
modern Linux kernel to Amiga hardware, and there's usually not much
distinction between the two.
Is the time-capsule aspect a realistic goal of long-term computing
projects? In most cases, I'd guess not. Technology has evolved in
ways systems designers fifty years ago couldn't have imagined, and
many business-critical uses for technology simply can't scale to the
needs of today. A prominent example is cryptography: encryption used
in the 1980s was sufficient because computers in that day couldn't
crack it, but modern hardware can bypass it in seconds. It might not
be realistic for hardware designed decades ago to provide the horse-
power needed to safely handle sensitive data.
On the other hand, some software--and even a few pieces of hardware--
lend themselves quite well to the time-capsule paradigm. A computer
from 1995 with a network card can still connect to existing dial-up
services or Ethernet, and Gopherspace is still as accessible to these
machines as it was in 1995. Surfing the modern Web would be out of
the question, of course, but that's another issue.
