Haiku

Around the turn of the millenium, the proprietary BeOS included many features that made it stand out from other operating systems. Despite a determined effort, it never gained a commercial foothold. However, it did capture some enthusiastic fans. After production ceased in 2002, a half dozen attempts to continue or clone BeOS sprang up, of which only Haiku exists today (Figure 1).

Figure 1: The default Haiku desktop: Note the two apps shown as tabs in the same window and listed in the Tracker on the upper right.

Although officially in its third beta, in 2022, Haiku is a stable operating system with a somewhat archaic look to its icons and widgets. However, with a little help from Plasma applications and standard software like LibreOffice, it is generally usable for modern computing purposes. Its speed is compelling, and even some minor features, like the ability to tab multiple applications in a single window or the use of a drop-down list to display open windows, make clear that Haiku is more than an exercise in nostalgia. To learn more about Haiku's modern relevance, I contacted one of the few people sometimes paid to develop Haiku, a developer and project mentor who prefers to go by the handle waddlesplash (or sometimes Mr. waddlesplash). As you might expect, some of his opinions might be surprising for many Linux users.

Linux Magazine (LM): What was the original appeal of BeOS?

waddlesplash (w): In the 1990s, BeOS was particularly advanced for its time. Not only did it natively utilize multiprocessor computing years before it became ubiquitous on the desktop, but its native APIs and toolkits were C++, and they were natively multithreaded for highly responsive user interfaces. They also had very advanced multimedia for the time. Moreover, the robustness of BeOS was almost legendary.

LM: I understand that for a long time Haiku maintained backwards compatibility with BeOS. Did backwards compatibility help or hamper development?

w: A bit of both. Having backwards compatibility with BeOS made it so that initially we had a fixed target to aim for and a baseline to compare things to. Nowadays it is a bit more of a hindrance, but we have dropped it in a lot of areas where it mattered less. For example, the kernel no longer supports loading BeOS kernel drivers, and we compile a lot of applications with the newer, non-BeOS-ABI-compatible GCC even on the "BeOS-compatible" builds.

LM: Do any of the original advantages of BeOS remain?

w: By and large, the rest of the world has caught up with the major innovations BeOS had. Haiku still has some innovations of our own, though. The biggest reason that Haiku is still something a lot of us believe in and still work on is because it is the only serious contender for a cohesive open source operating system for personal computing.

LM: What do you mean by a cohesive operating system?

w: The general argument we make on Haiku is that such problems Linux has are inherent to the ecosystem the Linux desktop has chosen for itself. There is not one "Linux desktop" project (or even a few competing ones); there's X11 (or now Wayland) for the display server, various differing options for a window manager, [and] Gnome or KDE or Xfce or whatever else for the desktop environment (and these are themselves huge projects with often competing interests internally). That's before we even get to ALSA, PulseAudio, systemd, or the multiple dozen other components you have to mix together in order to come up with something that actually can boot and display a web browser.

[As an example of the complications Linux's setup can cause,] take the bug reporting process on Linux. You have to begin by first establishing what project has responsibility for the application in question with the bug (is it Gnome? is it one of Gnome's sub-projects? is it really in PulseAudio, and Gnome just is displaying the error message?) which requires you to basically be an expert in the first place. Then once you have reported it, you may find out that the bug has already been fixed in a newer version your distribution does not have or is due to an incompatibility created by your distribution's packagers, or may well be a legitimate bug but is unreplicable outside of your distribution, so the developers do not care to bother with it. [By contrast,] Haiku is a fully cohesive ecosystem. There are of course still some issues with sorting out when a problem in an application is due to a bug in Haiku, a bug in our port of the application, or the application itself, but these are much easier to resolve when the boundaries between projects are much clearer. Bugs or feature requests for the base system itself are even easier: Whether it's really a bug in the UI toolkit, the graphics server, or the kernel, it's our responsibility, and we just need to agree amongst ourselves where [is] the best place to solve it. This means there's a lot less wasted effort and a lot more efficient development. If someone spots a minor problem in the file manager, a developer can post a patch for it, have installable test builds available within hours, and once it's merged, it will be in the binary update repositories for the "nightly" channel the next day. And everyone who updates their OS will get it. Whereas on Linux, if you report some issue with a default application and it gets fixed, it could take a year to trickle down into your local distribution, and you would otherwise have to resort to compiling it yourself or using an AppImage.

LM: Haiku's latest release is officially the third beta. Will Haiku ever have a general release?

w: "Beta" means we have replicated all functionality of BeOS R5 as well as implemented all of the features we had on our to-do list for R1. R1 will be ready "when it's ready." At this point, Haiku's desktop environment is probably on average more stable than, say, KDE 4.0 was at the time of its initial release, and kernel stability and hardware is not too shabby either.

LM: What sort of user is Haiku likely to appeal to? What features would you point out to new users?

w: [For] anyone who already runs desktop Linux or BSD and enjoys experimenting with beta-quality software, and Haiku sounds intriguing to you, I would encourage you to try it out – especially if you have some slightly older hardware that Linux seems a bit sluggish on these days. Haiku is still pretty resource-light and can often make the most out of slightly older hardware. (Newer hardware is fine, too, though: I run Haiku on bare-metal on a 16-thread Ryzen box!)

One of the more technically interesting features that I would mention is our package manager. Unlike Linux packages, which are just archives extracted at installation time, Haiku packages are block-compressed filesystem images. On boot, the bootloader loads the kernel from the main system package, and it then mounts all your installed packages during the boot sequence. Installing packages just means they get copied into the system packages directory and then mounted, or on de-installation [the package] is copied into an "old state" folder. So if you take a bad update or install a package which winds up breaking your system, you can ask the bootloader to start you into one of those older states. Or you can boot into a different installation and replace the set of installed packages altogether. Besides making package installation much faster, as well as making certain failure conditions impossible (no more "installed files database" to lose or corrupt like on Linux), or at least easier to resolve, this deep integration with the system is pretty typical of Haiku.

LM: What sort of kernel does Haiku use?

w: The Haiku kernel is a modular monolithic kernel. The kernel itself handles the basics of system calls, I/O, and memory management, and basically everything else (including the PCI bus, the filesystem drivers, the network stack, the USB stack, etc.) [is] all dynamically loaded modules.

We have been shifting some things into userland, though. Newer USB device drivers have been pushed to userland, and the upcoming work on 3D acceleration puts almost all of the GPU management logic in userland, with only a small amount of code in the kernel-side driver. There also used to be a way to run the network stack in userland, too, but that has bitrotted by now. I would say that most of the developers' sensibilities lean more towards the microkernel side of things than not, these days, but it would be a lot of work for not much benefit to do that refactor at this point. Maybe someday …

LM: Are any non-free components used in Haiku?

w: We used to ship a number of closed-source BeOS applications in the default install (for which we had permission from the original developers to do so), but these have all been open sourced, with maybe one minor library as an exception, at this point. I think the only other non-free components are the WiFi firmware blobs, but you can remove them if you have a WiFi chip that does not need them (or you don't need WiFi.)

Haiku itself is mostly under the MIT license, though, and overall we are not at all averse to commercial usage. There are (or were) at least one or two companies that used to run BeOS that were deploying Haiku commercially.

LM: How is Haiku organized and governed?

w: The project has voting team members, generally those with commit rights, who determine the direction of the project. If there are disagreements, theoretically we would put it to a vote. But in practice we are always able to come to some kind of consensus and proceed without an official vote. I can't recall any formal votes besides ones to grant commit rights while I have been a voting member these past six years.

There is also Haiku, Inc., a 501(c)3 non-profit which manages everything related to finances, but the board of the Inc. does not direct the project (though most of the board are voting members of the project).

I would say we have about a dozen or two regular contributors of code and ports at present, and a few hundred regulars on the forums and IRC who use the system on some kind of regular basis. Honestly, the fact that Haiku is able to at the very least not lose ground compared to desktop Linux's feature set and has been slowly gaining it the past few years is a testament to how much we have done with very little. Before a few months ago when I was brought on as a contractor to work on Haiku full time, I would say we had maybe one to two person-months of work done per month across the whole ecosystem, at best; it was probably less. If we had even a tiny fraction of the amount of money and time poured into the desktop Linux ecosystem each year, I would have to imagine we would catch up completely and then go beyond it very rapidly.

LM: Where is Haiku headed in the future?

w: Who knows what the future holds? Whatever is needed for personal computing, or at least whatever we and our users need, we'll try to support, as we have development time for. I realize that's a vague answer, but that's because our plans are still vague. Haiku has survived for over two decades now plodding along and doing whatever is next, and I imagine we will continue doing so for as long as we can.

LM: Would you like to say anything else?

w: I started volunteering for Haiku in early high school, and I learned a massive amount in working on it all these years from the other developers and contributors – not just in technical terms, but also in community organization, how to mentor new developers, and too many other things to count. I'm very grateful for all that I've learned, and the patience with which it was taught, and now I get paid to pay it forward by working on Haiku and mentoring the current newcomers! Overall, it is just a great project to be a part of.