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…
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.
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 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.
If anyone knows what the two games other than Minesweeper are about on the picture above, drop me a line.
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.
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.
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.
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.
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!
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 https://github.com/minexew/TempleOS.
* Lava crocodiles might not be a real species but hey, you never know.