A place to cache linked articles (think custom and personal wayback machine)
Du kan inte välja fler än 25 ämnen Ämnen måste starta med en bokstav eller siffra, kan innehålla bindestreck ('-') och vara max 35 tecken långa.

index.html 45KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679680681682683684685686687688689690691692693694695696697698699700701702703704705706707708709710711712713714715716717718719720721722723724725726727728729730731732733734735736737738739740741742743744745746747748749750751752753754755756757758759760761762763764765766767768769770771772773774775776777778779780781782783784785786787788789790791792793794795796797798799800
  1. <!doctype html><!-- This is a valid HTML5 document. -->
  2. <!-- Screen readers, SEO, extensions and so on. -->
  3. <html lang="fr">
  4. <!-- Has to be within the first 1024 bytes, hence before the `title` element
  5. See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset -->
  6. <meta charset="utf-8">
  7. <!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 -->
  8. <!-- The viewport meta is quite crowded and we are responsible for that.
  9. See: https://codepen.io/tigt/post/meta-viewport-for-2015 -->
  10. <meta name="viewport" content="width=device-width,initial-scale=1">
  11. <!-- Required to make a valid HTML5 document. -->
  12. <title>Permacomputing Update 2021 (archive) — David Larlet</title>
  13. <meta name="description" content="Publication mise en cache pour en conserver une trace.">
  14. <!-- That good ol' feed, subscribe :). -->
  15. <link rel="alternate" type="application/atom+xml" title="Feed" href="/david/log/">
  16. <!-- Generated from https://realfavicongenerator.net/ such a mess. -->
  17. <link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png">
  18. <link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png">
  19. <link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png">
  20. <link rel="manifest" href="/static/david/icons2/site.webmanifest">
  21. <link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c">
  22. <link rel="shortcut icon" href="/static/david/icons2/favicon.ico">
  23. <meta name="msapplication-TileColor" content="#f7f7f7">
  24. <meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml">
  25. <meta name="theme-color" content="#f7f7f7" media="(prefers-color-scheme: light)">
  26. <meta name="theme-color" content="#272727" media="(prefers-color-scheme: dark)">
  27. <!-- Documented, feel free to shoot an email. -->
  28. <link rel="stylesheet" href="/static/david/css/style_2021-01-20.css">
  29. <!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. -->
  30. <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>
  31. <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>
  32. <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>
  33. <link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
  34. <link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
  35. <link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
  36. <script>
  37. function toggleTheme(themeName) {
  38. document.documentElement.classList.toggle(
  39. 'forced-dark',
  40. themeName === 'dark'
  41. )
  42. document.documentElement.classList.toggle(
  43. 'forced-light',
  44. themeName === 'light'
  45. )
  46. }
  47. const selectedTheme = localStorage.getItem('theme')
  48. if (selectedTheme !== 'undefined') {
  49. toggleTheme(selectedTheme)
  50. }
  51. </script>
  52. <meta name="robots" content="noindex, nofollow">
  53. <meta content="origin-when-cross-origin" name="referrer">
  54. <!-- Canonical URL for SEO purposes -->
  55. <link rel="canonical" href="http://viznut.fi/texts-en/permacomputing_update_2021.html">
  56. <body class="remarkdown h1-underline h2-underline h3-underline em-underscore hr-center ul-star pre-tick" data-instant-intensity="viewport-all">
  57. <article>
  58. <header>
  59. <h1>Permacomputing Update 2021</h1>
  60. </header>
  61. <nav>
  62. <p class="center">
  63. <a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
  64. <use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-home"></use>
  65. </svg> Accueil</a> •
  66. <a href="http://viznut.fi/texts-en/permacomputing_update_2021.html" title="Lien vers le contenu original">Source originale</a>
  67. </p>
  68. </nav>
  69. <hr>
  70. <p>It is now more than a year since I wrote <a href="http://viznut.fi/texts-en/permacomputing.html">my "early notes" about
  71. Permacomputing</a>. At that time, I was not yet aware of anyone else having
  72. similar ideas, so I've now decided to write an update that connects my ideas
  73. with the existing discussions and activities. I also want to share some new
  74. ideas I have been pondering about. This text is about 33K characters / 4900
  75. words long, so allocate your time accordingly.</p>
  76. <h2>1. A fragmented pluriverse</h2>
  77. <p>The "biosphere-aware computing scene" is quite fragmented. There are many
  78. different islands (groups and individuals) that use different terminology
  79. and that are only now discovering each other. It is therefore important to
  80. build bridges between the islands.</p>
  81. <p><a href="https://computingwithinlimits.org/">Computing within Limits
  82. workshops</a> that started in 2015 form an important hub but have been
  83. rather invisible from non-academic perspectives. Many interesting papers
  84. have come out of these workshops, but I would really like to see more
  85. practical and/or longer-term projects that go beyond the shortish workshop
  86. papers. Computing within Limits branched out of a larger field of
  87. "sustainable" ITC <a href="http://urn.kb.se/resolve?urn=urn:nbn:se:uu:diva-375131">that is known
  88. to have huge problems</a>.</p>
  89. <p>Another hub is in the <a href="https://en.wikipedia.org/wiki/Fediverse">Fediverse</a>, particularly
  90. around the Mastodon server <a href="https://merveilles.town/">Merveilles.town</a> that centers around
  91. creativity and sustainable technology. Many of these productive hackers,
  92. artists and activists also participate in the "smolnet"/"smallnet",
  93. including the space of the <a href="https://gemini.circumlunar.space/">Gemini</a> protocol. My
  94. Permacomputing article was very well received in these circles and many have
  95. adopted the concept for their use.</p>
  96. <p>Then there's the "Sustainable Internet" activism that has the <a href="https://branch.climateaction.tech/about">Branch online magazine</a>. I
  97. tend to lump this together with the various "solar web" projects such as the
  98. <a href="https://www.lowtechmagazine.com/2020/01/how-sustainable-is-a-solar-powered-website.html">solar-powered
  99. version of Low-Tech Magazine</a> and the <a href="http://solarprotocol.net/">Solar Protocol</a>. Also somewhat related
  100. is the <a href="https://smallfile.ca/">Small File Media Festival</a> that
  101. criticizes the carbon footprint of streamed media with smallish (video)
  102. files. This is an area where the demoscene could make important
  103. contributions.</p>
  104. <p>In addition to the generic groups of like-minded people, there are
  105. specific projects, such as <a href="https://collapseos.org/">Collapse
  106. OS</a>, whose participants don't necessarily have connections to wider
  107. groups.</p>
  108. <p>Occasionally, an online article pops up that expresses similar concerns
  109. and ideas as I did with the Permacomputing essay, like Wim Vanderbauwhede's
  110. <a href="https://wimvanderbauwhede.github.io/articles/frugal-computing/">Frugal
  111. computing</a>. It is great to see that many different people independently
  112. come to similar conclusions, but this can also be seen as a sign that we
  113. need more social media activism and awareness-rising even to make all the
  114. concerned people find each other.</p>
  115. <p>Marloes de Valk has been <a href="https://computingwithinlimits.org/2021/papers/limits21-devalk.pdf">mapping</a>
  116. this scattered "pluriverse" and its terminology, but I have the feeling that
  117. this only scratches the surface, and that there's a lot of relevant practice
  118. going on in e.g. non-Western countries.</p>
  119. <p>A major problem with this "pluriverse" is the lack of a common name to be
  120. used in communication. "Permacomputing" scored quite high in De Valk's
  121. Fediverse poll, and I have no objections against using it for this purpose.
  122. Something like "radically sustainable computing" might also be a good
  123. umbrella term ("radically" being the keyword that differentiates it from the
  124. greenwashed capitalism of "Sustainable ITC").</p>
  125. <h2>2. Collapse Informatics</h2>
  126. <p>Many of the early Computing within Limits papers discuss collapse and
  127. scarcity scenarios from somewhat bleak viewpoints. In later years, the
  128. research community started to reframe itself in more positive ways by
  129. 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
  130. Sustainability</a></i> and Escobar's <i><a href="https://www.dukeupress.edu/designs-for-the-pluriverse/">Designs for
  131. the Pluriverse</a></i> – just like Permacomputing draws inspiration from
  132. Permaculture. But even when focusing on a positive vision, one should not
  133. take anything for granted. If a vision cannot survive a collapse of
  134. industrial production or network infrastructure, it isn't resilient
  135. enough.</p>
  136. <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:
  137. Hardware and Software After Collapse</a></i> that e.g. estimates lifetimes for
  138. various hardware components, with the conclusion that it may be possible to
  139. maintain some of current computer hardware for several human generations
  140. even if the entire semiconductor industry collapsed right now. Solderpunk
  141. (the creator of the afore-mentioned Gemini) has a concrete proposal for a
  142. "<a href="gopher://zaibatsu.circumlunar.space/0/%7esolderpunk/phlog/the-standard-salvaged-computing-platform.txt">standard
  143. salvaged computing platform</a>" based on smartphone/tablet e-waste. I'm
  144. sure that there are components with much longer potential lifespans (Jang et
  145. al. estimate current mobile hardware to be able to persist for about one
  146. generation), but at least there would be heaps of this type of junk
  147. available in the early years. I'm personally interested by the possibilities
  148. of microcontroller-based smartcards (that are even more ubiquitous than
  149. mobile phones but have entirely different challenges).</p>
  150. <p>Jang et al. also have a few interesting words about maintenance culture.
  151. In the same way as religious organizations continued to maintain ancient
  152. Chinese roads that no longer received governmental support, computing could
  153. be maintained in a post-collapse world by "semi-ascetic cultural
  154. organizations whose primary focus may or may not be computing". I have
  155. personally been fascinated by the potential of monastery-like communities to
  156. preserve science and technology even during "dark ages" when the society at
  157. large sees no value in them. In medieval Europe, some monasteries even
  158. 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
  159. power</a>.</p>
  160. <p>The term <i><a href="https://www.researchgate.net/publication/262276832_Collapse_Informatics_and_Practice_Theory_Method_and_Design">collapse
  161. informatics</a></i> comes from Bill Tomlinson who suggests that one should look
  162. into the existing computing practices in groups that have voluntarily chosen
  163. to live off-grid or in other "collapse-like" conditions. I might also want
  164. to include those who do so involuntarily, as well as those who have made
  165. "collapse-compatible" decisions specifically with computing (e.g. artists
  166. who specialize in old hardware).</p>
  167. <p>I don't know if there is going to be a collapse, but I'm quite sure that
  168. the entire society needs to reduce energy consumption, lengthen
  169. technological lifespans and reduce superfluous dependencies. Recognizing the
  170. 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
  171. disassembly</a></i> is an example of a concrete goal that supports hardware
  172. longevity in both collapse and non-collapse scenarios.</p>
  173. <h2>3. Anti-utilitarianism</h2>
  174. <p>In profit-oriented societies, people often try to make themselves and
  175. their fields of expertise as important and useful as possible. It has
  176. therefore been delightful to learn about visions that detach computing from
  177. all utilitarian purposes.</p>
  178. <p>Brendan Howell's <i><a href="https://moddr.net/rustic-computing/">Rustic
  179. Computing</a></i> is an artistic project that depicts computing as "the pastime
  180. of dilettantes, amateur scientists and gentleman tabulators who construct
  181. machines to manipulate abstract symbols with no practical application".
  182. Computer components are built using pre-industrial technology, which reminds
  183. me of early mechanical computers such as Zuse's Z1. When computers are built
  184. with non-pollutive technologies, they don't need to justify their existence
  185. by paying back their ecological debts. And since they have no practical
  186. purpose, they don't even have to be faster or better than manual
  187. paper-and-pencil calculation. They can just be interesting and important the
  188. way they are.</p>
  189. <p>I see much of the same attitude in <i><a href="https://compudanzas.net/about.html">Compudanzas</a></i>, a research
  190. project that reimagines computing in the form of "seemingly useless"
  191. activities such as rituals and dancing.</p>
  192. <p>In Steve Lord's idea of <i><a href="https://thedorkweb.substack.com/p/the-100-year-computer">Heirloom
  193. Computing</a></i>, a computer that has been made to last for many generations
  194. can be a piece of family history that evolves with the family, keeping
  195. permanent traces from every generation that has used it, and does not need
  196. to have any purpose besides this.</p>
  197. <p>As suggested by Jang et al., a post-collapse society that has eventually
  198. lost all of its artificial computing capacity may still want to continue the
  199. practice of computer science in a purely theoretical level, as a form of
  200. mathematics. This is another example of how computing may remain meaningful
  201. for some pockets of culture even with no ability to run any potential
  202. applications.</p>
  203. <p>Detachment from utilitarism may (perhaps paradoxically) give way to a
  204. deeper importance and meaning. I'm particularly thinking about Yuk Hui's
  205. 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>
  206. which refers to a unified harmony between technology, culture and non-human
  207. nature. Modern technological thinking lost this harmony by turning
  208. everything into utilitarian resources. An interesting point made by Hui is
  209. that every culture should find its own approach to cosmotechnics – so, we
  210. would be replacing a homogenous global utilitarian monoculture with a rich
  211. and diverse polyculture.</p>
  212. <h2>4. Limits of imagination</h2>
  213. <p>It is often difficult to even imagine a kind of computer culture that
  214. does not suffer from unlimited growth. Even the most interesting real-world
  215. examples (such as the Soviet computing culture) exist somewhat in the shadow
  216. of Western developments and ideologies. So, there's no real "other" to
  217. contrast the growth-obsessed mainstream computing with.</p>
  218. <p>Computing within Limits papers have also given me an impression that some
  219. scholars even find it difficult to imagine e.g. how software development
  220. could take place without the Internet. In cases like this, I might suggest
  221. looking into the actual history and listening to people who have experienced
  222. it. Even though the history of computing isn't nearly as diverse as it could
  223. or should be, it is still worthwhile to study it. And definitely not only
  224. the mainstream "winners' history" but everything from the various cultures
  225. and subcultures.</p>
  226. <p>Eriksson and Pargman <a href="https://computingwithinlimits.org/2018/papers/limits18-eriksson.pdf">have
  227. suggested the use of counterfactual history</a> to assist imagination.
  228. Sadly, their own <i><a href="https://www.researchgate.net/project/Coalworld">Coalworld</a></i>
  229. scenario (with the point of divergence being an early-seventies "peak oil"
  230. event) has not yet reached the point where computing can be elaborated. I
  231. wish there was more speculation (both fiction-oriented and academically
  232. rigorous works) that would present thoroughly-imagined alternatives to the
  233. actual history.</p>
  234. <h2>5. Alternative paradigms</h2>
  235. <p>I've already mentioned several "alternative paradigms of computing":
  236. <i>frugal computing</i>, <i>heirloom computing</i>, <i>rustic computing</i>,
  237. <i>collapse informatics</i>. But there are still a few more to add:</p>
  238. <p><i><a href="https://computingwithinlimits.org/2018/papers/limits18-mann.pdf">Regenerative
  239. computing</a></i> is Mann et al.'s idea of applying Hes &amp; du Plessis'
  240. <i>Regenerative sustainability</i> to computing. The most
  241. Permacomputing-relevant part of the Limits'18 is quite dense, so I'll quote
  242. 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
  243. for hope: pathways to regenerative sustainability</a></i>)</p>
  244. <blockquote>
  245. (3) Move beyond efficiency as the primary lever available to computing. -
  246. These new narratives should look to nature and ecology to demonstrate the
  247. interplay between computing, society and biological systems where limits of
  248. these systems are respected and worked with.<br>
  249. (4) Integrate ecological worldviews into computing's narratives and
  250. processes both the theory such as living systems and deep ecology, and
  251. values sets:
  252. <ul>
  253. <li>Integrity - maintaining the wholeness of [wider] systems, ensuring that
  254. structure and relationships remain intact and functioning as they
  255. should.</li>
  256. <li>Inclusivity - "interacting with the world in its entirety" [7, p. 35],
  257. engaging and integrating with all dimensions, levels of existence and
  258. knowledge.</li>
  259. <li>Harmony - all elements cooperate through relationships that are
  260. respectful in order to avoid dissonance.</li>
  261. <li>Respect - all parts of the world have intrinsic worth and all existence
  262. is part of the extended self, and therefore all self-respect is extended to
  263. mutual respect for the world.</li>
  264. <li>Mutuality - "we are in this together, and what happens to ‘others’ will
  265. also have an effect on self" - see: compassion, treating others the same as
  266. yourself.</li>
  267. <li>Positive reciprocity - "reciprocating in a way that is
  268. of benefit to and advances the relationship between
  269. self and extended self" [7, p. 35].</li>
  270. <li>Fellowship - an extension of mutuality and positive reciprocity, where
  271. the world is co-created by humans in partnership with nature.</li>
  272. <li>Responsibility - morally accountability for the consequences of our
  273. actions in an uncertain and unpredictable world</li>
  274. <li>Humility - change is constant, we cannot know the true consequences of
  275. our actions</li>
  276. <li>Non-attachment - In order to adapt to changing circumstances it is
  277. important to uphold non-attachment in order to decouple from “the futility
  278. of trying to hold onto anything in an ever changing world including ideas,
  279. dogmas and strategies” [7, p. 36]</li>
  280. </ul>
  281. </blockquote>
  282. <p><i>Convivial computing</i>, from <a href="https://www.researchgate.net/publication/235173004_Constrained_Design_Processes_Steps_Towards_Convivial_Computing">Fischer
  283. &amp; Lemke's 1987 paper</a>, is an earlier example of taking ideas from
  284. ecologically conscious thinking into computing (in this case, from Ivan
  285. Illich's book <i>Tools for Conviviality</i>). Even earlier, Lee Felsenstein
  286. had been inspired by the same book when designing the Osborne 1 personal
  287. computer. In both cases, however, the ecological aspects of Illich's thought
  288. are ignored. Also, Fischer &amp; Lemke's paper doesn't feel at all like a
  289. forgotten masterpiece of groundbreaking thought – the ideas actually seem to
  290. be very much in line with what was implemented in the "<a href="https://en.wikipedia.org/wiki/Rapid_application_development">RAD</a>
  291. tools" of the 1990s. And some of these tools (Delphi, Visual Basic) felt
  292. like the epitome of bloat at the time.</p>
  293. <p><i><a href="https://computingwithinlimits.org/2015/papers/limits2015-raghavan.pdf">Benign
  294. computing</a></i> basically advocates keeping things small in order to keep
  295. the problems caused by them small. Currently, huge problems are created by
  296. huge, centrally-managed systems built with the principles of abstraction and
  297. indirection. Raghavan's critique of these principles is very similar to how
  298. I see "<a href="http://viznut.fi/texts-en/maximalism_virtualism.html">maximalism and
  299. virtualism</a>". I also completely agree with Raghavan about that "the
  300. utopian notion of creating new technology that is strictly "beneficial" or
  301. that advances "development"" must be rejected.</p>
  302. <h2>6. Permacomputing practice</h2>
  303. <p>My Permacomputing article from 2020 is basically a vision of a new kind
  304. of computing that works in a radically different way in a radically
  305. different society. It does not give many guidelines towards actual practice
  306. or how to transition towards permacomputing, so maybe I should cover this
  307. area a little bit.</p>
  308. <p>I have been reluctant to name specific technologies or design constraints
  309. for permacomputing. This is because I want to support a diverse polyculture
  310. of ideas and possibilities. Asking what is the most suitable programming
  311. language for permacomputing is a bit like asking what is the most suitable
  312. plant for permaculture – the entire question contradicts itself. There is no
  313. "silver bullet" – there isn't one even in the mainstream industry despite
  314. its continuous attempts to uniformize everything. However, there can be
  315. design wisdom about the strengths, weaknesses and mutual interactions of
  316. specific elements, and this wisdom helps with choosing a language, a plant,
  317. an algorithm or a design pattern for a specific place.</p>
  318. <p>In software, nothing that can be run locally is "poisonous" per se. Even
  319. if something consumes a lot of energy, it does not need to mean more than
  320. that the consumption must be restricted to when that energy is available.
  321. Far more important questions are how the hardware is obtained and
  322. maintained, and how the energy is produced.</p>
  323. <p>I have noticed that many "sustainable" or even "low-tech" computing
  324. projects have been built on cheap DIY-oriented boards such as Raspberry Pi.
  325. Even though these may be among the best of the currently available options,
  326. it should be noted that they have been designed for hackability and
  327. replaceability rather than longevity or repairability. There might be a need
  328. for a radically repairable and modifiable hardware basis to fulfill similar
  329. purposes. Radical modifiability might include the ability to interface with
  330. a large variety of different chips (processors, SoCs etc.) – this would help
  331. maximize the usable lifespans of those chips.</p>
  332. <h3>6.1. Low complexity</h3>
  333. <p>Keeping systems very simple but very capable is a good guideline for a
  334. lot of permacomputing, but particularly so for the crucial basic software
  335. used to enable salvaged/makeshift hardware. Bare-hardware Forth systems
  336. (such as Collapse OS or OpenBIOS) are very capable for their low complexity,
  337. and can be small enough even for rudimentary 8-bit microcontrollers.</p>
  338. <p>One possible approach to simplicity is to try to keep things simple
  339. enough that they can be thoroughly understood and (re)implemented by one
  340. person. This applies not only to application programs but the dependent
  341. elements as well (programming language, operating system, firmware,
  342. hardware). This is not to say that people should write everything from
  343. scratch but to keep the complexity human-graspable. The ideal of human-sized
  344. computing is particularly applicable to systems that are used as tools
  345. (because tools in general should be thoroughly understandable to their
  346. users). Also, in decentralized "post-collapse" societies, the local
  347. all-around experts ("village hackers") should be able to master all aspects
  348. of the local computing systems in order to maintain them and to adapt them
  349. to various local needs. All this becomes much easier if complexities are
  350. kept low or moderate.</p>
  351. <p>The effective complexity of a software program can be estimated by
  352. summing its executable size with the size of the minimum set of dependencies
  353. required to run it (including the OS components). Alternatively, one can
  354. calculate its bootstrap complexity (by summing the size of all code and data
  355. required to compile the program, the dependencies, and the entire dependency
  356. network of the toolset required for the compilation in the smallest system
  357. that can run them). These types of assessment strongly favor programs that
  358. are written in non-bloated languages and can be made run on bare hardware –
  359. even if they can also run in bloated environments and use their special
  360. features.</p>
  361. <p>One way to deal with huge platforms is to create "pockets of simplicity"
  362. such as <a href="https://100r.co/site/uxn.html">simple virtual machines</a>
  363. that can also run on bare hardware. Emulators of existing hardware platforms
  364. are a special case of this. VMs are particularly suitable for small things
  365. that require far less computation than what the hardware is capable of. A
  366. virtual machine may also help eliminate compatibility problems and code rot,
  367. if it is unambiguously defined and the definition is canonized (permanently
  368. frozen). If approached with mainstream engineering attitudes, however, VMs
  369. may easily lead to "Java-like" problems (wastefulness, incompatibilities,
  370. etc.) Setting artificial limits to memory usage and execution speeds may
  371. prevent some of these developments. One might also want to think about how
  372. to statically translate VM programs into native code for running on
  373. platforms that are actually small.</p>
  374. <p>In mainstream computing, "ease of use" is usually implemented as
  375. "superficial simplicity" or "pseudo-simplicity", i.e. as an additional layer
  376. of complexity that hides the underlying layers. Meanwhile, systems that are
  377. actually very simple and elegant are often presented in ways that make them
  378. look complex to laypeople (think about the esoteric syntax of Forth or Lisp,
  379. for example). Ideally, UIs should reflect, amplify and illustrate the
  380. underlying elegance instead of trying to hide or misrepresent the inner
  381. workings. The earliest versions of the Apple Macintosh OS manage to do this
  382. to some extent (the system is not much more complex than the UI
  383. representation, every file is represented by an icon, program files are
  384. stand-alone without external dependencies, etc.)</p>
  385. <p>When minimizing the internal complexity of a system, however, it should
  386. not be isolated from the complexity of the external world. Computers are
  387. dependent on energy availability, temperature and other conditions, so they
  388. should be able to adjust their operation to the changes in these conditions
  389. – even if environmental monitoring is not among their designated tasks.</p>
  390. <h3>6.2. Towards concrete examples</h3>
  391. <p>Permacomputing has so far been defined in ways that emphasize generic
  392. ideas and a wide diversity of possibilities. However, in order to actually
  393. create something that represents permacomputing, one needs to make a lot of
  394. specific design decisions. Concrete examples (either real projects or
  395. mockups) may help with this. In order to cover the possibility space, we
  396. need a lot of different examples from different points of view.</p>
  397. <p>One possible starting point is to think about a general-purpose
  398. single-user computer that remains usable and relevant as long as possible
  399. even in a collapse scenario. Of course, any computer should be
  400. end-user-programmable and have some kind of programming interface to
  401. facilitate it, but what would be the concrete applications this kind of
  402. computer would be used for?</p>
  403. <p>I assume that viewing text files from physical storage devices (such as
  404. flash memory) is what would persist the longest in any scenario. A few
  405. gigabytes of storage would be enough for an entire library of literature
  406. that could be valuable for centuries. And accessing it would be possible
  407. (although not comfortable) even with very rudimentary post-collapse I/O
  408. devices (such as a few switches and indicators for a manual serial protocol
  409. – somewhat like using a Morse code telegraph).</p>
  410. <p>It may be theoretically possible to even read data directly from a USB
  411. flash drive with this kind of manual "telegraphy", but the complexity of the
  412. USB protocol would probably get overwhelming. Fortunately, a complex
  413. protocol implies that there is a (re)programmable microcontroller in the
  414. device, so one may want to reprogram it to support a simpler protocol. One
  415. could also add a "backdoor" that enables the device to run arbitrary
  416. programs from the drive, thus unleashing its potential for general-purpose
  417. computing. It may even be possible to get a USB stick to drive "proper"
  418. interface devices such as display screens despite the low number of I/O pins
  419. (two output pins are enough for composite video, but LCD panels
  420. unfortunately tend to need much more, so some kind of a multiplexer would be
  421. required). This could help reduce and postpone the need for "Morse
  422. code".</p>
  423. <p>These could become general guidelines for maximizing the lifespans of
  424. arbitrary programmable devices: 1) make it as straightforward as possible to
  425. run arbitrary code, 2) support an electrically simple interface that can
  426. even be operated manually in times of far-future scarcity.</p>
  427. <p>Another persistent application besides file viewing would be text
  428. editing. It has been prominent in personal computers since the early years
  429. and probably will be in just about any scenario. It would also imply the
  430. need for general file management tasks such as copying files between storage
  431. devices. Programs for doing these tasks would be among the first to
  432. implement for any "permacomputer" that does not require special expertise to
  433. use.</p>
  434. <p>Telecommunication is important but does not require computers – messages
  435. may well be relayed with classical amateur radio methods. Also, computer
  436. file-sharing networks can well be based on physical media. However, the
  437. existence of a radio and a computer makes it appealing to combine the two. A
  438. program for transferring files and text streams over abritrary channels, in
  439. one- or two-way protocols or packet protocols, with or without error
  440. correction and/or encryption, would be a fine inclusion to the set of
  441. "collapse software".</p>
  442. <p>Of course, supporting far-future post-collapse scenarios does not mean
  443. that one should stick to far-future post-collapse practices – rather, it
  444. ensures that there are fallbacks for everything. You can use a
  445. high-resolution screen today, but the system will work fine even with
  446. tomorrow's more rudimentary display. You can run a complex OS today, but the
  447. simple OS in the firmware ROM is also perfectly fine for editing a text
  448. document.</p>
  449. <p>I imagine that this "simple OS" would normally look either like a plain
  450. Forth interpreter or an orthodox file manager (i.e. a Norton Commander
  451. clone), depending on whether the computer is connected to a sufficient
  452. screen or not. For screens that are a bit too small for the OFM there might
  453. also be an intermediate option that resembles early-2000s cellphone
  454. interfaces. All of these modes would be usable even with quirky input
  455. devices (such as a game controller, a single telegraph key or a barely
  456. functional touchscreen). Hardware is accessed via Forth words that can be
  457. straightforwardly redefined if there are unexpected hardware changes (such
  458. as specific glitches that need to be bypassed).</p>
  459. <p>The OFM would allow one to browse, view and manipulate files, run
  460. executable files, edit text files and enter Forth commands. It could also be
  461. set up as a bootloader to load a more complex OS, but loading one would
  462. often be unnecessary, as many programs (especially ones that favor
  463. single-tasking) would also be available as "Forth" executables (that may
  464. also be native binaries that may or may not use Forth words) or as "ROM"
  465. files runnable with a simple VM.</p>
  466. <p>Systems that don't have much capacity to spare would perhaps only have a
  467. plain Forth interpreter, or if even that would be too bloated, something
  468. like the standard byte protocol used by smartcards.</p>
  469. <p>Longevity maximization easily leads to an emphasis on conservative and
  470. well-tested ideas, so this example may sound a little bit bleak. A fancier
  471. starting point (such as one based on ideas from unconventional computing)
  472. would perhaps give more room for fancier permacomputing ideas that take more
  473. distance from fossil-era computing.</p>
  474. <h3>6.3. Sustainable cyberspace</h3>
  475. <p>There are many projects that address the sustainability problems of the
  476. World Wide Web. Activism for sustainable websites, solar-powered servers,
  477. new protocols, simpler document formats. However, these often take the
  478. underlying Internet for granted. The access may perhaps be slow at times or
  479. places, and a solar-powered server may be sometimes offline, but any place
  480. of the world is still supposedly accessible from any other place of the
  481. world at any time. The weirdness of this assumption may not even be obvious
  482. to modern Internet users – after all, it is in the core of nearly every
  483. major service/protocol (perhaps apart from Email and Usenet that can also
  484. propagate over temporary connections).</p>
  485. <p>I see need for a decentralized protocol that works painlessly in
  486. conditions where everything is not constantly available. Where individual
  487. servers or communication links may be online or offline depending on
  488. circumstances. Where other parts of the network may only be accessible via
  489. temporary connections, physical file-sharing or data mules. Where your
  490. messages still reach their destinations, where you still get the files you
  491. need, and where "social media" discussions can still thrive, despite all
  492. these logistical constraints.</p>
  493. <p>For some inspiration for the required mindset, one may think about how
  494. files were collected and propagated in "pre-Internet" conditions (BBSes,
  495. friend-to-friend file copying) and how to make these processes as automatic
  496. as possible.</p>
  497. <h2>7. Collapse-tolerant business</h2>
  498. <p>I don't often think about how to do business in the capitalist economy,
  499. but in the early 2021 I asked myself what kind of IT company (or other type
  500. of IT-related organization) would thrive both before and after a collapse. I
  501. wanted to challenge my prejudice that anything you do for profit/living will
  502. always be somewhat "greenwashed" instead of properly sustainable.</p>
  503. <p>Here are my ideas of how a relatively small "permacomputing company"
  504. could operate in the "age of abundance":</p>
  505. <ul>
  506. <li>Accept software-related and other customer projects just like any
  507. average IT company, as long as they are in line with strict eco-ethical
  508. standards. Refuse to contribute to the wasteful use of resources, and
  509. strongly prefer doing things in sustainable and robust ways. Make these
  510. standards a part of the company brand.</li>
  511. <li>Have long-term in-house research and development projects related to
  512. radically sustainable computing, both software and hardware. Convince
  513. investors about their vitality to the future of civilization. Also practice
  514. permaculture (or constantly co-operate with ones who do) and try to connect
  515. it to everything else that the company is doing.</li>
  516. <li>Self-host everything you need for software work on local physical
  517. servers. This includes all networked applications as well as an extensive
  518. library of software and documentation (including repair manuals and OS
  519. distributions for all relevant hardware). Offer hosting services to make
  520. use of the surplus.</li>
  521. <li>Produce as much of your own energy as possible with solar panels, wind
  522. turbines etc. Sell the surplus to the company that maintains the grid.</li>
  523. <li>Repair and maintain all hardware by yourself. Maintain a storage
  524. facility for old/recycled hardware. Offer services related to repairing and
  525. recycling (in a small scale, for now). Maintain a hackerspace or constantly
  526. co-operate with one.</li>
  527. <li>Support forms of culture that strengthen the status of radically
  528. sustainable computing/technology (e.g. hackerspaces, education, demoscene
  529. events, art projects that use "obsolete" hardware, etc.)</li>
  530. <li>Make sure that many of the employees live close to the office. Maintain
  531. spaces that can be turned into apartments once transportation becomes more
  532. difficult.</li>
  533. </ul>
  534. <p>Once the world has completely changed, the focus or the organization will
  535. become somewhat wider:
  536. </p>
  537. <ul>
  538. <li>Accept any customer projects related to computing or any other
  539. technology you happen to understand. Offer repair services.</li>
  540. <li>Collect/buy "e-waste", build working computers and appliances out of it,
  541. sell them.</li>
  542. <li>Keep in contact with the rest of the "computing scene" even if
  543. long-range communication networks have collapsed. Share information and
  544. trade hardware components. Use couriers if necessary.</li>
  545. <li>If microchips or some other essential components are no longer produced,
  546. participate in attempts to restart the production (in a small scale, for
  547. now – until we learn how to do it sustainably).</li>
  548. <li>Similarly, try to rebuild communication networks if they have collapsed.
  549. Offer communications services, maybe maintain "Internet cafés".</li>
  550. <li>Maintain digital and physical libraries of pre-collapse and
  551. post-collapse information. Print physical books. Participate in projects
  552. that support the continuing existence of science and education.</li>
  553. <li>Make sure that technological understanding will pass on to new
  554. generations. If necessary, educate the new employees (or cult members or
  555. whatever they may be called) from scratch.</li>
  556. <li>If it becomes impossible to make living out of this, start depending on
  557. agriculture. But in any case don't forget the importance of science and
  558. technology. If necessary, explain the importance in religious terms.</li>
  559. </ul>
  560. <h2>8. Postdigital advocacy</h2>
  561. <p>Art researchers recognize the concept of "postdigital" as a reaction
  562. against the so-called "digital revolution" that took place in the nineties,
  563. and especially against the typically "digital" esthetics. Using cassette
  564. tapes for music in a world where digital music formats are ubiquitous is an
  565. obvious example of "postdigital".</p>
  566. <p>But not all that is called "postdigital" is non-digital. Actually, much
  567. of it is very profoundly digital – pixel art and glitch art for example. The
  568. term is somewhat misleading – it does not only mean "the non-digital that
  569. comes after digital", but can also be read as "a later form of digital" or
  570. "something that comes after the digital revolution". It particularly seems
  571. to set itself apart from the "progress narrative" that wants to continuously
  572. replace everything with "bigger and better". This makes the idea relevant to
  573. permacomputing as well.</p>
  574. <p>When advocating lifestyles that abandon maximalism, it is important to
  575. frame it in a positive way. Settling for simple and coarse things does not
  576. need to be a "sacrifice" but something genuinely better than the mainstream
  577. alternative. "Postdigitality" is already a prominent force in e.g. indie
  578. games that often choose to use pixel graphics as a "modern" esthetic
  579. preference rather than as "retro nostalgia". This gives hope that a major
  580. paradigm shift is possible for the mainstream digital culture in
  581. general.</p>
  582. <p>During the global pandemic, many people have been extremely dependent on
  583. prohibitively complex digital blackboxes. I therefore assume that, once the
  584. pandemic is over, many people will want to distance themselves from the
  585. mainstream digital world. To concentate on non-digital things but also to
  586. find a healthier relationship with the digital. I think this is something
  587. that advocates of radically sustainable computing should tap into.</p>
  588. <h2>Links</h2>
  589. <p>(Added 2021-08-27) Here are some links I failed to include in the
  590. original version of this page:</p>
  591. <ul>
  592. <li><a href="https://moddingfridays.bleu255.com/Main_Page">Modding
  593. 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
  594. culture". Includes a wiki and an XMPP chatroom.</li>
  595. <li><a href="http://civboot.org/">Civboot</a> is an educational project
  596. aiming at simplifying the requirements and dependencies of computer
  597. technology as well as increasing humanity's ability to understand it.</li>
  598. <li><a href="https://wiki.xxiivv.com/site/permacomputing.html">Permacomputing
  599. at the XXIIVV Wiki</a></li>
  600. <li><a href="https://communitywiki.org/wiki/SimpleSystemsManifesto">Simple
  601. Systems Manifesto</a></li>
  602. </ul>
  603. <p>Written by Ville-Matias "<a href="http://www.viznut.fi/">Viznut</a>" Heikkilä.<br>
  604. <b>2021-08-12</b>: initial release<br>
  605. <b>2021-08-27</b>: added the links section<br>
  606. <a rel="license" href="http://creativecommons.org/licenses/by/4.0/">
  607. <img alt="Creative Commons License" src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAFgAAAAfCAMAAABUFvrSAAAADFBMVEUAAAD///99fX2+w7rj0zguAAAA4klEQVRIx7WWgQ6FIAhFYf3/P9cjMX0K3rvStVwDT3QTRFS2jB/22DBkE9fI/WuwV639GnOrEILN/R6jKW4DCEaWftVWsWVJyjWX3M9NHTcne7j3fQH+42Zk8NNuy8BNlhTXOi3AqiM5V2KhhYGfv9xPH4DdV+oUrmGk8K1z3XzKwN2uQMBtJIDIwHZjwXCCUFIwKU39PKYIUduNKptMglCFnklp7gQhihB56M3L5tujOqqG75uA+dEU9wyWH6V5wMjR89CM2KVgzMf0IYpYRHE5ZskVRizKKA1g2Yi3tIU7sCfXlRBdibyVCwAAAABJRU5ErkJggg=="></a><br>
  608. This work is licensed under a
  609. <a rel="license" href="http://creativecommons.org/licenses/by/4.0/">
  610. Creative Commons Attribution 4.0 International License</a>.</p>
  611. </article>
  612. <hr>
  613. <footer>
  614. <p>
  615. <a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
  616. <use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-home"></use>
  617. </svg> Accueil</a> •
  618. <a href="/david/log/" title="Accès au flux RSS"><svg class="icon icon-rss2">
  619. <use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-rss2"></use>
  620. </svg> Suivre</a> •
  621. <a href="http://larlet.com" title="Go to my English profile" data-instant><svg class="icon icon-user-tie">
  622. <use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-user-tie"></use>
  623. </svg> Pro</a> •
  624. <a href="mailto:david%40larlet.fr" title="Envoyer un courriel"><svg class="icon icon-mail">
  625. <use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-mail"></use>
  626. </svg> Email</a> •
  627. <abbr class="nowrap" title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340"><svg class="icon icon-hammer2">
  628. <use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-hammer2"></use>
  629. </svg> Légal</abbr>
  630. </p>
  631. <template id="theme-selector">
  632. <form>
  633. <fieldset>
  634. <legend><svg class="icon icon-brightness-contrast">
  635. <use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-brightness-contrast"></use>
  636. </svg> Thème</legend>
  637. <label>
  638. <input type="radio" value="auto" name="chosen-color-scheme" checked> Auto
  639. </label>
  640. <label>
  641. <input type="radio" value="dark" name="chosen-color-scheme"> Foncé
  642. </label>
  643. <label>
  644. <input type="radio" value="light" name="chosen-color-scheme"> Clair
  645. </label>
  646. </fieldset>
  647. </form>
  648. </template>
  649. </footer>
  650. <script src="/static/david/js/instantpage-5.1.0.min.js" type="module"></script>
  651. <script>
  652. function loadThemeForm(templateName) {
  653. const themeSelectorTemplate = document.querySelector(templateName)
  654. const form = themeSelectorTemplate.content.firstElementChild
  655. themeSelectorTemplate.replaceWith(form)
  656. form.addEventListener('change', (e) => {
  657. const chosenColorScheme = e.target.value
  658. localStorage.setItem('theme', chosenColorScheme)
  659. toggleTheme(chosenColorScheme)
  660. })
  661. const selectedTheme = localStorage.getItem('theme')
  662. if (selectedTheme && selectedTheme !== 'undefined') {
  663. form.querySelector(`[value="${selectedTheme}"]`).checked = true
  664. }
  665. }
  666. const prefersColorSchemeDark = '(prefers-color-scheme: dark)'
  667. window.addEventListener('load', () => {
  668. let hasDarkRules = false
  669. for (const styleSheet of Array.from(document.styleSheets)) {
  670. let mediaRules = []
  671. for (const cssRule of styleSheet.cssRules) {
  672. if (cssRule.type !== CSSRule.MEDIA_RULE) {
  673. continue
  674. }
  675. // WARNING: Safari does not have/supports `conditionText`.
  676. if (cssRule.conditionText) {
  677. if (cssRule.conditionText !== prefersColorSchemeDark) {
  678. continue
  679. }
  680. } else {
  681. if (cssRule.cssText.startsWith(prefersColorSchemeDark)) {
  682. continue
  683. }
  684. }
  685. mediaRules = mediaRules.concat(Array.from(cssRule.cssRules))
  686. }
  687. // WARNING: do not try to insert a Rule to a styleSheet you are
  688. // currently iterating on, otherwise the browser will be stuck
  689. // in a infinite loop…
  690. for (const mediaRule of mediaRules) {
  691. styleSheet.insertRule(mediaRule.cssText)
  692. hasDarkRules = true
  693. }
  694. }
  695. if (hasDarkRules) {
  696. loadThemeForm('#theme-selector')
  697. }
  698. })
  699. </script>
  700. </body>
  701. </html>