Linked by Thom Holwerda on Sun 24th Aug 2014 20:29 UTC, submitted by mikeanderson
BeOS & Derivatives

A very interesting discussion is taking place in the Haiku mailing list right now. A developer has created a working prototype implementation of the BeOS API layer on top of the Linux kernel, and he is wondering if the project is worth pursuing. He's got the App, Interface and Networking Kits in good shape within a few months' work.

While there are some minor downsides to having the kits on top of Linux (or one of the BSDs), the upsides include all the drivers in the world (well, the gpu driver situation could be a tad better), a rock solid kernel that works on all kinds of devices (who says BeOS can't run on a phone, mine can), and a working BeOS clone with comparatively little effort (as a musical engineer, my biggest worry was sound system latencies, but it turns out many Linux schedulers can easily be tuned to handle the loads I expect in a BeOS system.)

I think the Haiku project made a monumental mistake in not using an existing kernel - it's simply no longer practical for a small project to keep up with the hardware evolution, handling security requirements and so on. Sad but true, and it was sad but true back in 2001.

A very interesting and in-depth discussion follows. Both 'sides' make a lot of compelling arguments, and it gives a lot of insight into decisions that went into the Haiku project, both past and present. For once, I have no clear opinion on this matter; both sides have merit, and it in the end comes down to what the actual developers want to work on (hint: it's not Linux).

Still, the developer in question will be putting up a repository of his Linux work, so we'll get to see what it's like.

Thread beginning with comment 594834
To read all comments associated with this story, please click here.
Already tried is not feasible
by Leszek Lesner on Mon 25th Aug 2014 14:17 UTC
Leszek Lesner
Member since:
2007-04-08

We had something in the pipes for ZevenOS back in the days. But it was simply not feasible. Besides technological problems it did not make any sense for the users to have beos applications run on top of linux.
This was at least the most feedback we got back then.
People loved BeOS for the kernel and the desktop mostly not the apps.

Reply Score: 2

RE: Already tried is not feasible
by renox on Mon 25th Aug 2014 14:33 in reply to "Already tried is not feasible"
renox Member since:
2005-07-06

People loved BeOS for the kernel and the desktop mostly not the apps.

I'm not sure exactly what you mean by 'and the desktop', but people didn't love BeOS 'for the kernel', they loved it because of its responsiveness.

Why it was so responsive is difficult to know, being closed source, the kernel, the libraries, the application design, probably all played a part.

Now the question is: is-it possible to get the same responsiveness on top of another generic kernel (Linux and or *BSD)?
No one know for sure, I would be very surprised if it wasn't possible: if this was really the case, I would expect a benchmark showing that Haiku's kernel is better than Linux|*BSD at foo (foo being a benchmark showing the better latency).

Is-there such benchmark? AFAIK no.

Reply Parent Score: 5

zlynx Member since:
2005-07-20

I recall reading some analysis of why BeOS was so responsive.

It had to do with good use of threads and care was taken with the GUI messaging and task scheduling.

When a mouse click event happened for example, the event was sent immediately. The task receiving the event ran immediately. The GUI was updated again, immediately.

With Linux, and to a lesser extent Windows, the system is much more complicated. The amount of latency in a X Window app is pretty ridiculous. Also, last I read about it (may have changed), Linux is not very aggressive about immediately waking an app which is sleeping in a select or poll. The task sending the message gets to run its whole time slice first unless it blocks on something else.

Reply Parent Score: 3