BeOS debuted in October 1995, running on the PowerPC architecture that was at the time the basis for Apple Macs (although initially BeOS was designed for systems using AT&T's Hobbit CPUs). Be Inc was formed by Apple alumni Jean-Louis Gassée, who exited the Cupertino, California, based company in 1990.
But although BeOS made a splash, Be Inc's final version of the operating system, BeOS R5, was released in 2000. The company's end came in 2001.
When it was released, BeOS was without the legacy code and designs that many of its contemporaries were stuck with in the interests of backwards compatibility. It was a modern operating system, with an impressive user interface, pre-emptive multitasking, symmetric multiprocessing and a 64-bit journaling file system. Be Inc's BeBox workstation, which debuted in 1995, included dual PowerPC CPUs and extensive multimedia support, as well as .
But the death of Be Inc didn't mean the death of BeOS; at least, not quite. The operating system's legacy lives on thanks to : An open source project re-implementing and extending BeOS, adding new features such as internationalisation and Wi-Fi and support for modern hardware, while maintaining the original system's speed and simplicity.
"Somehow BeOS resonated very strongly with some people," Haiku developer Stephan Aßmus says.
"Most people who used it will mention how fast and responsive it felt. To me, that's only one aspect. The other is elegance. By that I mean how the system tried to avoid redundancy at all levels and how it tried to figure out clever ways to empower the user.
"It made everything so transparent. Just by looking at the system folder layout, it was easy to understand how stuff worked. The system provided more or less one clear vision of how all the components are supposed to fit and work together from the kernel to applications."
Aßmus has been part of the Haiku project, which began in 2001, for seven years, contributing code and art, as well as representing the project at conferences and mentoring participants in Google's Summer of Code program, which Haiku has been a part of.
The initial aim of the Haiku project is to create an open source, drop-in replacement for BeOS R5. "It's supposed to be binary compatible, so all old BeOS applications continue to run," Aßmus says.
"Ideally, you could replace the contents of the system folder of your BeOS installation with the Haiku system and everything just continues to work."
But although a system compatible with R5 is a "fixed goal" for project participants, Aßmus says that "Haiku is open to new ideas and many BeOS features have already been extended or replaced with modern versions.
"If an idea is too crazy however, we can always say, if it wasn't in BeOS R5, it doesn't need to be in Haiku R1. And it really helped the project stay focused."
Aßmus was an Amiga user until the late '90s when he started looking for a replacement system.
"I had heard of BeOS as the system that some Amiga developers switched to and that they liked very much," he says.
"Compared to the Amiga, BeOS was very modern. For example it used 32-bit colour on the desktop while my Amiga was using 4-bit, 16 colour palette mode."
Along with Ingo Weinhold, who is also a major Haiku contributor, he travelled to the CeBIT trade show to see BeOS in action. They both came away convinced of the platform. Weinhold bought a PowerPC-based Mac clone -- BeOS was already running on PowerPC at that point -- while Aßmus purchased an x86 PC after a BeOS rep said that the OS was being ported to the architecture. "I had to wait for another year, I believe, but when BeOS R3 was released, I immediately bought and installed it," he says.
Aßmus and Weinhold both began developing applications for BeOS (Aßmus was largely responsible for WonderBrush, a graphics program for BeOS).
"When Be Inc went out of business in 2001, we already had quite some investment into the platform. And the alternatives at the time where not appealing to us."
Hence the appeal of Haiku.
The current version of Haiku is R1/Alpha 3, which was released in June last year. The hardware requirements have remained minimal compared to most contemporary operating systems -- at least 128MB of RAM (although 1GB is recommended as a minimum for compiling Haiku from within the OS) and 700MB of hard drive space. The Alpha 3 state that the system "has been tested to work on CPUs as slow as a Pentium II 400 MHz". Alpha 3 added improved file system and hardware support, MediaKit improvements, UI tweaks, and support for more than 4GB of RAM.
For a typical end user, there might not be a lot that Haiku can offer compared to other systems, at least in its current state, Aßmus says. However, under the hood, there are big differences between it and the more commonly encountered open source Linux-based OSes.
"Linux is not transparent and self-explaining at all. The system folders are a complete, redundant and cryptic mess," Aßmus says. "When I launch a new Nautilus window, it takes anywhere from half a second to 3 seconds until I see it appear. When I open a new Tracker window in Haiku, it appears instantly. Why is that? I know Linux is insanely optimised.
"The components that make up most Linux distributions are developed as an evolutionary process. That means that for many system services, multiple alternative implementations exist and they compete with each other. It drives the whole open source ecosystem forward and works quite well, despite all the redundancy and wasted energy. It is accepted as a necessity and the best or only possible way."
However, Haiku "is replicating what has already been accomplished": Building an OS from scratch instead of in an evolutionary manner.
"But as a user, I don't care so much about all that," Aßmus admits. "I can make a choice for a platform to install on my computer. I make a choice for particular applications, ideally only one for each task I need to perform."
However, in Ubuntu, for example, "that may mean that under the hood, multiple redundant, alternative system components and application frameworks are installed in parallel," Aßmus says.
"Qt and GTK are an obvious example, but it goes much farther and deeper. That the system actually feels so uniform on the surface, I consider a huge achievement.
"That sort of bloat and redundancy is what the Haiku project tries to avoid at all costs. For any given piece of system functionality, we try to provide only one implementation, one backend. Multiple APIs may map to this single implementation, but the system remains lean and clean."
For users this should mean that Haiku will be transparent, easy to understand and easy to fix, as well as fast and responsive and it should offer a more uniform experience.
Although the Haiku project has attracted people who haven't used BeOS, Aßmus believes that most of the core contributors have a history with Be Inc's operating system.
Despite this it's easy for people to get involved in Haiku, Aßmus says (although he adds "especially if one writes quality code"). "The Haiku user experience still has many rough spots and sometimes it's obvious how it should work instead and it's easy to make those changes.
"For new features, it's much easier to get them in when everyone feels they align with the vision of the project. Which everyone more or less has his own version of in his head, I suppose."
New people often join the Haiku mailing lists, which house discussions on new features. "When someone proposes a feature on the mailing list, often people try to envision how it could be implemented in a more generic and more elegant way, so that it doesn't solve only one particular use-case, but many similar ones.
"And that sometimes means the feature is not implemented for the time being, since it became clear that it's harder and more work to do it right. I believe that can sometimes feel frustrating, especially to aspiring contributors, since the original proposal looked like an easy change. At the same time, I think it's good for the eventual quality of Haiku."
The small size of the Haiku team can be a benefit because "everyone sort of knows everyone. And for new people it's easy to get to know and interact with everyone. The team is pretty welcoming and friendly; it's an ideal playground and every contribution is automatically important."
Haiku remains mostly a hobbyist OS, although "it has a lot of potential, especially since Haiku can be rather useful by hobbyist operating system standards". There is still plenty of room for adding features and polish.
"Haiku needs to realise more of its own potential, by integrating already existing features more to the benefit of users," Aßmus says. "And obviously Haiku needs more powerful applications to get actual work done. It depends on more capable developers to recognize the potential and share the overall vision of Haiku and to start contributing."
Haiku feels as snappy as BeOS, despite the project's team adding new features (such as internationalisation). "The Haiku kernel actually runs circles around BeOS," Aßmus says. "For example compiling Haiku on Haiku is more than seven times faster compared to compiling it on BeOS and only about 20 per cent slower compared to compiling it on Linux, on a dual core machine."
Kernel development has probably been the most challenging aspect of Haiku development, Aßmus believes. Hunting down kernel, file system or driver bugs is challenging, particularly given sometimes they crop up only on certain hardware configurations. I am not part of the kernel team; I completely admire them."
Of the development he has participated in directly, working on the Haiku Media Kit, particularly integrating the FFmpeg open source multimedia framework, has been most challenging.
Aßmus is also proud of the graphics subsystem, which he mostly implemented. "I integrated the excellent Anti-Grain Geometry library as the actual drawing backend into the Haiku application server. It all feels pretty fast considering it runs completely without hardware acceleration."
The OS uses the MIT License; a lot of open source operating systems, particularly Linux-based ones, primarily use the more familiar GNU General Public License. Aßmus wasn't around when the decision around licensing was made, but assumes it was because the MIT License was considered more business friendly (the MIT License doesn't restrict combining reusing code with software that has a proprietary license). ("These days, I think the GPL can be just as or more business friendly, since a business making an open source contribution knows that all other businesses are required to play by the same rules," Aßmus says.)
The project's members are currently working towards Haiku R1/Alpha 4, with the next release currently a topic of discussion on the Haiku development mailing list. "We don't call our releases 'beta', since we don't consider them feature complete," Aßmus says.
The "one big missing feature" is package management: "A lot of interesting and visionary work has been done for package management already, but it changes many fundamental aspects of Haiku. Like the system folder layout and some important things like the system folder itself becoming read-only.
"That's why it is not yet in the master branch. It needs a lot more work before it can be integrated. The people having worked on it most are currently too busy with their jobs, so the progress on that front has stalled for the time being."
When Haiku hits 1.0 -- or 'R1' -- it will have "tons of new features" compared to BeOS R5, despite being a drop-in replacement for the older system, Aßmus says. "Internationalisation, cool new APIs like powerful layout management. End users see this as all apps being scalable and adopting to different strings when switching languages.
"All the drawing in the interface is anti-aliased. All the icons are now 32-bit vector icons. BeOS had 16x16 and 32x32 256 colour icons with a system wide, fixed palette. Haiku also offers a WebKit-based browser with support for modern Web standards. [The] NetPositive [Web browser] on BeOS didn't even support CSS, let alone JavaScript.
"Haiku has support for modern hardware, like wireless networking. BeOS R5 didn't even support USB 2.0 or mass storage devices out of the box. And actually, BeOS doesn't even run on most computers made in the last eight to 10 years. It would not even boot when your computer had more than one gigabyte of RAM installed."
There's no release date for R1 yet, but the project is making a lot of progress, particularly thanks to being part of Google Summer of Code (GSoC). However, a decision by the development team means the features being worked on by GSoC participants are not critical for R1's release.
"There is an x86_64 port, NFSv4 module, BFS resizing support, power management and even an OpenJDK port -- all progressing nicely," Aßmus says. However, package management remains stalled, although this "may change at any time".
"It may take at least another year, probably more, before package management is ready. Maybe if one or two of our capable GSoC students sticks around and dig into that field, it could go a lot faster."
The team behind Haiku have tentative plans that look beyond R1, however: While R1 will replicate the functionality of BeOS R5 (albeit with modern hardware support and a stack of extra features) Haiku R2 is intended to take the BeOS philosophy even further.
"One big challenge [with R2] will be to extend and shape the features that are already there, and adopt them more towards the use cases of actual users," Aßmus says.
"For example, Haiku does not realise the full potential of file system queries, which is mostly a matter of how search results are presented to the user, and how queries are integrated or used within applications. There is a lot of potential there.
"And of course there are features like hardware 3D acceleration, compositing on the desktop or multi-user that everyone would love to have."
One challenge for the future will be "What happens when other frameworks are ported to Haiku?"
"What is the difference of running a Qt application on Haiku versus running it on Linux?" Aßmus says. "Qt is already available for Haiku. Maybe someone ports GTK. The OpenJDK port is very far along and can run big Swing based Java apps. This both benefits Haiku as a platform, but it also makes it less compelling to write native Haiku apps.
"And that basically defeats the desire to provide a redundancy free system where everything works only one way, completely integrated with everything else."
Haiku R1/Alpha 3 can be at .
Rohan Pearce is the editor of Techworld Australia and Computerworld Australia. Contact him at rohan_pearce at idg.com.au.
Follow Rohan on Twitter: @rohan_p
Follow Techworld Australia on Twitter: @techworld_au