A Roundup of Free Operating Systems
Date: Jun 22, 2007
Article is provided courtesy of Prentice Hall Professional.
Whenever people thinks of a free operating system (if they do), the odds are that they will think of Linux, a clone of UNIX from 1991. They also might think of one or more of the BSDs, UNIX-derivatives dating back to the early ’80s. Let’s face it, though—UNIX is pretty boring. It was great for a PDP-11, and it gets the job done now, but it’s not exactly exciting.
Fortunately, the Free Software community has some much more interesting projects which, even if they might not be as useful, are much more fun.
I Want to Be a... Haiku?
I have something of a soft spot for BeOS. It was the first mainstream operating system built around the idea of concurrency and low latency. The BeOS kernel was designed from the ground up to run large numbers of threads, and the entire API was designed around this. Because interface elements had their own threads, they didn’t stop responding when the application was busy. This meant that BeOS always felt quick and responsive, even on slow systems. The heavily threaded nature of the system also meant that applications tended to get a significant boost from multiple CPUs.
For a while, it looked like BeOS might be bought by Apple to replace the aging MacOS; however, the high price demanded by Be Inc. prevented this. The company decided to focus on the embedded market with BeIA aimed at Internet appliances. This killed the BeOS applications market, and turned out not to be the brightest decision to make just before the dot-com crash.
A project called OpenBeOS began in 2001 to try to re-create the Be experience. Due to trademark concerns, the project was renamed Haiku in 2004.
Haiku has come a long way in the last six years. The aim for the 1.0 release is full source and binary compatibility with BeOS Release 5 (the last public release). A lot of applications run already, and the team has implemented my favorite feature from BeOS: the BFS. There are only two filesystems I consider to have a truly elegant design—BFS and ZFS. While BFS lacks a few features you would expect from a new design, such as snapshots, it is still a very good choice for a desktop.
The basic design of BFS is close to UFS, with the addition of journalling and the use of B+ trees to store directory contents. BFS inodes were at least one disk block, because this is the smallest amount you can efficiently read from a disk. This left about 200 bytes free per inode. Rather than waste this space, BFS used this for "small data," or typed key-value pairs containing arbitrary information.
While storing arbitrary metadata was nice, as was the fact that you could get at it all just by reading the inode (making folder listings with metadata very fast), BFS had one extra trick. It was possible to create folders containing indexes of metadata, which would be automatically updated.
One of the ways in which BeOS gained some speed was to put the file icon into the metadata. This meant that a single disk read would get all of the information required to display a file in the Tracker (the BeOS file manager). Haiku does this, too, but uses a highly compressed vector graphics format, giving a much higher visual quality.
Haiku is more or less ready for their 1.0 release in terms of features, although not in terms of bugs (a lot still remain). Hopefully this will improve in the next few months, making Haiku a potentially interesting operating system for future desktops.
ReactOS
A little more than a decade ago, I came across a little project called FreeWin95, aiming to create a clone of Windows 95 in much the same way that Linux cloned UNIX. It seemed somewhat interesting, but in order to have a chance at being useful, it needed a working release and at the time it didn’t even have any code.
In 1998, the project was relaunched with the name ReactOS. This time, it aimed to produce a clone of Windows NT. Because Microsoft’s roadmap showed that it would be sticking with the NT kernel for a while (and Microsoft is still using it in Vista), this seemed more promising. As a user of Windows NT 4.0, I decided to keep an eye on it.
Over the years, ReactOS has periodically impinged on my consciousness. I haven’t used Windows seriously for a few years, but I am still rather fond of the NT kernel design. It made some very interesting design decisions, such as the ability to plug in different personalities and support different userspace kernel APIs easily. Unfortunately, it was buried under so much legacy-compatibility cruft that it never really had a chance to show off its strengths.
Over the years, the focus of ReactOS kept slowly shifting. Originally aiming to be a functional clone of Windows NT 4.0, it now incorporates some features from Windows 2000 (NT 5.0), XP (NT 5.1), and 2003 (NT 5.2).
Because ReactOS always aimed to be binary-compatible with Windows, a lot of device drivers can be used directly without modification. While they can’t use any of the Microsoft-supplied drivers for generic hardware, one of the strengths of Windows is that there is a plethora of third-party driver support. Things like nVidia’s display drivers can be used to provide 3D acceleration to applications, as shown off by running Unreal Tournament on ReactOS. It should be noted, however, that this can only be managed with a little patching of the nVidia driver binaries.
Not all drivers will work correctly. While most of the interfaces are identical, some parts are very different. The cache controller and memory manager are completely unlike their Windows NT counterparts, preventing some drivers from working.
Another group has overlapping, if somewhat different, goals to ReactOS. The WINE project aims to provide replacements for most of the userland libraries found on a Windows system. A significant amount of code sharing goes in between the two projects. Some components from WINE can be re-used directly in ReactOS. Some can be used with a few minor changes, and some are superfluous. GUI applications, for example, are run on the native display, and so GDI calls don’t need to be turned into X11 calls.
This code sharing is not all one-way. Code from ReactOS has found its way into various driver wrappers for Linux, such as NDISWrapper for WiFi drivers and Captive for NTFS support. The GNU toolchain for Windows has similarly benefited from contributions by ReactOS developers, as has QEMU. WINE, of course, also accepts some patches.
In spite of ten years of development, ReactOS is still considered "alpha" quality. It works reasonably well in emulated or virtualized environments, but hasn’t been tested on much real hardware. In spite of this, it is capable of running a variety of Windows software, including large applications like OpenOffice quite well. In a few years when support for Windows XP runs out and businesses are looking to migrate, ReactOS might be a good solution.
AROS
I have a confession to make. I never owned an Amiga. Back when Amiga owners had a multi-tasking GUI running on top of a microkernel, I was using Windows 3.0 on MS-DOS. And I’m still bitter.
For those of us who missed out the first time, the AROS Research Operating System (AROS) provides some surrogate nostalgia. For its era, the AROS OS was an impressive piece of work. It ran on very slow hardware (by today's standards), but still managed to provide an impressive user experience. Of course, this came at a cost.
Perhaps the biggest price paid by the AROS OS was the lack of protected memory. This is seen as vital these days; the idea that one rogue application could trample over another’s memory seems remarkably quaint. Swapping, something that usually goes hand-in-hand with virtual memory, is similarly absent.
Syllable
All of the operating systems listed so far are clones of old proprietary systems. The next one is not. Syllable began life as AtheOS, a graphical OS that itself started life as an AROS clone. AtheOS was the work of a single developer as a hobby project. Because one of the goals of the project was to teach the author about OS design, and to create his own vision of what an OS should be, he was reluctant to accept patches from the community.
In 2002, two years after development of AtheOS had effectively ended, it was forked to produce Syllable. As AtheOS grew, it became more similar to BeOS than the AROS, although retained its own unique flavor.
One of the biggest benefits AtheOS had over BeOS was the fact that Kurt Skauen (the original author of AtheOS) ported KHTML over and created ABrowse. When BeOS was still stuck with the antique NetPositive browser (one that predated even frames), AtheOS had a relatively modern one. Modern BeOS clones tend to use Firefox, but this has the disadvantage that it doesn’t feel particularly integrated with the rest of the desktop.
Syllable’s big advantage over many other operating systems is that it has no legacy to support. No concessions must be made to support legacy Mac, Windows, BeOS, or AROS applications. This is a two-edged sword, because it means that there is no existing software library for Syllable. This is not as bad as it might seem; beneath the GUI, Syllable supports a large subset of POSIX, and so much non-GUI Free Software can be easily ported. GUI applications with a clean abstraction layer are relatively easy to port, although they require a lot more than a straight recompile.
Under the hood, Syllable is a modern design. The filesystem is heavily inspired by that of BeOS, the kernel supports all of the expected features (SMP, protected memory, multithreading, and more), and the GUI is built along object oriented lines in C++.
MenuetOS
The first question anyone who begins building an OS will be asked is, "Why bother?" It’s a reasonable question, because there are already a lot of operating systems around, and they all have one major advantage over a new one—lots of existing applications. For some the answer is fun; for others, it’s a learning experience. For many, the answer is "because no one’s done it quite like this before."
In the case of MenuetOS, it’s not so much that no one has ever done it like this, just that no one has for a few decades. MenuetOS is a full-featured OS written entirely in x86 assembly language (specifically, the FASM dialect).
The reasoning behind this is two-fold. First, it is an attempt to prove that it is still possible to write complex programs entirely in modern assembly languages. The second is to create a small (and thus hopefully relative bug-free) and yet full-featured system.
Booting MenuetOS is an incredible experience. The entire system fits on one single 1.44MB floppy disk (compare this to MS DOS 6.22, which required 3MB and then another 10MB for Windows). Most of the boot time is taken answering a few questions about the system, such as the amount of available memory and the display resolution to use. Within seconds, you are in a graphical environment and able to run programs.
The standard distribution comes with a few example apps, such as a text editor and calculator. It’s enough to start developing, because it includes FASM, but not enough to really use. Application support gained a boost relatively recently with the addition of a C library, allowing both C and FASM applications to run. Ports of both Doom and Quake exist, showing that isn’t just trivial for applications, and sound works with an AC97-compatible sound card.
Would I use MenuetOS on a real system? Almost certainly not. If I were planning on creating an x86-based embedded system, however, it might be an interesting starting point. The minimum requirement of 32MB of RAM isn’t a lot by today’s standards, and it would run quite nicely on something like AMD’s Geode line of processors.
Contiki
Last but not least (except in terms of size) is Contiki. While MenuetOS feels like it was written to show that it could be done, I still find it hard to believe that Contiki is possible, even after seeing it. If you thought 32MB of RAM and 1.44MB of disk space was a fairly low set of system requirements for a multitasking graphical operating system, then you are unlikely to believe the system requirements for Contiki—2KB of RAM and 40KB of ROM.
Originally built for embedded systems, particularly sensor networks, the operating system has been ported to a large number of systems including the Commodore 64. Even on the C64, it supports a full TCP/IP stack and can run a web browser and server. If you don’t have graphical capabilities locally, there’s even a VNC server included for remote access.
The kernel is event-driven, and permits individual applications to support pre-emptive multithreading. The core system is built around the idea of protothreads, similar in concept to coroutines. Unlike true threads, a protothread does not have a local stack. While a protothread is running, it may use the stack, but as soon as it enters a blocking state it will lose the contents of the stack frame. Local variables do not persist between blocking operations in protothreads.
Because local variables are not preserved, most coroutines have to rely on statically allocated global variables. In practice, this is not a huge problem for Contiki; target systems are sufficiently memory-constrained that it is quite rare for them to be able to implement luxuries such as a heap and dynamic memory allocation. The TCP/IP stack, uIP, has a number of limitations defined at compile time, such as the number of fragmented IP packets that can be cached for reassembly and the number of TCP connections permitted. This allows the maximum memory usage to be determined at compile time, which eliminates a lot of potential out-of-memory conditions from the system. Of course, this comes at a cost. Rather than run out of memory, you can now run out of connections (for example). In general, however, it is possible to ensure that these limits are larger than an embedded system will encounter.
Conclusion
From Haiku to Contiki, it should be clear that there are a wide range of Free Software operating systems around, some aimed for general-purpose use, some for education, and some for highly specialized uses. If you’re bored with UNIX or interested in learning more about operating system design, try taking one for a spin. Most run well inside emulators such as QEMU, so you don’t even need to reboot.