davidbgk
/
larlet-fr-david-cache

<!doctype html><!-- This is a valid HTML5 document. -->
<!-- Screen readers, SEO, extensions and so on. -->
<html lang="fr">
<!-- Has to be within the first 1024 bytes, hence before the `title` element
  See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset -->
<meta charset="utf-8">
<!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 -->
<!-- The viewport meta is quite crowded and we are responsible for that.
  See: https://codepen.io/tigt/post/meta-viewport-for-2015 -->
<meta name="viewport" content="width=device-width,initial-scale=1">
<!-- Required to make a valid HTML5 document. -->
<title>Permacomputing Update 2021 (archive) — David Larlet</title>
<meta name="description" content="Publication mise en cache pour en conserver une trace.">
<!-- That good ol' feed, subscribe :). -->
<link rel="alternate" type="application/atom+xml" title="Feed" href="/david/log/">
<!-- Generated from https://realfavicongenerator.net/ such a mess. -->
<link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png">
<link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png">
<link rel="manifest" href="/static/david/icons2/site.webmanifest">
<link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c">
<link rel="shortcut icon" href="/static/david/icons2/favicon.ico">
<meta name="msapplication-TileColor" content="#f7f7f7">
<meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml">
<meta name="theme-color" content="#f7f7f7" media="(prefers-color-scheme: light)">
<meta name="theme-color" content="#272727" media="(prefers-color-scheme: dark)">
<!-- Documented, feel free to shoot an email. -->
<link rel="stylesheet" href="/static/david/css/style_2021-01-20.css">
<!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. -->
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<script>
    function toggleTheme(themeName) {
        document.documentElement.classList.toggle(
            'forced-dark',
            themeName === 'dark'
        )
        document.documentElement.classList.toggle(
            'forced-light',
            themeName === 'light'
        )
    }
    const selectedTheme = localStorage.getItem('theme')
    if (selectedTheme !== 'undefined') {
        toggleTheme(selectedTheme)
    }
</script>

  <meta name="robots" content="noindex, nofollow">
  <meta content="origin-when-cross-origin" name="referrer">
  <!-- Canonical URL for SEO purposes -->
  <link rel="canonical" href="http://viznut.fi/texts-en/permacomputing_update_2021.html">

<body class="remarkdown h1-underline h2-underline h3-underline em-underscore hr-center ul-star pre-tick" data-instant-intensity="viewport-all">


<article>
  <header>
    <h1>Permacomputing Update 2021</h1>
  </header>
  <nav>
    <p class="center">
      <a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
        <use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-home"></use>
      </svg> Accueil</a> •
      <a href="http://viznut.fi/texts-en/permacomputing_update_2021.html" title="Lien vers le contenu original">Source originale</a>
    </p>
  </nav>
  <hr>
  <p>It is now more than a year since I wrote <a href="http://viznut.fi/texts-en/permacomputing.html">my "early notes" about
Permacomputing</a>. At that time, I was not yet aware of anyone else having
similar ideas, so I've now decided to write an update that connects my ideas
with the existing discussions and activities. I also want to share some new
ideas I have been pondering about. This text is about 33K characters / 4900
words long, so allocate your time accordingly.</p>

<h2>1. A fragmented pluriverse</h2>

<p>The "biosphere-aware computing scene" is quite fragmented. There are many
different islands (groups and individuals) that use different terminology
and that are only now discovering each other. It is therefore important to
build bridges between the islands.</p>

<p><a href="https://computingwithinlimits.org/">Computing within Limits
workshops</a> that started in 2015 form an important hub but have been
rather invisible from non-academic perspectives. Many interesting papers
have come out of these workshops, but I would really like to see more
practical and/or longer-term projects that go beyond the shortish workshop
papers. Computing within Limits branched out of a larger field of
"sustainable" ITC <a href="http://urn.kb.se/resolve?urn=urn:nbn:se:uu:diva-375131">that is known
to have huge problems</a>.</p>

<p>Another hub is in the <a href="https://en.wikipedia.org/wiki/Fediverse">Fediverse</a>, particularly
around the Mastodon server <a href="https://merveilles.town/">Merveilles.town</a> that centers around
creativity and sustainable technology. Many of these productive hackers,
artists and activists also participate in the "smolnet"/"smallnet",
including the space of the <a href="https://gemini.circumlunar.space/">Gemini</a> protocol. My
Permacomputing article was very well received in these circles and many have
adopted the concept for their use.</p>

<p>Then there's the "Sustainable Internet" activism that has the <a href="https://branch.climateaction.tech/about">Branch online magazine</a>. I
tend to lump this together with the various "solar web" projects such as the
<a href="https://www.lowtechmagazine.com/2020/01/how-sustainable-is-a-solar-powered-website.html">solar-powered
version of Low-Tech Magazine</a> and the <a href="http://solarprotocol.net/">Solar Protocol</a>. Also somewhat related
is the <a href="https://smallfile.ca/">Small File Media Festival</a> that
criticizes the carbon footprint of streamed media with smallish (video)
files. This is an area where the demoscene could make important
contributions.</p>

<p>In addition to the generic groups of like-minded people, there are
specific projects, such as <a href="https://collapseos.org/">Collapse
OS</a>, whose participants don't necessarily have connections to wider
groups.</p>

<p>Occasionally, an online article pops up that expresses similar concerns
and ideas as I did with the Permacomputing essay, like Wim Vanderbauwhede's
<a href="https://wimvanderbauwhede.github.io/articles/frugal-computing/">Frugal
computing</a>. It is great to see that many different people independently
come to similar conclusions, but this can also be seen as a sign that we
need more social media activism and awareness-rising even to make all the
concerned people find each other.</p>

<p>Marloes de Valk has been <a href="https://computingwithinlimits.org/2021/papers/limits21-devalk.pdf">mapping</a>
this scattered "pluriverse" and its terminology, but I have the feeling that
this only scratches the surface, and that there's a lot of relevant practice
going on in e.g. non-Western countries.</p>

<p>A major problem with this "pluriverse" is the lack of a common name to be
used in communication. "Permacomputing" scored quite high in De Valk's
Fediverse poll, and I have no objections against using it for this purpose.
Something like "radically sustainable computing" might also be a good
umbrella term ("radically" being the keyword that differentiates it from the
greenwashed capitalism of "Sustainable ITC").</p>

<h2>2. Collapse Informatics</h2>

<p>Many of the early Computing within Limits papers discuss collapse and
scarcity scenarios from somewhat bleak viewpoints. In later years, the
research community started to reframe itself in more positive ways by
drawing inspiration from e.g. Hes &amp; du Plessis' <i><a href="https://www.routledge.com/Designing-for-Hope-Pathways-to-Regenerative-Sustainability/Hes-Plessis/p/book/9781138800625">Regenerative
Sustainability</a></i> and Escobar's <i><a href="https://www.dukeupress.edu/designs-for-the-pluriverse/">Designs for
the Pluriverse</a></i> – just like Permacomputing draws inspiration from
Permaculture. But even when focusing on a positive vision, one should not
take anything for granted. If a vision cannot survive a collapse of
industrial production or network infrastructure, it isn't resilient
enough.</p>

<p>An important paper in the collapse vein is Jang et al.'s <i><a href="https://kurti.sh/pubs/unplanned_limits17.pdf">Unplanned Obsolescence:
Hardware and Software After Collapse</a></i> that e.g. estimates lifetimes for
various hardware components, with the conclusion that it may be possible to
maintain some of current computer hardware for several human generations
even if the entire semiconductor industry collapsed right now. Solderpunk
(the creator of the afore-mentioned Gemini) has a concrete proposal for a
"<a href="gopher://zaibatsu.circumlunar.space/0/%7esolderpunk/phlog/the-standard-salvaged-computing-platform.txt">standard
salvaged computing platform</a>" based on smartphone/tablet e-waste. I'm
sure that there are components with much longer potential lifespans (Jang et
al. estimate current mobile hardware to be able to persist for about one
generation), but at least there would be heaps of this type of junk
available in the early years. I'm personally interested by the possibilities
of microcontroller-based smartcards (that are even more ubiquitous than
mobile phones but have entirely different challenges).</p>

<p>Jang et al. also have a few interesting words about maintenance culture.
In the same way as religious organizations continued to maintain ancient
Chinese roads that no longer received governmental support, computing could
be maintained in a post-collapse world by "semi-ascetic cultural
organizations whose primary focus may or may not be computing". I have
personally been fascinated by the potential of monastery-like communities to
preserve science and technology even during "dark ages" when the society at
large sees no value in them. In medieval Europe, some monasteries even
refined and advocated technologies such as <a href="https://www.researchgate.net/publication/271064820_Wind_and_Water_in_the_Middle_Ages_Fluid_Technologies_from_Antiquity_to_the_Renaissance">water
power</a>.</p>

<p>The term <i><a href="https://www.researchgate.net/publication/262276832_Collapse_Informatics_and_Practice_Theory_Method_and_Design">collapse
informatics</a></i> comes from Bill Tomlinson who suggests that one should look
into the existing computing practices in groups that have voluntarily chosen
to live off-grid or in other "collapse-like" conditions. I might also want
to include those who do so involuntarily, as well as those who have made
"collapse-compatible" decisions specifically with computing (e.g. artists
who specialize in old hardware).</p>

<p>I don't know if there is going to be a collapse, but I'm quite sure that
the entire society needs to reduce energy consumption, lengthen
technological lifespans and reduce superfluous dependencies. Recognizing the
possiblity of a collapse may help coordinate these changes. <i><a href="https://www.ceguide.org/Strategies-and-examples/Design/Design-for-disassembly-deconstruction">Designing for
disassembly</a></i> is an example of a concrete goal that supports hardware
longevity in both collapse and non-collapse scenarios.</p>

<h2>3. Anti-utilitarianism</h2>

<p>In profit-oriented societies, people often try to make themselves and
their fields of expertise as important and useful as possible. It has
therefore been delightful to learn about visions that detach computing from
all utilitarian purposes.</p>

<p>Brendan Howell's <i><a href="https://moddr.net/rustic-computing/">Rustic
Computing</a></i> is an artistic project that depicts computing as "the pastime
of dilettantes, amateur scientists and gentleman tabulators who construct
machines to manipulate abstract symbols with no practical application".
Computer components are built using pre-industrial technology, which reminds
me of early mechanical computers such as Zuse's Z1. When computers are built
with non-pollutive technologies, they don't need to justify their existence
by paying back their ecological debts. And since they have no practical
purpose, they don't even have to be faster or better than manual
paper-and-pencil calculation. They can just be interesting and important the
way they are.</p>

<p>I see much of the same attitude in <i><a href="https://compudanzas.net/about.html">Compudanzas</a></i>, a research
project that reimagines computing in the form of "seemingly useless"
activities such as rituals and dancing.</p>

<p>In Steve Lord's idea of <i><a href="https://thedorkweb.substack.com/p/the-100-year-computer">Heirloom
Computing</a></i>, a computer that has been made to last for many generations
can be a piece of family history that evolves with the family, keeping
permanent traces from every generation that has used it, and does not need
to have any purpose besides this.</p>

<p>As suggested by Jang et al., a post-collapse society that has eventually
lost all of its artificial computing capacity may still want to continue the
practice of computer science in a purely theoretical level, as a form of
mathematics. This is another example of how computing may remain meaningful
for some pockets of culture even with no ability to run any potential
applications.</p>

<p>Detachment from utilitarism may (perhaps paradoxically) give way to a
deeper importance and meaning. I'm particularly thinking about Yuk Hui's
idea of <i><a href="https://www.academia.edu/35561477/On_Cosmotechnics_For_a_Renewed_Relation_between_Technology_and_Nature_in_the_Anthropocene">Cosmotechnics</a></i>
which refers to a unified harmony between technology, culture and non-human
nature. Modern technological thinking lost this harmony by turning
everything into utilitarian resources. An interesting point made by Hui is
that every culture should find its own approach to cosmotechnics – so, we
would be replacing a homogenous global utilitarian monoculture with a rich
and diverse polyculture.</p>

<h2>4. Limits of imagination</h2>

<p>It is often difficult to even imagine a kind of computer culture that
does not suffer from unlimited growth. Even the most interesting real-world
examples (such as the Soviet computing culture) exist somewhat in the shadow
of Western developments and ideologies. So, there's no real "other" to
contrast the growth-obsessed mainstream computing with.</p>

<p>Computing within Limits papers have also given me an impression that some
scholars even find it difficult to imagine e.g. how software development
could take place without the Internet. In cases like this, I might suggest
looking into the actual history and listening to people who have experienced
it. Even though the history of computing isn't nearly as diverse as it could
or should be, it is still worthwhile to study it. And definitely not only
the mainstream "winners' history" but everything from the various cultures
and subcultures.</p>

<p>Eriksson and Pargman <a href="https://computingwithinlimits.org/2018/papers/limits18-eriksson.pdf">have
suggested the use of counterfactual history</a> to assist imagination.
Sadly, their own <i><a href="https://www.researchgate.net/project/Coalworld">Coalworld</a></i>
scenario (with the point of divergence being an early-seventies "peak oil"
event) has not yet reached the point where computing can be elaborated. I
wish there was more speculation (both fiction-oriented and academically
rigorous works) that would present thoroughly-imagined alternatives to the
actual history.</p>

<h2>5. Alternative paradigms</h2>

<p>I've already mentioned several "alternative paradigms of computing":
<i>frugal computing</i>, <i>heirloom computing</i>, <i>rustic computing</i>,
<i>collapse informatics</i>. But there are still a few more to add:</p>

<p><i><a href="https://computingwithinlimits.org/2018/papers/limits18-mann.pdf">Regenerative
computing</a></i> is Mann et al.'s idea of applying Hes &amp; du Plessis'
<i>Regenerative sustainability</i> to computing. The most
Permacomputing-relevant part of the Limits'18 is quite dense, so I'll quote
it verbatim: (number 7 refers to Hes &amp; du Plessis' 2014 book <i><a href="https://www.routledge.com/Designing-for-Hope-Pathways-to-Regenerative-Sustainability/Hes-Plessis/p/book/9781138800625">Designing
for hope: pathways to regenerative sustainability</a></i>)</p>

<blockquote>
(3) Move beyond efficiency as the primary lever available to computing. -
These new narratives should look to nature and ecology to demonstrate the
interplay between computing, society and biological systems where limits of
these systems are respected and worked with.<br>
(4) Integrate ecological worldviews into computing's narratives and
processes both the theory such as living systems and deep ecology, and
values sets:
<ul>
<li>Integrity - maintaining the wholeness of [wider] systems, ensuring that
structure and relationships remain intact and functioning as they
should.</li>
<li>Inclusivity - "interacting with the world in its entirety" [7, p. 35],
engaging and integrating with all dimensions, levels of existence and
knowledge.</li>
<li>Harmony - all elements cooperate through relationships that are
respectful in order to avoid dissonance.</li>
<li>Respect - all parts of the world have intrinsic worth and all existence
is part of the extended self, and therefore all self-respect is extended to
mutual respect for the world.</li>
<li>Mutuality - "we are in this together, and what happens to ‘others’ will
also have an effect on self" - see: compassion, treating others the same as
yourself.</li>
<li>Positive reciprocity - "reciprocating in a way that is
of benefit to and advances the relationship between
self and extended self" [7, p. 35].</li>
<li>Fellowship - an extension of mutuality and positive reciprocity, where
the world is co-created by humans in partnership with nature.</li>
<li>Responsibility - morally accountability for the consequences of our
actions in an uncertain and unpredictable world</li>
<li>Humility - change is constant, we cannot know the true consequences of
our actions</li>
<li>Non-attachment - In order to adapt to changing circumstances it is
important to uphold non-attachment in order to decouple from “the futility
of trying to hold onto anything in an ever changing world including ideas,
dogmas and strategies” [7, p. 36]</li>
</ul>
</blockquote>

<p><i>Convivial computing</i>, from <a href="https://www.researchgate.net/publication/235173004_Constrained_Design_Processes_Steps_Towards_Convivial_Computing">Fischer
&amp; Lemke's 1987 paper</a>, is an earlier example of taking ideas from
ecologically conscious thinking into computing (in this case, from Ivan
Illich's book <i>Tools for Conviviality</i>). Even earlier, Lee Felsenstein
had been inspired by the same book when designing the Osborne 1 personal
computer. In both cases, however, the ecological aspects of Illich's thought
are ignored. Also, Fischer &amp; Lemke's paper doesn't feel at all like a
forgotten masterpiece of groundbreaking thought – the ideas actually seem to
be very much in line with what was implemented in the "<a href="https://en.wikipedia.org/wiki/Rapid_application_development">RAD</a>
tools" of the 1990s. And some of these tools (Delphi, Visual Basic) felt
like the epitome of bloat at the time.</p>

<p><i><a href="https://computingwithinlimits.org/2015/papers/limits2015-raghavan.pdf">Benign
computing</a></i> basically advocates keeping things small in order to keep
the problems caused by them small. Currently, huge problems are created by
huge, centrally-managed systems built with the principles of abstraction and
indirection. Raghavan's critique of these principles is very similar to how
I see "<a href="http://viznut.fi/texts-en/maximalism_virtualism.html">maximalism and
virtualism</a>". I also completely agree with Raghavan about that "the
utopian notion of creating new technology that is strictly "beneficial" or
that advances "development"" must be rejected.</p>

<h2>6. Permacomputing practice</h2>

<p>My Permacomputing article from 2020 is basically a vision of a new kind
of computing that works in a radically different way in a radically
different society. It does not give many guidelines towards actual practice
or how to transition towards permacomputing, so maybe I should cover this
area a little bit.</p>

<p>I have been reluctant to name specific technologies or design constraints
for permacomputing. This is because I want to support a diverse polyculture
of ideas and possibilities. Asking what is the most suitable programming
language for permacomputing is a bit like asking what is the most suitable
plant for permaculture – the entire question contradicts itself. There is no
"silver bullet" – there isn't one even in the mainstream industry despite
its continuous attempts to uniformize everything. However, there can be
design wisdom about the strengths, weaknesses and mutual interactions of
specific elements, and this wisdom helps with choosing a language, a plant,
an algorithm or a design pattern for a specific place.</p>

<p>In software, nothing that can be run locally is "poisonous" per se. Even
if something consumes a lot of energy, it does not need to mean more than
that the consumption must be restricted to when that energy is available.
Far more important questions are how the hardware is obtained and
maintained, and how the energy is produced.</p>

<p>I have noticed that many "sustainable" or even "low-tech" computing
projects have been built on cheap DIY-oriented boards such as Raspberry Pi.
Even though these may be among the best of the currently available options,
it should be noted that they have been designed for hackability and
replaceability rather than longevity or repairability. There might be a need
for a radically repairable and modifiable hardware basis to fulfill similar
purposes. Radical modifiability might include the ability to interface with
a large variety of different chips (processors, SoCs etc.) – this would help
maximize the usable lifespans of those chips.</p>

<h3>6.1. Low complexity</h3>

<p>Keeping systems very simple but very capable is a good guideline for a
lot of permacomputing, but particularly so for the crucial basic software
used to enable salvaged/makeshift hardware. Bare-hardware Forth systems
(such as Collapse OS or OpenBIOS) are very capable for their low complexity,
and can be small enough even for rudimentary 8-bit microcontrollers.</p>

<p>One possible approach to simplicity is to try to keep things simple
enough that they can be thoroughly understood and (re)implemented by one
person. This applies not only to application programs but the dependent
elements as well (programming language, operating system, firmware,
hardware). This is not to say that people should write everything from
scratch but to keep the complexity human-graspable. The ideal of human-sized
computing is particularly applicable to systems that are used as tools
(because tools in general should be thoroughly understandable to their
users). Also, in decentralized "post-collapse" societies, the local
all-around experts ("village hackers") should be able to master all aspects
of the local computing systems in order to maintain them and to adapt them
to various local needs. All this becomes much easier if complexities are
kept low or moderate.</p>

<p>The effective complexity of a software program can be estimated by
summing its executable size with the size of the minimum set of dependencies
required to run it (including the OS components). Alternatively, one can
calculate its bootstrap complexity (by summing the size of all code and data
required to compile the program, the dependencies, and the entire dependency
network of the toolset required for the compilation in the smallest system
that can run them). These types of assessment strongly favor programs that
are written in non-bloated languages and can be made run on bare hardware –
even if they can also run in bloated environments and use their special
features.</p>

<p>One way to deal with huge platforms is to create "pockets of simplicity"
such as <a href="https://100r.co/site/uxn.html">simple virtual machines</a>
that can also run on bare hardware. Emulators of existing hardware platforms
are a special case of this. VMs are particularly suitable for small things
that require far less computation than what the hardware is capable of. A
virtual machine may also help eliminate compatibility problems and code rot,
if it is unambiguously defined and the definition is canonized (permanently
frozen). If approached with mainstream engineering attitudes, however, VMs
may easily lead to "Java-like" problems (wastefulness, incompatibilities,
etc.) Setting artificial limits to memory usage and execution speeds may
prevent some of these developments. One might also want to think about how
to statically translate VM programs into native code for running on
platforms that are actually small.</p>

<p>In mainstream computing, "ease of use" is usually implemented as
"superficial simplicity" or "pseudo-simplicity", i.e. as an additional layer
of complexity that hides the underlying layers. Meanwhile, systems that are
actually very simple and elegant are often presented in ways that make them
look complex to laypeople (think about the esoteric syntax of Forth or Lisp,
for example). Ideally, UIs should reflect, amplify and illustrate the
underlying elegance instead of trying to hide or misrepresent the inner
workings. The earliest versions of the Apple Macintosh OS manage to do this
to some extent (the system is not much more complex than the UI
representation, every file is represented by an icon, program files are
stand-alone without external dependencies, etc.)</p>

<p>When minimizing the internal complexity of a system, however, it should
not be isolated from the complexity of the external world. Computers are
dependent on energy availability, temperature and other conditions, so they
should be able to adjust their operation to the changes in these conditions
– even if environmental monitoring is not among their designated tasks.</p>

<h3>6.2. Towards concrete examples</h3>

<p>Permacomputing has so far been defined in ways that emphasize generic
ideas and a wide diversity of possibilities. However, in order to actually
create something that represents permacomputing, one needs to make a lot of
specific design decisions. Concrete examples (either real projects or
mockups) may help with this. In order to cover the possibility space, we
need a lot of different examples from different points of view.</p>

<p>One possible starting point is to think about a general-purpose
single-user computer that remains usable and relevant as long as possible
even in a collapse scenario. Of course, any computer should be
end-user-programmable and have some kind of programming interface to
facilitate it, but what would be the concrete applications this kind of
computer would be used for?</p>

<p>I assume that viewing text files from physical storage devices (such as
flash memory) is what would persist the longest in any scenario. A few
gigabytes of storage would be enough for an entire library of literature
that could be valuable for centuries. And accessing it would be possible
(although not comfortable) even with very rudimentary post-collapse I/O
devices (such as a few switches and indicators for a manual serial protocol
– somewhat like using a Morse code telegraph).</p>

<p>It may be theoretically possible to even read data directly from a USB
flash drive with this kind of manual "telegraphy", but the complexity of the
USB protocol would probably get overwhelming. Fortunately, a complex
protocol implies that there is a (re)programmable microcontroller in the
device, so one may want to reprogram it to support a simpler protocol. One
could also add a "backdoor" that enables the device to run arbitrary
programs from the drive, thus unleashing its potential for general-purpose
computing. It may even be possible to get a USB stick to drive "proper"
interface devices such as display screens despite the low number of I/O pins
(two output pins are enough for composite video, but LCD panels
unfortunately tend to need much more, so some kind of a multiplexer would be
required). This could help reduce and postpone the need for "Morse
code".</p>

<p>These could become general guidelines for maximizing the lifespans of
arbitrary programmable devices: 1) make it as straightforward as possible to
run arbitrary code, 2) support an electrically simple interface that can
even be operated manually in times of far-future scarcity.</p>

<p>Another persistent application besides file viewing would be text
editing. It has been prominent in personal computers since the early years
and probably will be in just about any scenario. It would also imply the
need for general file management tasks such as copying files between storage
devices. Programs for doing these tasks would be among the first to
implement for any "permacomputer" that does not require special expertise to
use.</p>

<p>Telecommunication is important but does not require computers – messages
may well be relayed with classical amateur radio methods. Also, computer
file-sharing networks can well be based on physical media. However, the
existence of a radio and a computer makes it appealing to combine the two. A
program for transferring files and text streams over abritrary channels, in
one- or two-way protocols or packet protocols, with or without error
correction and/or encryption, would be a fine inclusion to the set of
"collapse software".</p>

<p>Of course, supporting far-future post-collapse scenarios does not mean
that one should stick to far-future post-collapse practices – rather, it
ensures that there are fallbacks for everything. You can use a
high-resolution screen today, but the system will work fine even with
tomorrow's more rudimentary display. You can run a complex OS today, but the
simple OS in the firmware ROM is also perfectly fine for editing a text
document.</p>

<p>I imagine that this "simple OS" would normally look either like a plain
Forth interpreter or an orthodox file manager (i.e. a Norton Commander
clone), depending on whether the computer is connected to a sufficient
screen or not. For screens that are a bit too small for the OFM there might
also be an intermediate option that resembles early-2000s cellphone
interfaces. All of these modes would be usable even with quirky input
devices (such as a game controller, a single telegraph key or a barely
functional touchscreen). Hardware is accessed via Forth words that can be
straightforwardly redefined if there are unexpected hardware changes (such
as specific glitches that need to be bypassed).</p>

<p>The OFM would allow one to browse, view and manipulate files, run
executable files, edit text files and enter Forth commands. It could also be
set up as a bootloader to load a more complex OS, but loading one would
often be unnecessary, as many programs (especially ones that favor
single-tasking) would also be available as "Forth" executables (that may
also be native binaries that may or may not use Forth words) or as "ROM"
files runnable with a simple VM.</p>

<p>Systems that don't have much capacity to spare would perhaps only have a
plain Forth interpreter, or if even that would be too bloated, something
like the standard byte protocol used by smartcards.</p>

<p>Longevity maximization easily leads to an emphasis on conservative and
well-tested ideas, so this example may sound a little bit bleak. A fancier
starting point (such as one based on ideas from unconventional computing)
would perhaps give more room for fancier permacomputing ideas that take more
distance from fossil-era computing.</p>

<h3>6.3. Sustainable cyberspace</h3>

<p>There are many projects that address the sustainability problems of the
World Wide Web. Activism for sustainable websites, solar-powered servers,
new protocols, simpler document formats. However, these often take the
underlying Internet for granted. The access may perhaps be slow at times or
places, and a solar-powered server may be sometimes offline, but any place
of the world is still supposedly accessible from any other place of the
world at any time. The weirdness of this assumption may not even be obvious
to modern Internet users – after all, it is in the core of nearly every
major service/protocol (perhaps apart from Email and Usenet that can also
propagate over temporary connections).</p>

<p>I see need for a decentralized protocol that works painlessly in
conditions where everything is not constantly available. Where individual
servers or communication links may be online or offline depending on
circumstances. Where other parts of the network may only be accessible via
temporary connections, physical file-sharing or data mules. Where your
messages still reach their destinations, where you still get the files you
need, and where "social media" discussions can still thrive, despite all
these logistical constraints.</p>

<p>For some inspiration for the required mindset, one may think about how
files were collected and propagated in "pre-Internet" conditions (BBSes,
friend-to-friend file copying) and how to make these processes as automatic
as possible.</p>

<h2>7. Collapse-tolerant business</h2>

<p>I don't often think about how to do business in the capitalist economy,
but in the early 2021 I asked myself what kind of IT company (or other type
of IT-related organization) would thrive both before and after a collapse. I
wanted to challenge my prejudice that anything you do for profit/living will
always be somewhat "greenwashed" instead of properly sustainable.</p>

<p>Here are my ideas of how a relatively small "permacomputing company"
could operate in the "age of abundance":</p>

<ul>
<li>Accept software-related and other customer projects just like any
average IT company, as long as they are in line with strict eco-ethical
standards. Refuse to contribute to the wasteful use of resources, and
strongly prefer doing things in sustainable and robust ways. Make these
standards a part of the company brand.</li>

<li>Have long-term in-house research and development projects related to
radically sustainable computing, both software and hardware. Convince
investors about their vitality to the future of civilization. Also practice
permaculture (or constantly co-operate with ones who do) and try to connect
it to everything else that the company is doing.</li>

<li>Self-host everything you need for software work on local physical
servers. This includes all networked applications as well as an extensive
library of software and documentation (including repair manuals and OS
distributions for all relevant hardware). Offer hosting services to make
use of the surplus.</li>

<li>Produce as much of your own energy as possible with solar panels, wind
turbines etc. Sell the surplus to the company that maintains the grid.</li>

<li>Repair and maintain all hardware by yourself. Maintain a storage
facility for old/recycled hardware. Offer services related to repairing and
recycling (in a small scale, for now). Maintain a hackerspace or constantly
co-operate with one.</li>

<li>Support forms of culture that strengthen the status of radically
sustainable computing/technology (e.g. hackerspaces, education, demoscene
events, art projects that use "obsolete" hardware, etc.)</li>

<li>Make sure that many of the employees live close to the office. Maintain
spaces that can be turned into apartments once transportation becomes more
difficult.</li>
</ul>

<p>Once the world has completely changed, the focus or the organization will
become somewhat wider:

</p>
<ul>
<li>Accept any customer projects related to computing or any other
technology you happen to understand. Offer repair services.</li>

<li>Collect/buy "e-waste", build working computers and appliances out of it,
sell them.</li>

<li>Keep in contact with the rest of the "computing scene" even if
long-range communication networks have collapsed. Share information and
trade hardware components. Use couriers if necessary.</li>

<li>If microchips or some other essential components are no longer produced,
participate in attempts to restart the production (in a small scale, for
now – until we learn how to do it sustainably).</li>

<li>Similarly, try to rebuild communication networks if they have collapsed.
Offer communications services, maybe maintain "Internet cafés".</li>

<li>Maintain digital and physical libraries of pre-collapse and
post-collapse information. Print physical books. Participate in projects
that support the continuing existence of science and education.</li>

<li>Make sure that technological understanding will pass on to new
generations. If necessary, educate the new employees (or cult members or
whatever they may be called) from scratch.</li>

<li>If it becomes impossible to make living out of this, start depending on
agriculture. But in any case don't forget the importance of science and
technology. If necessary, explain the importance in religious terms.</li>
</ul>

<h2>8. Postdigital advocacy</h2>

<p>Art researchers recognize the concept of "postdigital" as a reaction
against the so-called "digital revolution" that took place in the nineties,
and especially against the typically "digital" esthetics. Using cassette
tapes for music in a world where digital music formats are ubiquitous is an
obvious example of "postdigital".</p>

<p>But not all that is called "postdigital" is non-digital. Actually, much
of it is very profoundly digital – pixel art and glitch art for example. The
term is somewhat misleading – it does not only mean "the non-digital that
comes after digital", but can also be read as "a later form of digital" or
"something that comes after the digital revolution". It particularly seems
to set itself apart from the "progress narrative" that wants to continuously
replace everything with "bigger and better". This makes the idea relevant to
permacomputing as well.</p>

<p>When advocating lifestyles that abandon maximalism, it is important to
frame it in a positive way. Settling for simple and coarse things does not
need to be a "sacrifice" but something genuinely better than the mainstream
alternative. "Postdigitality" is already a prominent force in e.g. indie
games that often choose to use pixel graphics as a "modern" esthetic
preference rather than as "retro nostalgia". This gives hope that a major
paradigm shift is possible for the mainstream digital culture in
general.</p>

<p>During the global pandemic, many people have been extremely dependent on
prohibitively complex digital blackboxes. I therefore assume that, once the
pandemic is over, many people will want to distance themselves from the
mainstream digital world. To concentate on non-digital things but also to
find a healthier relationship with the digital. I think this is something
that advocates of radically sustainable computing should tap into.</p>

<h2>Links</h2>

<p>(Added 2021-08-27) Here are some links I failed to include in the
original version of this page:</p>
<ul>
<li><a href="https://moddingfridays.bleu255.com/Main_Page">Modding
Fridays</a>: "An online community of people interested to learn together about the maintenance, repurposing, and reappropriation of supposedly obsolete consumer electronics, for fun and profit. We see our interest as part of a broader conversation on post-digital culture, permacomputing and repair
culture". Includes a wiki and an XMPP chatroom.</li>
<li><a href="http://civboot.org/">Civboot</a> is an educational project
aiming at simplifying the requirements and dependencies of computer
technology as well as increasing humanity's ability to understand it.</li>
<li><a href="https://wiki.xxiivv.com/site/permacomputing.html">Permacomputing
at the XXIIVV Wiki</a></li>
<li><a href="https://communitywiki.org/wiki/SimpleSystemsManifesto">Simple
Systems Manifesto</a></li>
</ul>

<p>Written by Ville-Matias "<a href="http://www.viznut.fi/">Viznut</a>" Heikkilä.<br>
<b>2021-08-12</b>: initial release<br>
<b>2021-08-27</b>: added the links section<br>
<a rel="license" href="http://creativecommons.org/licenses/by/4.0/">
<img alt="Creative Commons License" src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAFgAAAAfCAMAAABUFvrSAAAADFBMVEUAAAD///99fX2+w7rj0zguAAAA4klEQVRIx7WWgQ6FIAhFYf3/P9cjMX0K3rvStVwDT3QTRFS2jB/22DBkE9fI/WuwV639GnOrEILN/R6jKW4DCEaWftVWsWVJyjWX3M9NHTcne7j3fQH+42Zk8NNuy8BNlhTXOi3AqiM5V2KhhYGfv9xPH4DdV+oUrmGk8K1z3XzKwN2uQMBtJIDIwHZjwXCCUFIwKU39PKYIUduNKptMglCFnklp7gQhihB56M3L5tujOqqG75uA+dEU9wyWH6V5wMjR89CM2KVgzMf0IYpYRHE5ZskVRizKKA1g2Yi3tIU7sCfXlRBdibyVCwAAAABJRU5ErkJggg=="></a><br>
This work is licensed under a
<a rel="license" href="http://creativecommons.org/licenses/by/4.0/">
Creative Commons Attribution 4.0 International License</a>.</p>
</article>


<hr>

<footer>
  <p>
    <a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
        <use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-home"></use>
      </svg> Accueil</a> •
    <a href="/david/log/" title="Accès au flux RSS"><svg class="icon icon-rss2">
        <use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-rss2"></use>
      </svg> Suivre</a> •
    <a href="http://larlet.com" title="Go to my English profile" data-instant><svg class="icon icon-user-tie">
        <use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-user-tie"></use>
      </svg> Pro</a> •
    <a href="mailto:david%40larlet.fr" title="Envoyer un courriel"><svg class="icon icon-mail">
        <use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-mail"></use>
      </svg> Email</a> •
    <abbr class="nowrap" title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340"><svg class="icon icon-hammer2">
        <use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-hammer2"></use>
      </svg> Légal</abbr>
  </p>
  <template id="theme-selector">
      <form>
          <fieldset>
              <legend><svg class="icon icon-brightness-contrast">
                <use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-brightness-contrast"></use>
              </svg> Thème</legend>
              <label>
                  <input type="radio" value="auto" name="chosen-color-scheme" checked> Auto
              </label>
              <label>
                  <input type="radio" value="dark" name="chosen-color-scheme"> Foncé
              </label>
              <label>
                  <input type="radio" value="light" name="chosen-color-scheme"> Clair
              </label>
          </fieldset>
      </form>
  </template>
</footer>
<script src="/static/david/js/instantpage-5.1.0.min.js" type="module"></script>
<script>
    function loadThemeForm(templateName) {
        const themeSelectorTemplate = document.querySelector(templateName)
        const form = themeSelectorTemplate.content.firstElementChild
        themeSelectorTemplate.replaceWith(form)

        form.addEventListener('change', (e) => {
            const chosenColorScheme = e.target.value
            localStorage.setItem('theme', chosenColorScheme)
            toggleTheme(chosenColorScheme)
        })

        const selectedTheme = localStorage.getItem('theme')
        if (selectedTheme && selectedTheme !== 'undefined') {
            form.querySelector(`[value="${selectedTheme}"]`).checked = true
        }
    }

    const prefersColorSchemeDark = '(prefers-color-scheme: dark)'
    window.addEventListener('load', () => {
        let hasDarkRules = false
        for (const styleSheet of Array.from(document.styleSheets)) {
            let mediaRules = []
            for (const cssRule of styleSheet.cssRules) {
                if (cssRule.type !== CSSRule.MEDIA_RULE) {
                    continue
                }
                // WARNING: Safari does not have/supports `conditionText`.
                if (cssRule.conditionText) {
                    if (cssRule.conditionText !== prefersColorSchemeDark) {
                        continue
                    }
                } else {
                    if (cssRule.cssText.startsWith(prefersColorSchemeDark)) {
                        continue
                    }
                }
                mediaRules = mediaRules.concat(Array.from(cssRule.cssRules))
            }

            // WARNING: do not try to insert a Rule to a styleSheet you are
            // currently iterating on, otherwise the browser will be stuck
            // in a infinite loop…
            for (const mediaRule of mediaRules) {
                styleSheet.insertRule(mediaRule.cssText)
                hasDarkRules = true
            }
        }
        if (hasDarkRules) {
            loadThemeForm('#theme-selector')
        }
    })
</script>
</body>
</html>