Comment by fodkodrasz | Hacker News Reader

Comment by fodkodrasz | Hacker News Reader

I find the CollapseOS approach unrealistic and somewhat self-indulgent. In a real collapse scenario, having a portable Forth environment for arbitrary microcontrollers wouldn’t put us meaningfully ahead. The primary value of computers wouldn’t be to run new minimalistic programs from scratch for stuff we only automate in a situaton where we are living in economic and technical abundance, but to access and preserve existing information systems and whatever remains of digital infrastructure, especially libraries, CAD/CAM systems, etc.

A more practical strategy would be maintaining simple yet complete computing environments that can operate on salvaged hardware. NetBSD is a good example: it supports a wide range of hardware, has a relatively straightforward codebase, and provides a full source-based system with a usable graphical userland, with a wide variety of tools available.

In a “collapse computing” context, it is far more plausible to repair and reuse an x86-compatible machine than to rely on extremely minimal custom setups that can barely run a Forth interpreter. With salvaged x86 hardware, one could install a robust OS like NetBSD and immediately run a broad set of existing tools, which is likely to be far more useful than rebuilding a software ecosystem from near-zero on constrained microcontrollers.

This is why having a NetBSD and pkgsrc mirror is my approach to collapse computing instead of fantasizing on building from scratch.

Your reasoning is sound, but is already covered by Collapse OS' manifesto. It refers to two stages of collapse, Collapse OS being for the second.

As long as we have working modern machines, self-contained modern open source OSes, NetBSD being one, are good choices.

One problem there is with such system is their overall complexity. Sure, you can use them, and they're pretty flexible for the user. However, when necessity forces you to crack the kernel open, the learning curve is pretty big.

For example, let's imagine a computer with a broken SATA controller. How would NetBSD behave on it? Hard to say, NetBSD developers don't develop with that target machine in mind. Usually, when you have such a machine, you replace it or repair it. But what if you can't? Maybe you'll have to play in the kernel to manage to do something with that machine, route around it. Maybe it will work, but maybe you'll be stuck, and maybe that in that particular situation, it's going to have tragic consequences.

And that's kind of what Dusk OS (http://duskos.org/) is about.

Exactly, DuskOS is for maintaining a somewhat degraded level of civilization and perhaps rebuilding, while salvaged machines are still common. CollapseOS is there if things get even worse, to retain a minimal level of computing capability during the transition to whatever comes next. It’s hard to imagine the need for CollapseOS while things are still working, but in some horrible future where it’s the only system keeping the water system running, people will appreciate it.

The additional value in Collapse OS is that — as the hardware capable of running even Dusk OS (let alone a more complicated 32+-bit operating system) continues to break down and dwindle in supply — you still have an option such that you can reasonably-comfortably use those more constrained systems for simple tasks and free up the complicated hardware for complicated tasks. You don't need a multicore 64-bit CPU to keep a typical water system running; an 8-bit microcontroller is typically enough, and having a software stack already ready to go (including an ease of adapting to whatever specific hardware might be wired to that microcontroller's pins) is a pretty big deal even long before the point where we're shooting each other over the last Z80s and PICs.

Reply on news.ycombinator.com