Esoteric Operating Systems

esoteric /ˌɛsəˈtɛrɪk/

ADJECTIVE. Intended for or likely to be understood by only a small number of people with a specialized knowledge or interest.

Oxford Dictionaries

Operating systems are complex. Their mission is to provide a connection between some squishy flesh (that’s me and you, dear reader) and a plastic box made up of sand, lightning and even water in some cases. Its task boils down to taking orders from you via the software you’ve installed on top of it and translating those fuzzy ideas and wants into something your rigid CPU, hard drive, graphics card, etc., can understand.

There’s a few more services an operating system may provide though, and here’s where OS maintainers take the liberty to imbue their perspective of how a computer should be used:

Choices, choices. So many of them, enough to satisfy everybody’s individual needs and tastes, hopefully. When it comes to operating system design, there’s no shortage of opinions as to how things should be. Everybody should be moderately familiar with the idiosyncrasies of the two mainstream operating systems: macOS and its obsession with simplicity and aesthetics; Windows, on the other hand, tries to offer convenience and user-friendliness (and ads). Some of us don’t find these two standpoints towards daily computing good enough though, and search for alternatives which offer greater freedom and empower us to make more decisions of our own. The major Linux distributions and the BSDs offer this alternative path. Inside this alternative realm, a few brave ones decided to wander further off into the void and come up with even more contrived technical feats. This post will walk you through these depths, this uncharted landscape of magic and thrill. As is common in any journey into the depths of an abyss, we’ll start out at the surface and will crawl our way into the unknown. Our first stop is the (distant) family of less known Linux distros.

Ring 2: the Darker Face of Linux

Linux has been around since that fateful, timid post made by a young Torvalds in a usenet group in 1991 piqued the interest of a bunch of hackers which saw the potential perhaps not even Linus himself dared to see in his own creation. Since then, fuelled by its overarching emphasis on freedom and collaboration, Linux has grown from a basement OS hobbyist pet project to the massive, pervasive beast it is today, branching out into multiple lineages of distributions covering every possible niche in the computing space. There’s the big players everybody knows and loves: Canonical’s Ubuntu, Red Hat’s RHEL, Fedora and CentOS; Debian, Linux Mint… Then there’s the DIY family of distros like Slackware, Arch, Void, Gentoo, and their many spin-offs such as Antergos, Manjaro or Funtoo. There’s also the “libre” version of these, supported by the FSF: Trisquel, Parabola… Perhaps not as popular as the FSF may want to but in reality, other than having their non-GPL-compliant blobs carefully plucked out, there’s little difference between these distros and their non-GPL-compliant parents.

However tricky or difficult some of these distros may be, they’re not unpopular, they’re well known and most people who are into Linux have at least heard of them. But there’s so much beyond these. Let’s talk about the first one that comes to mind.


The first member of our family of obscure Linux distros is NixOS. The approach of NixOS is rather unique: it seeks to answer a question many people in the functional programming communities have pondered for ages: could we apply the concept of immutability to operating systems?

The answer is yes, indeed! But how? NixOS achieves it by viewing the state of the entire filesystem as an atomic unit of data, a snapshot of your operating system it can retrieve, restore and build upon. This is achieved via the Nix package manager, which instead of performing partial system upgrades by updating the files of individual packages which may in turn trigger further upgrades of their dependent packages, upgrades the entire operating system in one go. Simple (in a way), safe and completely atomic. You either get a brand-new OS from head to toe or you get nothing at all. Can’t get any better!

Suicide Linux

Perhaps you’re looking for something completely opposed to this though. You love to tip-toe on tightropes suspended above volcanoes infested by hungry crocodiles (volcano crocodiles, it’s totally a species, go look it up*). If you thrive on the face of uncertainty, then you might find Suicide Linux amusing at the very least. The premise of the system is, simply put, that every time you mistype something on the shell, the erroneous command will be automatically translated to a rm -rf /. It’s like playing the shell Russian roulette, only that it’s not luck but human error that will bring about the demise of your precious data. It goes without saying, Suicide Linux is experienced to its fullest as the superuser.

Ah, such a nice day today, the birds are chirping, the Sun is shining through the window, its warmth licking my face. Time to do some programming! Cool, let’s see where I left off last night, let’s go quickly edit my global bash_profile to set up some env vars I’ll be needing today ─ sudo namo /etc/profile ─ aaand my filesystem is gone.

Ubuntu Satanic Edition

Next up is something a bit more frightening on the surface but perhaps not as damaging, contrary to what one may think. I’m talking about Ubuntu Satanic Edition, or as the creators describe it themselves, Linux for the Damned!

Ubuntu Satanic Edition

In all fairness, there’s not a whole lot of excitement around this distribution, other than the appeal of its malevolent wallpapers and desktop theme design. Under the hood it’s just Ubuntu plus a customised version of GNOME 2. The sick wallpapers though…

Ubuntu Satanic Edition Wallpaper

Pop Star Scented Linux

But in all seriousness, what could be more Satanic than Satan himself? Well, do you happen to like Hannah Montana? Or perhaps Justin Bieber? In fact, do you like them so much you can’t ever stop thinking about them, usually falling asleep every night lulled to the rhythm of their velvety voices? Then I’ve just got the thing for you. May I introduce Hannah Montana Linux and Justin Bieber Linux. Based on (Ubuntu?), these are fully-fledged Linux distributions that are sure to delight the fans that just can’t get enough of their pop idols.

Hannah Montana Linux

Justin Bieber Linux

Red Star OS

You can’t call yourself a democracy, or a republic, or the best half of a peninsula if you haven’t developed your own official OS. The Democratic People’s Republic of (North) Korea’s official OS is called Red Star OS and is based on Linux, although I’m not entirely sure which distro (probably Red Hat).

Red Star OS (Credit: Wikipedia)

Red Star OS ships with a version of KDE 3 customised to make it look more like OS X, and it comes with all the essentials you could expect in an honest-to-God Government-funded operating system: a Firefox clone called Naenara, a few media utilities, a text editor, an e-mail client and even games like a version of Minesweeper which suspiciously resembles that of Windows XP, as well as some other games I failed to identify just by looking at the pictures on Wikipedia. The system comes with lots of Government-sponsored goodies pre-installed for your convenience as well as an impenetrable anti-virus which is able to detect content deemed inadequate by the Supreme Leader’s Party. If you can’t wait to get your hands on this dream system you’re in luck. Somehow, an image of Red Star OS 3.0 made its way to the Western civilisation. Once you install it, you’ll be able to carry out all of your routine computing chores just like any good ol’ North Korean citizen would. You can download Red Star OS 3.0 here.

Games in Red Star OS

(Credit: Wikipedia)

If anyone knows what the two games other than Minesweeper are about on the picture above, drop me a line.

Ring 1: Esoteric Potpourri

While these may not be necessarily less known than any of the examples I provided above, I decided to put them in a lower (higher?) classification because they are not mere rehashes of a well-known operating system. These systems were written mostly from scratch in isolation from all of the systems I’ve spoken about so far, or were derived from equally obscure projects. These systems provide their own kernels, ecosystem and their own, unique philosophy to OS design. First up is GNU Hurd.

GNU Hurd

Richard Stallman, the head of the FSF and the GNU project, is an ambitious man. He postulates that people should retain full ownership of their computers with the implication that they should be free to use, study, reproduce and share both the hardware and the software components that make up their computer. In order to do this, he founded the GNU project, which had the aim of developing a wholly free (as in freedom) operating system. But writing kernels is no easy task, and Stallman concentrated his efforts in developing every tool surrounding his idea of this free operating system (compilers, filesystem utilities, C standard library implementations, shells) and ended up without a kernel to run it all! The timing was just right when Linus Torvalds came to the rescue with his GPL’ed kernel. Hence, the everlasting symbiosis between GNU and Linux, commonly known as GNU/Linux, was forged.

But Stallman never discarded the idea of developing his own kernel to achieve his dream of creating the ultimate free operating system. The result of many decades of slow development and false starts culminated in the creation of GNU Hurd.

GNU Hurd’s most interesting feature is the architecture of its kernel, which is a microkernel, in direct opposition to Linux’s monolithic paradigm. The crucial difference between these two approaches is the emphasis on stability and performance. Monolithic kernels are faster as all of the key components of the operating system run as part of a single binary which is loaded into the kernel memory space. On the other hand, microkernels like the one GNU Hurd implements, aim to be as lightweight and small as possible. Only the most critical kernel components run in privileged mode: scheduling, memory management, device drivers and little else. Everything else such as the network stack, input handling, the filesystem and every other component you may think of run as individual modules in userspace. Less efficient? Perhaps, but no single component would be able to negatively impact the overall performance of the system, as the rest of the kernel runs isolated from it.

Plan 9

Hailed by some as Unix 2.0 (or perhaps System VI?), the spiritual successor to the venerable OS created at Bell Labs, Plan 9, was developed in the late 1980s by a team of people among which I can recognise the names of Ken Thompson (co-author of Unix) and Rob Pike which, together with Thompson, also invented UTF-8 (which, incidentally, was designed to be implemented in Plan 9) and developed the Go programming language at Google many years later. Industrious minds can’t help themselves, I guess.

So what’s the deal with Plan 9? In plain terms and somewhat paraphrasing the authors themselves, Plan 9 is all about making something more Unix than Unix itself. The endeavour Plan 9 championed was building a Unix out of many systems, not a system out of many Unixes. To accomplish this, Plan 9 introduces many novel techniques such as a universal filesystem for exposing local and remote resources in tandem with the concept of the namespace. Namespaces, as envisioned by Plan 9, are simply local names given by a user to an arbitrary collection of resources.

Plan 9 was, in a sense, a distributed operating system at heart. It was designed to allocate different types of computational tasks to different computers running in a heterogeneous network. CPU-intensive tasks would be carried out by a server, whereas permanent storage would be provided by a separate file server running a trimmed down build of the OS. Finally, a bunch of dumb terminals would be attached to the network so they could make use of these resources. Plan 9 would make this simple and convenient as it mounts every type of file (local or remotely stored), device, network exchange or even graphical window, on a universal filesystem powered by a transaction-driven protocol called 9P. This universal tree would be arranged by an individual user behind a terminal or a process on their behalf to suit their particular needs. This customised view of the global collection of resources is what Plan 9 would call a namespace.

What would this specialist-driven network architecture translate to in a typical day? Imagine a small network comprised of a server, a file server and a terminal you’ll use to do some work, all running Plan 9. With this arrangement, you would switch on your terminal (it will probably boot up very fast as it doesn’t have an awful lot to load anyway) and navigate to the directory where you keep the sources of the programme you want to work on, say, /usr/$user/code/plan9/ (Plan 9 doesn’t use the tilde to alias the user’s home directory). You cd into it and open a file on the text editor, which is launched on the same window you invoked it from. The file is promptly rendered on the screen. You make some changes to it and save them when you’re done. What did just happen there? Well, for starters, that file doesn’t really exist in your terminal; in fact, the entire code directory did not come from any form of local storage. All of it is hosted on the file server. When you requested to switch into this directory, your OS translated this request into a network request to the remote file server, which, unbeknownst to you, just transferred the entire contents of the directory and the opened file over the wire. Then, rio, Plan 9’s windowing system (equivalent to X11 in the Unix world), will create a namespace for this window and expose a file in /dev/bitblt on which clients can send their bitmap graphics commands to so stuff is rendered on your screen (in this case, some text and perhaps some icons to click with your mouse).

Powerful operating system, no doubt. Unfortunately, there is a reason it is on this list: Plan 9 was unable to dislodge any of the popular operating systems at the time, including Unix, the very system it was trying to replace. It never took off. A simple and intelligent design, implemented in a clean and concise manner. Plan 9 was truly a step forward in most respects. Alas, the main reason behind its failure was that Unix, with its many flaws, was still good enough for the job. Switching over required a tremendous amount of effort no-one was willing to spend. Plan 9 was not released under an open source license until its third revision in the year 2000, a fact which really stumped its adoption during the following eight years after its first release.

Nevertheless, the novel ideas introduced by Plan 9 and its cleanly engineered architecture are worth a book of their own so I won’t ramble about it any longer. If you’re burning with curiosity, you can read more about it here.

Also, their mascot Glenda is lovely.

Plan 9’s Glenda (Credit)


Redox is probably the youngest operating system in the list. Three years after its first release back in 2015, Redox has grown with safety and robustness at the forefront of its design. Runtime safety is king. Just like GNU Hurd, Redox uses a microkernel. This decision makes sense as microkernels are architecturally more stable and tolerant to failure than their monolithic counterparts. This pursuit of maximum reliability is the reason why the developers behind Redox chose to write the entire system, kernel included, in the Rust programming language.

While Redox will never replace other long-established operating systems such as Linux, that doesn’t make it any less of a worthy system to study and play with. There are certainly many lessons that can be learned from the principles driving the design and implementation of a modern system like Redox.


Finally, there’s Haiku. Haiku is a direct descendant of the Be operating system, a.k.a. BeOS, which was developed by Be Inc. circa 1995. Haiku itself was forked from BeOS in 2002 and has been under active development since then.

BeOS is the third system in this list sporting a microkernel that handles all the critical hardware-interfacing tasks, leaving everything else, such as printing, input handling, windowing, etc., to a collection of background processes called “servers” in BeOS jargon. On top of these, BeOS would expose an API made out of C++ classes which a programmer can utilise to develop native BeOS applications.

BeOS was discontinued in 2000 due to Be Inc’s failure to remain a viable business. Fortunately, a mere 2 years later, Haiku was released.

Haiku is a complete FOSS re-implementation of the Be operating system. As such, it re-uses almost no code from its spiritual predecessor. Haiku as an operating system is built around a high-level architecture akin to BeOS: a microkernel, a bunch of servers to handle non-critical OS tasks, an API and then the desktop environment or shell to interface with it. The general look and feel is also similar to BeOS but then again, under the hood, Haiku is a completely different beast.


The name Haiku comes from the system’s minimalist and elegant philosophy. Haiku developers strive to deliver a unified, coherent operating system where the desktop is the preferred host. While not as powerful, mature or flexible as other well-established OSs like FreeBSD or Linux, systems like this are not bogged down by backwards-compatibility constraints that slow down development, hamper the adoption of new features. That on itself is a virtue worth considering.

Ring 0: God’s Virtual Temple

TempleOS unveils itself as the ultimate expression of genius and unparalleled technical prowess, a one-of-a-kind fruit borne out of the raw seed of devotion.


This is an excerpt from the TempleOS website itself. I find there can’t be a better description than that coming straight from the horse’s mouth:

TempleOS is a x86_64, multi-cored, non-preemptive multi-tasking, ring-0-only, single-address_mapped (identity-mapped), operating system for recreational programming. Paging is almost not used.

TempleOS operates in ring-0 all the time, which means every CPU instruction is executed in privileged mode or kernel space. Thus, every application has complete access to the underlying hardware: the kernel, the text editor, the calculator…

Simplicity is a goal to keep the line count down, so it’s easy to tinker with. […] It’s only 81,303 lines of code including the kernel, the 64-bit compiler, the graphics library and all the tools. More importantly, it’s designed to keep the user’s line count down – you can do a Hello World application in one line of code and can put graphics on the scrn with a three line program!

TempleOS could be considered a quick-and-dirty operating system. It lacks support for virtual memory, operates on full privilege mode all the time, does not perform any sort of clever process scheduling, lacks network capabilities, adequate hardware detection, yet none of this matters, as all was made according to plan. Amongst the several limitations imposed in God’s revelations to Mr Davis regarding the architecture of the system, sheer performance and minimal footprint were paramount from the start.

It’s a kayak, not a Titanic – it will crash if you do something wrong. You quickly reboot, however. DOS and the 8-bit home computers of the 80’s worked fine without memory protection and most computers in the world – the embedded ones – operate without protection. The resulting simplicity of no protections is why TempleOS has value. In facts, that’s the point of TempleOS.

TempleOS boots fast, and I mean, really fast. It takes it a literal second, if not less, to fully load up and present you a totally responsive welcome screen. Plus, its memory footprint is not exactly massive either (512MB). No context switches occur between userspace and the kernel; there is no paging or swapping to/from disk, which means the entire OS runs off RAM; process scheduling is minimal: nothing can get any faster than this.

This bizarre operating system is the culmination of more than 20 years of development spent by its one and only father, Mr Terry Davis. Let me repeat that: TempleOS is a complete, fully functional operating system, designed and written completely from scratch by a single man. No person has ever worked on this project other than Terry Davis himself. A typical TempleOS installation includes dev toolkits such as compilers, assemblers, a shell, shell utilities like a grep clone, even 3D games!

TempleOS 3D Game

Why would a person embark on such a gargantuan journey, you ask, aghast? Out of pride, pure enjoyment, or to gain arcane knowledge perhaps? Nay, Mr Terry Davis is not driven by personal interest. He crafted this technical marvel to fulfill a divine endeavour bestowed upon him by no other than God Himself.

TempleOS is God’s official temple. Just like Solomon’s temple, this is a community focal point where offerings are made and God’s oracle is consulted.

If you’d like to know more about the principles behind TempleOS, your best option is to view the [archived version of the website](TempleOS as Terry remade the whole website recently, eliminating most information directly addressing the design philosophy and make-up of his operating system, which is an absolute shame, if you ask me.

TempleOS has been released by Mr Davis as a public domain work so anyone can download it, use it, study the code, share it, and do whatever they want with it. You can get hold of it directly from the website on this URL. It’s distributed as an ISO image so you’ll need to extract it from the file. Alternatively, you can browse the source code at one of the several mirror pages on GitHub that make the source available like [](this one).

* Lava crocodiles might not be a real species but hey, you never know.

Back to top ↑

Articles from friends and people I find interesting

In praise of qemu

qemu is another in a long line of great software started by Fabrice Bellard. It provides virtual machines for a wide variety of software architectures. Combined with KVM, it forms the foundation of nearly all cloud services, and it runs SourceHut in our self…

via Drew DeVault's blog September 2, 2022

The quick and practical "MSI" hash table

I generally prefer C, so I’m accustomed to building whatever I need on the fly, such as heaps, linked lists, and especially hash tables. Few programs use more than a small subset of a data structure’s features, making their implementation smaller, simp…

via null program August 8, 2022

Migrating Go and Node.js Fargate tasks and Lambda functions to Graviton ARM processors with CDK

Migrating Go and Node.js Fargate tasks and Lambda functions to Graviton ARM processors with CDK I’ve been using AWS’s Graviton ARM processors for personal projects for a while. They’re cheaper, use lower power chips, and might be better for the environment…

via July 27, 2022

Generated by openring