•

We Need Apocalypse-Proof Software

By Alireza Alavi • 9 minutes read •


Table of Contents

  1. Preface
  2. How do we address this as software engineers?
    1. We must take an offline-first and local-first approach to our critical, not inherently online software
    2. We must make robust software that can work for years without needing to update
    3. We must make more software that are meant to help in situations like these
    4. Our software must contain offline documentation
    5. We should write efficient software that run great on low end systems
  3. Some software for apocalypse
    1. Documentation and knowledge
    2. File sharing
    3. Software package repositories
    4. Collaboration
    5. Communication
    6. Navigation
    7. Honorable mentions

Preface

After experiencing war, numerous revolution attempts and mass protests, and numerous extended internet blackouts, I have experienced how it is to live in situations where there is no internet and no connectivity (among other things).

In my country, Iran, we are currently going through a full internet blackout due to mass protests. Today, I wanted to start working on one of my projects (using Clojure and kit-clj), And right from the start, trying to start my dev server with clj -M:dev:nrepl I get faced by these errors:

```
Unable to fetch /home/alireza/.gitlibs/_repos/https/github.com/cognitect-labs/test-runner
fatal: unable to access 'https://github.com/cognitect-labs/test-runner.git/': Could not resolve host: github.com
```

So I can't work on my project when there is no internet. Which is pretty sad (it could still be run if I commented out some of the startup dependencies, but still).

Yesterday, I tried to connect my sister's Samsung phone to my NAS(network attached storage) to listen to music, and the file manager tried to download the FTP functionality from the galaxy store, although she had connected to the NAS before.
While my FOSS file manager "Material Files" already has FTP functionality built-in and it takes only 20MB of space on my phone.

You can see this pattern a lot. Software that are not online in nature, needing an internet connection.
Depending on where you live on the blue-ish globe, You might experience outages quite often, like we Iranians do. And it's not only about governmental outages. Many countries or places on the world simply don't have internet. You might be on vacation with no internet, maybe your internet subscription has ended, you might be in a cafe and you don't want to connect to the public internet, or maybe the zombies have broken loose and chewed your internet cable!
Its simple. You shouldn't need to be online for doing something inherently offline. We don't need to be constantly online.

Many of our software are built on top of the assumption of good, stable, high speed connectivity, up to date hardware and the ability to babysit, update and fix the software constantly.
In bad situations like this, you don't have any of this. You might go months without being connected to the internet, you might have to use decades old hardware, and the software should be reliable enough so you don't have to constantly babysit it.

In fact, creating software and hardware for "the apocalypse" or more realistically, "Civilizational collapse" has been a focus of many smart people over the years.
For example, the plan9 operating system or collapseOS are operating systems that are either specifically built for this scenario or fit very well with it. So these aren't just my schizophrenic thoughts, these are very much real experiences.

And this isn't just about the collapse of civilizations, wars, outages etc. (which are very likely).
Even disregarding these matters, we need to create software for worst case scenario, the same way good automotive manufacturers do (or used to do).
You can rely on a good car in pretty dire situations, pushing it much further from it's normal and rated usage, and it will be mostly fine.

How do we address this as software engineers?

We must take an offline-first and local-first approach to our critical, not inherently online software

It doesn't get worse than opening your text editor or image editor program and it not working because you are not connected to the internet.

If the nature of your software isn't online, make sure it doesn't require to be.

We must make robust software that can work for years without needing to update

This is a whole topic on how to make robust software, but in general:

  1. we have to release our software tested and verified, to sensible degree.
  2. we must use stable technology for our software development.
  3. we must create high quality software.

Can we start formally verifying every piece of software we write?
No. That is not feasible, because the cost would be too high, and some software isn't just that critical to justify the cost. But, we must verify and test our software, to the degree that is sensible for its criticality, to deliver stable and robust software. Software that works even when things go wrong. Not software that is glued together and falls apart as soon as it faces the most minor inconvenience.

We must make more software that are meant to help in situations like these

Bringing offline functionality for critical tasks will really help us in situations like these, like Kiwix, Zeal, and many others do.

Our software must contain offline documentation

In Neovim, you can do :help or for example :help netrw or any part or module of nvim and you will get pretty good documentation right there. Those .txt files are the official documentation of Neovim. That's what you see on the website too. This is great practice.
Most good plugins also add their manuals there.
The same goes for Emacs. I think Emacs is even stronger in that since how the codes are the documents.
Most good software will have man pages which you can use. There is a lot of information that you can get from a good manpage. We should write good manpages, or other forms of easily accessible offline documentation for our software.
For example, the fennel programming language provides it's whole tutorial in the manpages with man fennel-tutorial.

We should write efficient software that run great on low end systems

Do I need to dive further in this or did the recent global RAM shortage gave us the lesson we needed to learn?
We can't just keep bloating our software and expecting users to throw more hardware at it.

Some software for apocalypse

This can probably serve as a checklist for future events.

Note that circumventing governmental censorships is a topic of it's own, which will not be covered in this post. Here we are mostly trying to survive in the situation with what we have, and circumventing it is a pretty complex task that we won't cover in this post.
But make sure you are also always prepared for that case too. To be realistic, there will probably be governmental censorship in any critical situation as we saw during COVID-19 or other dire situations around the world.

Documentation and knowledge

File sharing

Software package repositories

Collaboration

Communication

Honorable mentions

Discuss this post on hackernews

  1. Self hosted and needs central servers, most likely a VPS (For when there is only "intranet"). ↩ ↩2 ↩3 ↩4