*** All this is very much a work in progess, be wary ***
The main issue people have with collapse computing is accepting to work on its concepts even if the chance of a general collapse are, fortunately, low. But we don’t have to live in a Mad Max post-collapse world to see that low-power, self-contained, easy to assemble/repair/use computing machines are a good thing.
I always thought that cyberpunk-style cyberdecks are a good starting point to design a post-collapse computer. They’re self-contained, portable, with an optimized interface (but neural connectors and a cyberspace-y virtual space to live in, instead, are not an option, sorry).
The cyberdeck concept is so popular that there’s plenty of real world versions made by hobbysts. Some are impressive in how they replicate cyberpunk vibe and aesthetics. And most of them are based on SBCs, so they actually, already are (relatively) easy to assemble and repair – if you know what you’re doing.
In general, hardware is not an issue in designing post-collapse computing devices. Boards like Raspberry Pis, or even Arduino stuff, have enough computing power, use relatively low energy and can be connected to a wide range of peripherals.
What I really find fun to work with is the software part. Also because designing an essential software operating environment goes against all what normal developers do in their jobs today: writing code that assumes you have unlimited resources for unlimited complexity and operating modes.
Collapse computing instead forces you to work with constraints and to develop a software environment that is simple, robust, adaptable, efficient. Look at any modern OS: it doesn’t have all this features. And a “collapse machine” shouldn’t present an OS concept. At least, not a conventional modern one. You don’t have the time to dwell in OS commands while you’re scavenging cities covered in dust, avoiding mutant killer squirrels.
The most efficient user interface for a collapse device is, I think, a REPL environment for a functional (or functional-ish) language. It’s easy to manage but lets you do many things, from basic calculations to define your own functions and assemble them in complex sequences. In some way, REPLs are (also) OSes.
A functional language makes sense, in a collpase device, because it makes problem solving easier. Decompose your problem in steps, turn them into functions, code and test them in the REPL. It’s easier than sitting at your desk – maybe you don’t even have one after the collapse – and writing long code pages in an imperative language you then have to compile and load.
The need of simplicity makes me choose basic, native and “safe” REPL environments: Forth or Common Lisp. Yes, they’re old languages but that’s an advantage, post-collaple: they’ve been engineered to work on basic machines, with basic interfaces and (if needed) no external libraries. You fire the REPL, create your functions/words, assemble your programs. And win over the mutant squirrels. If you’re clever.
Lisp and Forth REPLs on single-board computers are nothing new and are not difficult to implement. MicroLisp is a Lisp for SBCs available for many platforms and I’ve directly tested it on a very basic Arduino Uno board (one of my pet projects is to create a whole system around that implementation, we’ll see…).