Motivation

I've been recently searching for minimalist IT systems. In short, I am interested in sustainability and conviviality, with the help of modernity. These words have several meanings, so let's be specific. To me, sustainability means that I want to reduce the systems' footprint onto the world's resources: I want these systems to last a few decades (allowing the user to repair it), have efficient usage (consuming few energy) and be made of already existing materials (or to be reusable). The term 'conviviality' is probably badly chosen because it's often confused with pseudo-simplicity (hiding implementation details). As Illich, I intend instead to prevent users' dependency on their tools. Allow the user to use the tool on need only (not more, not less), and make it possible for the user to fully understand/adapt their tools.

These goal require to take the best of the existing solutions, but also to leverage modernity without nostalgia: new solutions are not good just because they are new, but old solutions are not sufficient against our societal challenges. We need the latest scientific outcomes, and things that are yet to be invented. That being said, I'm not sure of whether modernity actually eases or complicates my journey: I dream of advanced systems that may be easier to build with the state-of-the-art science. But I also see a tension between the conviviality where the user can understand and adapt the whole system, and modern science in which each piece is only understood by overly specialized experts. Begging for more research may also be perverted into some sort of business as usual, or greenwashing. But I still think that science could help (disclamer: I'm a scientist), even if nobody knows for sure the kind of research that we should pursue to foster convivial and sustainable IT systems.

These systems are very different from classical digital systems that are easily bloated, short-lived and pseudo-simple. Yet, I've discovered that many people explored these concepts before me, calling them lownum (low-tech IT in French), or permacomputing. This even comes with many variants. YMMV, but I'm personally not interested in Collapse Computing: I don't want to survive the Big Collapse by suffering for a short while. Instead, I'm more into frugal computing in a decent world where we can live our life in peace without hindering the next generations. I think we should build computers that last decades or even centuries and become heirlooms. If you think that there is no way we could reach such a future, then you probably need to read more SolarPunk.

Finally, I'm actually interested in building and experimenting with such systems. Half working proof-of-concepts speak louder to me than bright ideas, concepts and theorems. The crisis we face (climate change, energy and resource shortage, planetary limits, etc) are just baffling. I cannot handle the pressure if I only think about it, I need to consider and evaluate solutions. I'm not trying to save the world, just to save my mental health though personal actions. I'm not seeking for definitive solutions. I know I won't find anything useful to solve any notable problem. I personally need to goof around, but I'm far from my tiny expertise bubble. Please, bear with me.

What the problem could be

We constantly need to change our hardware because it's becoming too old for the new software, that keeps being stuffed with new features. All these features come at the price of an increased software complexity, that must be hidden behind over-simplified interfaces to remain usable on our brand new hardware.

For decades, I thought that the problem was with proprietary software, where new features are quickly built to push the users into buying new versions again and again. Things must be different with free software where the software authors want to reduce their burden by enrolling users in the development team. I was somewhat bothered to see that many usability improvements on Linux meant copying old windows desktops but hey, I use the terminal and emacs. I was saddened to see my machine suffering under Widelands while Settlers was fully playable on much less powerful machines, but hey! It's still ongoing and I could contribute to improve it. I remember how swindled I felt when Gnome decided to /simplify thing/ by removing some configuration options that I was actually using. I stopped configuring anything on that day. I now adapt myself to the changing conditions of my desktop, switching from Gnome to LXDE to KDE to XFCE to whatever where I can just type my text, read my mails, chat with friends, compile my code and surf the net.

Earlier this year, I realized how addicted I was to bloatware anyway. I was not using any closed source software and very few GAFAM services, but I was still reading my mails in a webmail, my agenda was in the cloud, I searched online things that are in a manpage on my machine, I was listening to music online, and I had 6 browser tabs just for all messaging solutions. Installing mattermost just meant installing yet another browser window. Even codium, my source code editor, was a web browser! (codium is to vscode what Chromium is to Chrome, and vscode is implemented with web technologies). I guess that I could use mac or even windows on a daily basis with no negative impact on my workflow! I tried to move back to my old setup such as Pidgin for the messaging, mutt for mails or emacs as a IDE, but I failed. They miss some features I'm now used to (pidgin: Mattermost; mutt: quick full-text search; emacs: nothing works before configuration). Some of my old tools also died under the technical debt. I also failed to switch to new tools, which all seem promising but unfinished. I considered contributing to the code, but I got lost in the forest of similar but different applications and frameworks that I could extend, each solution with its own flaws. Do the world really need so many IDEs, each loaded with so many advanced features? It's so frustrating to see that the vscode IDE by Microsoft is the best fit to my terminal workflow based on non-standard tools. If only it used less Gb on disk and in RAM. If only the other tools could rely more on a shared ecosystem instead of partially reimplementing everything...

I was distressed at this point, with a sick sad world outside, and my free computer slowly drowning in undue complexity, technical debts and efforts scattering.

Back in time, to fork history

I explored the history of computing to see whether the problem could be that we decided to copy Windows into Linux. I came upon Plan9, an experimental OS invented in the nighties by the people who invented UNIX in the seventies. This system seems loaded with good ideas: everything is a file (even the network -- the UNIX design pimple -- and even the services, so adding a mountpoint to your filesystem is the way to add a system service. Much cleaner that the SystemD bloat or the init.d quagmire of shell scripts), you can assemble features by plumbing processes together (even better than UNIX's pipes, you can script inter-application copy/pasting), the terminal is a nice workplace (even more than the VT100 that emulates the fifties), the shell syntax is sensible and not inspired by the frightening Algol (so manipulating arrays is accessible to simple humans), etc, etc.

I didn't try Plan9 myself (although some forks are still maintained), but it's certainly appealing. My extensive use of the terminal would be further improved with these ideas. When I read about Plan9, I dream of swarms of small interconnected programs that collaborate to do my work. Appealing, but I'm not really sure it'd be any simpler, actually. And I don't see any protection against bloatware here. Starting again with Plan9 instead of UNIX removes maybe 15 years of bloat development to my Linux, but it brings me 30 years back. I don't see why bloat wouldn't accumulate with Plan9 too. It would merely be another kind of bloat.

Design improvements through new limits

I now think that extendability, modularity and open-ended diversity are the root of all evils. If your system is not artificially limited, features are added just because it's possible. When the complexity hits, the users have to conform to the intended use cases even if it's not exactly matching their needs. Software is not meant to be adapted by its users. Cumbersome software architectures emerge to tame the code complexity. The technical debt accumulates faster in quickly changing, large code base. Perfectly generic and extensible software is a misguided objective. The Linux desktop ecosystem is not as sick as the javascript one, but it's still frustrating to see how frictions between individuals often hinder any code sharing between solutions. Do we really need so many desktop environments, with so little shared code?

In some sense, the free software development model falls short when it comes to develop modern bloatware, but it does not protect us per see against bloatware. I'm now contemplating systems that are limited by design. I'm wondering whether limiting the developers could be a solution to free the users.

One of the first such systems I've found is Gemini: a hypertext format that is explicitly designed to not be extensible. The stance is that HTML was a great approximation of the Memex but became a bloated monster over the years. To avoid that, Gemini is limited by design, and cannot be extended in any way. I like intend very much, but I'm still unsure that I like the result. For example, not being able to have inline links seems very limiting to me: you have to put the links in full text below your text, one per line. I'm not sure I'd like to read a Wikipedia obeying this restriction for internal links too. I may prefer Markdown, even if recent extensions such as CommonMark may enable future bloat.

Beyond data formats, the uxn virtual machine was designed specifically against bloat. Programs can only be 64kb at most, which naturally limits the program complexity. But this limit does not prevents the authors to implement some useful program on this system. The language and the VM are not efficient, but that's actually the point. And some people seem to actually enjoy programming with it. See this presentation on why and how the author ended up making uxn.

Limited hardware could also be used to prevent software bloat. uxn shows the path: its VM is ported to a variety of older hardware to allow their reuse. If all what you want is a typesetting machine, it should be possible to use a micro-controller as a tiny processor. Cortex M4 chips seem to have the same performance than a Pentium P3 or P4 of the nighties, for a much lower energy consumption. Their main limitation is memory with only 512kb and 4 Mb of flash memory! The lack of MMU makes it hard to use RAM. You cannot embed Linux on these chips, which makes it interesting and hard (and interesting).

Fantasy consoles such as TIC-80 or PICO-8 are great virtual machines offering exactly what you need to program a little retrogame in term of features, API and tooling. That's too bad that no such system exist for more general-purpose applications. I've heard that it was the case on Commodore64, but I never had any.

TempleOS and ZealOS

TempleOS is an incredible OS. As explained in this article, many people taunt this OS because the author suffered of mental illness and said that God asked him to build this OS as the third temple of the Bible. Yet, this is a truly impressive creation. The part that I like the most is that its Charter sets a hard limit of 100,000 lines of code for the kernel, the standard library, the compiler, the shell, and everything you need to build TUI applications and small graphical games. Components and libraries are banned to further enforce this limit. Incredible. For the record, bash alone is almost 150k lines while the Linux kernel is approaching 30M lines...

AFAIK, TempleOS is not maintained since Terry's death, but many forks exist. TinkerOS remains true to TempleOS on modern hardware. Shrine is another notable fork, adding TCP/IP and some other features. It claims to be a "TempleOS distro for heretics". This is because TempleOS has a very strong religious stance. Press F7 to study a verse of the bible. The system is called Adam, etc. I'm not a religious guy myself. I prefer when people do whatever they want with their religion, but privately (I'm French). I was thus delighted to find ZealOS. This fork seems to be the currently active fork, with many features (multi-core, changeable screen resolution, more than 16 colors, TCP/IP) and with the religious matter removed from the charter.

So back to the technical stuff. How does did the author manage to pack all those features in 100k lines only? Well. Through simplicity and by having at most one implementation of each thing. He invented his own C-like language, specifically tailored to make the compiler code simpler. To have only one parser, the shell uses the same programming language. The standard library contains very few containers. There is only one disk driver (when the modern AHCI driver was added, support for the older IDE standard was removed). Also, the design goals are also somewhat reduced. It targets x86_64 processors only (no 32bits, no exotic system), for a single user. There is no cryptography and no security: everything runs in ring 0, and there is no separation between applications, no memory protection whatsoever. At first, there were no networking to avoid any security issue. Programs are compiled on the fly, so that that you can inspect and change every piece of code. Every part must be readable for the whole to be blissful.

A first tour in the OS is appealing. The screen readability is hindered by the 8x8 font, but it's nice to have a complete text editor, a documentation browser with its own hypertext format where the images are embedded in the text file, and several non-trivial graphical games. I like very much the fact that the TUI includes graphical areas for images and games. I would call this a Mostly Textual User Interface (MTUI) or something. I would love to have a shell environment with inline images and I'm surprised that Terminology is the only shell allowing this. These features plus the simplicity of the implementation makes it a strong candidate for a truly convivial system.

But unfortunately, the implementation falls short. I tried to implement the French layout properly (by default, there is only one layout of course), and I failed. The compiler may be very fast, but it's dumb (I had weird warnings with composed conditionals but that may be my fault) and the error messages are a real pain. There is almost no comments in the code, and I failed to get the logic of the small part I was changing (the keyboard driver). It may well be my fault since I never modified a keyboard driver before, but I still have the feeling that improving and making this system robust and pleasant to hack will be require a lot of work. C code is not the most pleasant language, but a reduced C which design decisions are only guided by the compiler's complexity cannot be nice to use, unfortunately.

What's next

The internet is full of other ideas I'd like to explore. I just bought a STM32F446 micro-controller with a small screen to goof around with this nicely limited hardware. I also I need to invest some time in uxn. At first I misread the project page and thought that the project was a minimalism toy experiment with 4kb programs only. But things are very different with a the limit at 64kb. I definitely need to dig further in this rabbit hole. Modern and truly inventive OSes such as redox or TheseusOS may also be interesting to explore, even if I fear to be overwhelmed by the complexity of these systems.

Please send your comments to @emptty@mastodon.social.

Changelog

• 221128: initial release
• 221130: Rephrase the introduction to clarify that I'm not phasing out existing solutions, add some inline links, chase some typos.
• 230106: Add a link to a presentation by the authors of uxn on how and why.