It was the summer of 2001, and computer programmer Michael Phipps had a problem: His favorite operating system, BeOS, was about to go extinct. Having an emotional attachment to a piece of software may strike you as odd, but to Phipps and many others (including me), BeOS deserved it. It ran amazingly fast on the hardware of its day; it had a clean, intuitive user interface; and it offered a rich, fun, and modern programming environment. In short, we found it vastly superior to every other computer operating system available. But the company that had created BeOS couldn’t cut it in the marketplace, and its assets, including BeOS, were being sold to a competitor.
Worried that under a new owner BeOS would die a slow, unsupported death, Phipps did the only logical thing he could think of: He decided to re-create BeOS completely from scratch, but as open-source code. An open-source system, he reasoned, isn’t owned by any one company or person, and so it can’t disappear just because a business goes belly-up or key developers leave.
Now if you’ve ever done any programming, you’ll know that creating an operating system is a huge job. And expecting people to do that without paying them is a little nuts. But for the dozens of volunteer developers who have worked on Haiku, it has been a labor of love. In the 11 years since the project began, we’ve released three alpha versions of the software, and this month we expect to release the fourth and final alpha. After that we’ll move to the beta stage, which we hope to get out by the end of the year, followed by the first official release, known as R1, in early 2013.
Even now, anybody can install and run the operating system on an Intel x86-based computer. Many of those who have done so comment that even the alpha releases of Haiku feel as stable as the final release of some other software. Indeed, of all the many alternative operating systems now in the works, Haiku is probably the best positioned to challenge the mainstream operating systems like Microsoft Windows and Mac OS. For both users and developers, the experience of running Haiku is incredibly consistent, and like BeOS, it is fast, responsive, and efficient. What’s more, Haiku, unlike its more established competitors, is exceedingly good at tackling one of the toughest challenges of modern computing: multicore microprocessors. Let’s take a look at why that is, how Haiku came to be, and whether the operating system running on your computer really performs as well as it should.
First, a little history. In 1991, a Frenchman named Jean-Louis Gassée and several other former Apple employees founded Be Inc. because they wanted to create a new kind of computer. In particular, they sought to escape the backward-compatibility trap they’d witnessed at Apple, where every new version of hardware and software had to take into account years of legacy systems, warts and all. The company’s first product was a desktop computer called the BeBox. Finding no other operating system that met their needs, the Be engineers wrote their own.
Released in October 1995, the BeBox didn’t last long. BeOS, on the other hand, quickly found a small yet loyal following, and it was soon running on Intel x86-based PCs and Macintosh PowerPC clones. At one point Apple even considered BeOS as a replacement for its own operating system. The company eventually released a stripped-down version of BeOS for Internet appliances, but it wasn’t enough. In 2001, Palm acquired Be for a reported US $11 million.
Even as the sale of Be was being finalized, Phipps launched the Haiku project, which back then was known as OpenBeOS. (The name changed a few years later; see box, “What’s in a Name?”)
From the start, Phipps decided that the project’s singular focus would be to replicate the last official release of BeOS, known as R5. In hindsight, this was a stroke of genius. Open-source efforts, generally done for fun in people’s free time, can sometimes fizzle out or get sidetracked without ever releasing anything tangible. Haiku has avoided this fate because the developers all believed in the goal of replicating R5.
Still, Phipps and those who joined him had their work cut out for them. An operating system is extremely complex, especially one as comprehensive as BeOS, whose various layers and applications had all been designed from the ground up to work together. Some of the most gifted engineers in Silicon Valley had developed the software over the course of more than 10 years. Re-creating such a system with an all-volunteer crew working in their free time was a crazy idea. But then, that’s how Linux came to be, as well as the Free Software Foundation’s GNU software, from the Gnu C Compiler to GnuCash, an accounting program.
Much like the layers of a cake, a computer system consists of the hardware, an operating system that manages the hardware, and the applications that run within the operating system, such as Web browsers, document editors, and fun things like games. The operating system is also the means by which programmers give instructions to the hardware.
Fortunately, BeOS had been written in a modular fashion, making it relatively straightforward to develop, test, and then replace each component of BeOS with its open-source equivalent. A few pieces of BeOS had already been released by Be as open source, such as the Tracker and Deskbar, which are equivalent to Windows’ Explorer and Taskbar and to OS X’s Finder and Dock. One of the first chunks of code that the volunteers tackled was the screen-saver kit, which has a very simple function but also a lot of moving parts. Among other things, it has to constantly monitor activity on the keyboard and mouse, load the screen-saver settings at the right times, and ask for a password when the screen saver is turned off. Once all the parts had been nailed down, Phipps replaced the BeOS screen saver with the open-source version, and much to everyone’s surprise and delight, it worked. More important, it was a proof of concept that showed the developers they could replace each module in BeOS and know it would be fully compatible.
In 2008 we reached a milestone. Haiku, like any piece of software, is written in source code; to convert the source code into binary instructions that the computer can process, you need to compile it. The breakthrough was that we were finally able to compile the Haiku source code from within Haiku itself; programmers refer to that feat as “self-hosting.” This step is critical in the development of any operating system, because without it, the OS will always be dependent on other systems.
Even as the development was getting under way, Phipps was working to create an organizational home for Haiku, eventually establishing Haiku Inc. as a nonprofit organization in 2003. In addition to overseeing the project and taking in donations, Haiku Inc. holds the copyrights to and the trademarks of the Haiku website, logo, and of course, the source code. All Haiku source code is now licensed under what’s called the MIT License, which allows full and free use of the code by pretty much everyone, including private companies and other open-source projects.
Of course, the Haiku team also has to be mindful of not infringing on BeOS’s patents, which are still in force. In general, we maintain a friendly relationship with the Japanese software company Access, which now owns the rights to BeOS; for example, the company allows us to post BeOS documentation on our website, and it has never challenged any of our efforts to replicate BeOS technology. Would Access or some other corporation that thinks it has a right to our code choose to sue a small open-source project like ours? Financially, it wouldn’t make much sense, and it would also generate a lot of bad publicity. But we’ll just have to wait and see. Given the current frenzied state of intellectual property litigation in the United States and elsewhere, no software project can be considered completely immune from legal troubles.
In 2007, Phipps announced he was leaving the project for personal reasons, and a new group of people took over Haiku Inc. Much as Phipps had anticipated at the outset, the loss of one leader hasn’t doomed the project. I’m currently the treasurer and, along with the other executives of Haiku Inc., sit on its board of directors. We’ve kept the momentum going, and at their latest gathering in Düsseldorf, Germany, in early April, Haiku developers worked on the imminent alpha release.
At this point, we’ve replicated BeOS R5 so precisely that legacy BeOS applications, now more than 10 years old, can run on Haiku. When the project first started, many thought this sort of compatibility would be impossible. And in many key areas, Haiku has surpassed its predecessor. For example, Haiku supports more languages than BeOS did and is more amenable to internationalization in other ways as well. It can also handle modern video cards, newer processors, and wireless network access, and it supports more memory than BeOS could.
And in terms of programming, Haiku makes it much easier to design user interfaces for applications, because it has a built‑in layout tool that lets you automatically place icons and other widgets on the screen. With BeOS, developers had to specify each minute detail of the layout, aligning buttons with check boxes by hand, for instance. These and other enhancements have allowed Haiku to remain relevant, despite the lightning-fast pace of innovation in computer hardware and software.
Even so, you may be wondering: With Windows, Mac OS X, hundreds of versions of Linux, and numerous mobile operating systems, does the world really need Haiku?
Yes, it does, for many reasons. Much as in nature, computer viruses flourish in a monoculture, and because so many of us use Windows computers, Windows viruses find plenty of victims. Further, if one operating system has a monopoly, its creators have little reason to improve their software. (Competition from the Mozilla Firefox browser is, after all, largely what prompted Microsoft to update Internet Explorer.) And diversity promotes interoperability because it compels software developers to create code that plays well with others. When there’s very little competition, there’s no incentive to do so.
But Haiku does more than just expand the gene pool of operating systems. One of the first things people notice about it is that it doesn’t feel anything like Windows or OS X or Linux. It’s unique. Linux, for instance, is based around a core—called a kernel—that was originally designed for use in servers and only later modified for desktop systems. As a consequence, the kernel sometimes gives short shrift to the user interface, which Linux users experience as annoying delays when their computers are doing especially taxing things, like burning a DVD or compiling code. Haiku’s kernel has always been for a desktop system, and so it always gives priority to whatever is happening by way of its graphical user interface.
In between the kernel and the graphical user interface is what’s known as the application programming interface, or API. An API is what application developers use to access other software systems, and the design of that API can affect both the developers and the eventual users of their software. Haiku has just one API. Linux, by contrast, has hundreds of APIs and about as many user interfaces, so you can’t just switch seamlessly from one version of Linux to another. The version you use can greatly alter the appearance of your computer screen, the way programs boot and execute, and various other things, all of which make it quite difficult to develop software that consistently runs well on all Linux systems.
All of Haiku’s components are designed to work together from the ground up; that includes its applications, like the media player and the Web browser. Its source code even uses a consistent style, something developers really appreciate because it allows them to quickly get up to speed. A developer writing code for Haiku can be confident it will run and act the same way on all Haiku installations. Even though Haiku is open source, there will always be only one official version. All this combines to provide a remarkably consistent user experience.
What really sets Haiku apart, though, is its efficiency and speed. On my three-year-old desktop computer, Haiku boots up from a cold start in 10 to 15 seconds, and when running it uses only about 170 megabytes of RAM. Compared with other operating systems, it’s great at maximizing available computing resources. Haiku feels fast and responsive even when running on older systems that would otherwise be considered obsolete because they can no longer handle the inefficiency and bloat of other operating systems.
Much of Haiku’s efficiency and speed is a direct result of its BeOS legacy. BeOS was designed from the start to make full use of threads, which in computing terms represent sequences of executing code. Much as fabric consists of many threads woven together, an operating system is made of threads that all have to share time on the processor. Generally, there is one thread for each application and one for the operating system’s user interface as well. The problem is that the user interface in particular needs more than one thread. Those “application is not responding” messages in Windows and the “beach ball of death” in OS X—which most of us experience with some regularity and frustration—are a direct result of using just one thread for the user interface. When that thread gets too backed up with work or has another problem (like a slow network), the whole application interface locks up.
That didn’t happen on BeOS, and it doesn’t happen on Haiku. Where BeOS drove ahead of other operating systems of its time (and where Haiku is still ahead of contemporary operating systems) is that each individual application uses many threads. The core of the application itself has one thread, and each window the application creates has a thread. While this can make the code a little more complicated to write, the result is that applications almost never lag or lock up.
This highly threaded system means that Haiku can make great use of multiple processors or CPU cores, which are now ubiquitous. The Haiku kernel allows each thread to run on its own core or processor—even threads within the same application. Adding more threads for other tasks, such as retrieving data from a network, is also straightforward. Other operating systems make use of multiple cores only when running many applications at the same time or when a particular application has special multithreading code added to it. But this multithreaded code is difficult to write, and so most applications don’t have it.
Haiku simplifies the process of writing multithreaded code by hiding most of the thread interaction so that the developer doesn’t need to worry about it. A big part of what makes this work is the extensive use of message passing. Let’s say Thread A and Thread B in an application both want to retrieve a piece of data from Thread C. Instead of directly accessing that data, Threads A and B each pass a message, which is placed in a central message queue and dealt with in a specified order. Without that mechanism, the two threads would attempt to access Thread C simultaneously, creating a deadlock, in which they both just wait endlessly. With Haiku, messages can be passed within an application and also to other applications. Haiku’s message-passing code thus manages all the complexities of threading so that the developer doesn’t have to.
The main reason that BeOS used multiple threads was because the BeBox was conceived of as a media platform. One of BeOS’s marketing monikers, in fact, was “the media OS.” While that might have been a bit of hype, the system was very good at handling multimedia. In a typical product demo, a BeBox would play half a dozen different videos at the same time, with no lag or frame dropping, while the system still remained responsive. The efficiency of the system also allowed for low latency in audio processing. While Haiku still needs work in these areas, it is well ahead of many other systems.
Another advantage that Haiku has over other operating systems is that it makes extensive use of a database-like file system, which allows any file to have various attributes associated with it. These attributes can then be indexed and queried just as in a contemporary database. For example, each e-mail message in Haiku is stored along with attributes such as the subject, the sender’s name and address, and the recipient’s name and address. From the operating system’s file manager, known as Tracker, you can search on any of these attributes. Attributes also let you extract the song information from MP3 files and then easily organize and search your music library through Tracker. Entries in Haiku’s address book, known as People files, consist almost entirely of attributes.
Having your operating system organize your e-mail and address book offers a huge advantage: You’re no longer tethered to just one program to manage your e-mail or your contacts. Anyone who has ever tried extracting old e-mails from a bloated Microsoft Outlook mail file will understand the beauty of this approach. Instead of having your e-mail locked into a proprietary format that’s accessible from only one program, Haiku lets you use whatever program you want—you can even use multiple programs on the same set of e-mails. Similarly, Haiku’s People files can be edited and managed by various programs and can even be edited from within Tracker. No other operating system has so successfully implemented a database-like file system.
For all its capabilities, Haiku does lack some key things that users have come to expect. For example, most operating systems today have interfaces that are hardware accelerated. That allows fancy graphics like window shadows, transparent window borders, and thumbnails of window contents to be handled in a fast, efficient way using video cards. Users of mainstream operating systems also have a huge array of applications to choose from. Haiku at the moment is limited to the few applications created specifically for it or left over from BeOS.