How Haiku Is Building a Better BeOS 137
angry tapir writes "BeOS may be dead, but over a decade after its lamentable demise the open source Haiku project keeps its legacy alive. Haiku is an attempt to build a drop-in, binary compatible replacement for BeOS, as well as extending the defunct OS's functionality and support for modern hardware. At least, that's the short-term goal — eventually, Haiku is intended significantly enhance BeOS while maintaining the same philosophy of simplicity and transparency, and without being weighed down with the legacy code of many other contemporary operating systems. I recently caught up with Stephan Aßmus, who has been a key contributor to the project for seven years to talk about BeOS, the current state of Haiku and the project's future plans."
Re:Haiku (Score:5, Informative)
From which I can deduce that you pronounce "BeOS" as "bee-oss" and not "bee-oh-ess" (the latter is how the BeOS FAQ says it should be pronounced (http://testou.free.fr/www.beatjapan.org/mirror/www.be.com/support/qandas/faqs/faq-0407.html)).
It's shit (Score:3, Informative)
Haiku is based on the excellent micro/monolith hybrid NewOS, and it had a very interesting prospect of becoming a great OS.
Unfortunately, the project is slowly heading towards disaster as more and more incompetent people have started to contribute (think GSoC gone wrong, permanently.)
The code base is 1) not security audited, 2) slow as hell, 3) assbackwards and 4) not having a snowballs chance in hell to work on my 4-way CPU (the memory manager dies under SMP load and must be rewritten.)
I loved BeOS, but this is not going to replace it.
Re:It's shit (Score:3, Informative)
Unfortunately, the project is slowly heading towards disaster as more and more incompetent people have started to contribute (think GSoC gone wrong, permanently.)
Care to elaborate?
The code base is 1) not security audited,
What says it can't be? Also, Haiku is only single user, so at the moment this doesn't even make sense. (pre-beta software is pre-beta)
2) slow as hell
Umm, most 3rd party reviews mention how fast it is
3) assbackwards
This isn't a statement.
4) not having a snowballs chance in hell to work on my 4-way CPU (the memory manager dies under SMP load and must be rewritten.)
Strange, my eight core AMD bulldozer cpu works just fine.
I loved BeOS, but this is not going to replace it.
Patches welcome
Re:Riding off into the sunset (Score:3, Informative)
Twelve years, give or take a couple of months
Unless you count updated hardware drivers so that it can actually run on a recently manufactured computer as "progress", that is. Personally, I'd call that "treading water".
BeOS is very interesting, and there are definitely some things we can learn from it. I think anyone involved in OS or especially GUI design should make a point of being familiar with it. (The same is also true of VMS, although that has a somewhat higher learning curve.)
I cannot, however, imagine wanting to actually use it as my primary operating system on a day to day basis at this point. I do not see it as a practically useful system today. Haiku perhaps could have been, if it had gotten started much sooner, like, immediately after it became clear in 1996 that Apple was going to buy NeXT and not BeOS, at which point it was already well understood that Be had either failed to convince OEMs to ship BeOS, either as a dual-boot option or solo or that any OEMs they did convince had become unconvinced due to other pressures. Thus, any intelligent person by the end of 1996 could easily figure out that the company was going to go under. If the Haiku project had been started right then, and if the project had progressed much more rapidly once it got underway, if, for example, Haiku R1 had come out in 1998 and a multi-user-enabled R2 in 2000, Haiku might have carved out a significant niche for itself.
But in 1996, and still in 1998, and even still in 2000 for that matter, most BeOS users were in denial about the company's fate and the possibility that store shelves might soon feature computers with BeOS pre-installed, so Haiku didn't even get started at all until 2001 (around the time the company formally announced that it was selling off all its assets and giving up on any possibility of further development in order to salvage what stock-holder value it could). Even as late as 2005 many BeOS users (the ones who had not yet switched to Linux or Mac OS X) were still in denial about the fate of the BeOS R5 source code base and whether whatever company eventually ended up with those assets might either resurrect the OS or else release it under an open-source license. So it's fair to say that Haiku development was a little slow getting started -- a slowness it could ill afford, given how far behind BeOS development had been already. BeOS had some cool advantages compared to the operating systems of the day, such as Windows 95 or, heaven help us, Mac System 7; but there were also some rather notable things it was missing, even then, things that should have been fixed in a subsequent release -- and presumably would have been, if the company had found enough of a market to continue to pay its operating expenses. Haiku, when it was finally started half a decade later, was even further behind, due to the need to start from scratch and reimplement what had already been done -- and once they eventually finish with that, they will still need to design and implement the things that Be had not yet done when it went under.
As a result of those delays, Haiku is still in no position to be adopted as an operating system for regular day-to-day use any time in the forseeable future. Among other things, it has no provision at all for file ownership, user accounts, or (meaningful) permissions. That was one thing in 1996, but now, in an era when we take for granted that everything has to interact with a hostile internet, and so other systems are no longer limiting themselves to simple owner/group permissions but rather are by necessity moving toward adding more complex and discriminating security systems (ACLs, application-level permissions, non-executable memory, ASLR, etc.), the Haiku developers speak of plain old multi-user capability as a pie-in-the-sky "something everyone would like to have" eventually in the distant-future R2. Aside from the obvious implications in multi-user (e.g., business) environments
Re:Riding off into the sunset (Score:3, Informative)
> Could BEOS be used as an alternate GUI for a Unix based system.
You could borrow *ideas* from BeOS if you were designing an alternate GUI for a Unix-type system, or any other system for that matter.
That would be kind of missing the point, though. The BeOS GUI was largely unremarkable. Okay, yes, if you had multiple desktops they could each have a different resolution (and color depth, if desired). At the time, that was innovative. Other systems have it now, of course.
On the whole, though, the really notable things about BeOS were infrastructural, not superficial. To speak of BeOS as a GUI is to rob it of its strengths and everything that makes it really notable.
The way BeOS did multitasking, for example, provided a level of responsiveness that other systems at the time were not able to deliver on similar hardware. That's a kernel design feature, not something you can layer on top when building a GUI.
The BeOS approach to hardware and drivers was really remarkable and completely unprecedented at the time and eliminated several major categories of problems in one fell swoop. Knoppix has since delivered something almost comparable. (I suspect it's probably implemented differently, but the results are similar, if not quite as impressive.)
Then of course there's the filesystem. Personally I'm not terribly fond of the BeOS approach to that (except for the journaling, which has become standard on other systems), but there's no denying that the filesystem, and in particular the unusual metadata handling, was a significant aspect of what made BeOS unique and conceptually interesting, and it's not something you could implement in a GUI without the underpinnings being there in the kernel and in the on-disk filesystem format.