Haiku OS Resurrects BeOS as Open Source

Technical Writing Geek writes "The Haiku project, which began shortly after the death of BeOS in 2001, aims to bring together the technical advantages of BeOS and the freedom of open source. 'The project has drawn dozens of contributors who have written over seven million lines of code. Although Haiku is nearly feature-complete, there are still numerous bugs that must be fixed before it is ready for day-to-day use. The design principles behind Haiku are very closely aligned with those of BeOS. The central goal of the Haiku project is to create an operating system that is ideally suited for use on the desktop--this differs significantly from Linux and other open-source operating systems which are intended for use in a diverse range of settings including server and embedded environments.'"

Interesting....

[fyngyrz]

But I don't look forward to the long climb up the curve of identifying and cleaning up what, going by past experience, is likely to be quite a nest of security issues.

Having said that, if it is actually like BeOS in that it handles multimedia similarly (that is, *really* well and without even a nod towards DRM), I'd be very likely to put some effort into using it. Linux's swap paradigm is completely unsuited to applications that need to respond *right now*, OS X is just about the same (it's only been a matter of hours since I shook my fist at Leopard for swapping out things I was using), and Windows... ugh. Going completely the wrong way.

I suppose it'll be a while yet, though. [prepares to wait]

Re:First poem

[xTantrum]

from TFA:

BeOS featured a unique modular microkernel

i wasn't aware BeOS used a microkernal. i wonder if this gives any merit to tanenbaum's [cs.vu.nl] views. with everyone and his grandma extoling the virtues of the BeOS this diffinetly makes me want to look closer at minix again.

Network Functionality Embedded in Kernel?

[quanticle]

Haiku's network performance is better, for instance, because the networking functionality is integrated directly into the kernel rather than running in userspace as it did in BeOS.

Am I the only one that thinks that this is a horrible idea from a security perspective? Also, wouldn't the integration of network functionality mean that Haiku is about as much of a microkernel as Windows NT?

Awesome!

[Anonymous Coward]

I used to run BeOS and am a huge fan. When this reaches the point where it runs reasonably well on an EeePC, the dubious Linux install on that thing is *so* gone.

Re:Interesting....

[fyngyrz]

When you say a ground up rewrite, I worry. This is because the real-time nature of the OS is something that none of the other "big 3" have gotten right; there isn't a one of them that won't glitch your audio or video just at the wrong time (not that there is a right time.) BeOS was unique in that it was designed to be real time from day one and -- and this is the kicker -- they got it right. For the first time in modern OS history. So the issue here is, given that this is a rewrite to (presumably) R5 interface spec, will the underpinnings be of a similar nature, or will we simply have a fourth OS that can't handle real-time demands reliably?

Re:Evolution

[Fred_A]

It would be nice to see it not only bringing back the technical advancements that once were available but to also see it bringing some new features.

Applications would be nice too.

It's nice to have all those systems, but when people are looking at creatingsoftware for an open system for the desktop, they target Linux, possibly with a side of BSD. If the result compiles on Be, that's an unintended bonus, but nobody in his right mind is going to go out of his way to make it so.

The people of Bibble Labs who make commercial (and closed source) photography software which I buy from them sell their stuff for Windows, Mac OS and Linux (which is why I use it).

The last time I looked at Be, it wasn't too hard to *port* Unix/Linux software to it. However it really needs to be able to "just" run it, at least for the Linux binaries (like the *BSD do with the Linux libs). Otherwise it's going to be a repeat of 1999 (or whenever that was) when everybody played with the Be live CD or created a little partition to poke at for a while, and then went back to Linux or Windows or whatever the system where his software and data lived was.

Be was/is a nice system, among other things I liked the ideas in the filesystem. But unless there's actually a reason to use it (and there's none), nobody will. Unless you're into that kind of thing and you still have a little space next to your OS/2 partition. But then you're probably too far gone anyway.

Re:Yes, License Issue

[Anonymous Coward]

But that's a non-issue. If you GPL the stubbing code, it all runs in a process with the GPL driver code, and could live happily within a completely commercial + proprietory closed-source system, let alone any open-source one.

This is a major win for microkernels which Tannenbaum missed - they allow you to use any driver on any system with no GPL-esque legal issues arising because there's no linking.

Haiku is COOL! Normal desktop footprint is 60 Meg

[StCredZero]

Haiku is an example of code reuse par-excellence! You can get a normal desktop footprint into something like 60 megabytes. (Not one of these cut-down small footprint distros.) It's how an object-oriented multimedia operating system should be done.

http://video.google.com/videoplay?docid=236331448076587879 [google.com]

Haiku is damn cool
The One OS that follows
Don't Repeat Yourself

Re:Network Functionality Embedded in Kernel?

[mpapet]

Linux's networking stack is in the kernel. Firewall too.

So, your concern may not be kernel-levelness, but maybe the privilege with which networking runs? Or, perhaps if the networking kernel component can bring the whole OS to a screeching halt?

OS's are complicated, so it's easy to nit-pick from ./. That's a bad habit though because the more different OS's are out there being worked on the better off we all are.

As an example to all, I'll fire up qemu this afternoon and install haiku on my trusty old thinkpad. If 100 ./'ers did it and provided feedback to the project, it's a benefit to all.

Re:First poem

[Anonymous Coward]

Indeed it was -- because you'd be restarting that particular service (network) over and over and over.
  When all your connections die, does it matter that much if it's a service? The thing booted in 5 seconds anyway.

Re:What was the point of BeOS/Haiku?

[Anonymous Coward]

>>Multimedia works just great on my Windows XP machine.

Please don't take this as an insult, but the reason you feel that multimedia works "just great" on your XP box is probably because you've not seen anything better. In the same way propeller-driven aircraft were just fine until jet engines came along. BeOS *was* better than anything else at the time (Can't speak to Haiku, as I've not run it). I ran BeOS as my primary OS for several years and in those days Windows would struggle to play two (or sometimes just one) video smoothly, with well-tracked audio. BeOS had no problem on the same hardware with a half-dozen simultaneous videos. It could simultaneously import video, mix audio tracks and play video streams, render 3D graphics, etc. and when it did slow down, it did so gracefully and never failed to respond the way that Windows would (e.g. click a menu, wait 20 seconds for Win to load the code and draw the menu).

The main thing is, BeOS was amazingly fast and responsive in the days of I486 CPUs and 128Meg RAM. Menus and UI elements responded instantly. Cold boot to completely loaded desktop, on the net, HDD light off and ready to work? Something like 15 seconds. Windows took something like 2 1/2 minutes by comparison and the HDD never quit rattling. Why? Clean design internally and small size -- about 50MB for the whole OS including sample applications, code, and demos. (Or to put it another way, about the size of one of the hundred-or-so security patches for Windows XP.)

From a programmer's perspective, BeOS was the best-designed OS I've ever coded for. Everything was logically named, well structured and designed with threading in mind. (In fact, every window ran in its own thread). Written entirely in C++, it was just brilliantly designed and easy to code for!

Personally, I'm pretty excited about Haiku. IMO, BeOS was the best OS from the 90s. (BeOS was created by a spin-off group from Apple France, the same group that defied Steve Jobs' direct orders and developed the Color Macintosh (early 1990s?) and saved Apple. I was profoundly disappointed that Apple chose NeXTStep over BeOS for what was to become MacOSX.

So, that's my long-winded way of saying "give it a try! You have no idea what you're missing."

Re:The design principles behind Haiku are...

[samkass]

As a former BeOS fan, I agree it was a great OS, but let's not whitewash the past. They had some significant design challenges ahead of them if they wanted to go mainstream. Everything from the "fragile base-class problem", which they never really solved, to support for lots of functionality most users consider basic these days had the potential to eat away at the performance.

BeOS had a local file search in 1997 that would rival OS X 10.4 ...which is why Apple hired the guy to help develop MacOS X 10.5.

they were a decade ahead of their time, and got killed by MSFT because of it.

"got killed"? Apple didn't buy them, and Microsoft encouraged VARs to not sell it pre-installed, but the simple fact is that it wasn't really valuable enough for most people to want to buy it. Windows 95, Windows 2000, linux and MacOS 9 were "good enough" for most folks across most market segments.

Re:Evolution

[discogravy]

If I understand you, it sounds like haiku/the beos user movement needs someone to intentionally break gcc-2.x-binary-compatibility (like redhat did with their gcc2.95 in RH8) to kickstart the move out of the old software. Possibly there's no one Free-BeOS users' group/os-project that has the numbers to catalyze all the others into switching. Too many forks, not enough people to choose just one and stick to it. Which is a shame, from the time I ran BeOS Max PE, it was a work of genius.

RIP

[DNS-and-BIND]

"I once preached peaceful coexistence with Windows. You may laugh at my expense - I deserve it."

-- Jean-Louis Gassée, CEO Be, Inc.

Sorry

[Vexorian]

MIT license because the developers want to encourage corporate involvement and believe that permissive licensing creates a healthier relationship with commercial industry.

I stopped liking the idea after I read that.

Than you BeOS

[Faux_Pseudo]

I used BeOS for about 20 minutes back when it was around. I would have spent longer playing with it but something amzing happened. When I went to to check if it could recognize my modem it did and it connected to my ISP. Which was something I was unable to do with any version of Linux I had tried so far. So I quickly started digging through the differances in the code of the Linux version I was using at the time and BeOS to find out where the magic happend. I didn't find it but I asked some others and turned out I was only one line of code away from fixing the problem. /bin/setserial -b /dev/modem IRQ 3
I never got back around to trying BeOS but I am ever so thankful for it providing me proof that my modem was supposed to be working. After that I deleted windows from the 1.3 gig hard drive and was Linux only. Been windows clean for about 9 years now and I owe it all to BeOS. Maybe when Haiku comes out I will dedicate at bit more time to it. Maybe it will be or provide an alternative to Windows for more people.

Re:Evolution

[Anarke_Incarnate]

I know it will kill the performance to some degree, but why not create a compatibility layer ala WINE for BEOS apps ? BINE perhaps?

Re:Interesting....

[Lally Singh]

It sounds like what you want is a combination of:

1. Real-time scheduling. Preferably hard-real time (for stable video)
2. Page locking. Don't let RT tasks page out
3. Drivers written to obey the scheduling demands (e.g. don't wait for a disk while we have an RT task ready)

It can all be done on regular desktop OSs.

Challenges are:

1. Requiring RT scheduling and page locking usually require a good level of access. For that, you'll probably want a capabilities-based permission model to to keep quicktime from giving people backdoors into root access
2. Keeping device drivers off the RT thread path. I'd honestly prefer a separate I/O processor to do that stuff, so the CPU can keep chunking along. Dedicating RT threads to one core and device drivers to another isn't a bad way to splice up modern dual-core CPUs.
3. It's easy to end up page-locking a lot of pages in for processes, large platform shared libs & all

I bought BeOS, back in the R3 days...

[ZenDragon]

I bought BeOS, back in the R3 days and was very sad to see it go. Despite the lack of hardware support it truly was a revolutionary operating system, its multitasking capabilities were unmatched on the hardware at the time and I can only imagine what it might be like on modern hardware. I will definitely be keeping an eye on the progress of this project. Personally I would love to see this project gain some support from the music creation industry. Software like Traktor, and other DJ related software would run fantastically on this OS. BeOS was touted as a multimedia OS and it blew everything else out of the water at the time.

Re:Evolution

[discogravy]

is there a particular reason you can't have both? (and statically link the libraries needed for the older-gcc-compiled binaries? it would take up disk space, but that's cheap these days...)

Check out Moka5

[DisorderlyConstruct]

The system you described is what I use every day. It is called Moka5 BareMetal [moka5.com], and you boot into it and select what virtual environment you want to run. The virtual environments (what they call "LivePCs") automatically update when the version on the server is updated. It keeps the user data (documents, settings, etc.) separate so you can revert and update the system without losing your data. You can suspend them and they start up pretty quickly. Makes using XP and Vista a lot more pleasant, plus I have a bunch of other Linux distros installed. It's a very cool system.

To stay on topic, there is a Moka5 LivePC for HaikuOS [moka5.com] available for download, so you can try out Haiku without installing it.

Re:Evolution

[KugelKurt]

IIRC this was requested. The BeOS binary-compatible code was suggested to be placed in /beos while the GCC4 code should be placed into /haiku. If my memory serves me right, this idea wasn't welcome because it's too much work, wastes too much space on old PCs and so on.

Re:Why Apple didn't go with BeOS

[Anonymous Coward]

Actually, Apple had a relatively good new OS, MacOS 8, a real protected-mode OS which got as far as a first developer release. But it wasn't backwards compatible with old MacOS programs, and apps would have to be rewritten. In particular, Microsoft Office for Mac would need an overhaul, and Microsoft wasn't willing to do one. The same problem applied to BeOS.

You're not remembering things clearly. Assuming you're talking about Copland (as opposed to the released MacOS 8, which was something quite different), the design was actually quite compromised in order to guarantee backwards compatibility. Nobody would have had to rewrite just to get their applications running.

Describing it as 'relatively good' is questionable. Ever booted one of the Copland Developer Releases? I managed to coax it into happening once. It was not pretty.

(I think I still have a copy of the disc, but it'd be difficult to find the hardware to boot it on now. It only worked on a handful of early PowerMac models.)

Steve Jobs was brought in to suck up to Microsoft and cut the deal which kept Office on the Mac for five years.

Uh, yeah. This was on his job description, then?

Apple needed that deal to survive. That's the real reason for the NeXT acquisition.

No. The real reason was that Apple's board went out looking to buy an OS once it became clear the internal next generation OS project had failed. At that time, it probably would've been possible to resurrect Copland by cleaning house, hiring replacements for those booted out, and restarting implementation nearly from scratch, but the result would have been far too late and far too out of date to be worth the cost in dollars or time. With the company in deep trouble due to the lack of a modern OS, the best option to get back on track quickly looked like acquisition (not just for the code but also to get the engineering staff and management -- Apple's problems with Copland had a lot to do with the organization, see above comment re: cleaning house).

NeXT was supposed to be closer to deployable than MacOS 8 or BeOS, but, as it turned out, it was years away from delivery as MacOS X.

NeXTStep was by definition deployable -- it had been deployed for years, since before 1990. And in fact Apple almost immediately shipped a slightly warmed over NeXTStep as MacOS X Server (it was, more or less, NeXTStep skinned to look a bit like MacOS 8).

In the early days of the NeXT merger, Apple was trying to push the idea of legacy Mac application compatibility only in a penalty (emulation) box. They had a pretty realistic shot at shipping that in about a year. However, Mac developers (not just Microsoft) revolted, because they'd have to completely rewrite their GUIs in an unfamiliar language and UI toolkit to get out of the penalty box. So Apple had to go back to the drawing board and come up with Carbon, and while they were doing Carbon they decided to modernize everything which needed modernizing in NeXTStep, which was a lot because NeXT had actually stopped new development on NeXTStep the OS for a few years mid-90s. And that's how it stretched to 3-4 years post-acquisition to ship MacOS X (client) 10.0.

The same process with BeOS instead of NeXTStep would only have shipped later, as BeOS simply wasn't as complete a system to begin with.

But can Haiku Run on a Bebox?

[Ober]

I type this in Links running on a Bebox dual 66mhz 603 running NetBSD. bebox# uname -a
NetBSD bebox.linbsd.org 4.99.52 NetBSD 4.99.52 (GENERIC) #0: Mon Feb 11 09:18:42 CST 2008 [e-mail]:/usr/obj/sys/arch/bebox/compile/GENERIC bebox
Now that is resurrection. :P

it's the applications, stupid!

[nguy]

The central goal of the Haiku project is to create an operating system that is ideally suited for use on the desktop

The degree to which an OS is suited to use on the desktop is primarily determined by (1) available applications, (2) ease of use, (3) driver support, and (4) stability. Linux has BeOS beat on (1) and (3). There is almost no work on usability on Haiku. And even in the best case, Haiku is at best equal to Linux on (4).

Re:Could someone explain to me...

[Eivind Eklund]

FreeBSD has generally had better network driver support than Linux. It has been the single driver area where we've usually been ahead. I don't know if that is true any longer or not - but at least it was, for a long period (1998 or so and forwards, after Bill Paul's "Let's fix FreeBSD network drivers"-run)

Eivind.