Linked by Thom Holwerda on Thu 23rd Oct 2008 19:58 UTC, submitted by FreeGamer
BeOS & Derivatives It seems like only yesterday when due to a combination of hubris, bad business decisions, and pressure from Apple and Microsoft, Be, Inc. went under, with its assets - including the BeOS - bought up by Palm, who now store it in a filing cabinet somewhere in the attic of the company's Sunnyvale headquarters. Right after Be went under, the OpenBeOS project was started; an effort to recreate the BeOS as open source under the MIT license. This turned out to be a difficult task, and many doubted the project would ever get anywhere. We're seven years down the road now, and the persistence is paying off: the first Haiku alpha is nearer than ever.
Thread beginning with comment 335131
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: Please explain
by umccullough on Mon 27th Oct 2008 15:11 UTC in reply to "RE[2]: Please explain"
umccullough
Member since:
2006-01-26

Ok, so there are APIs listed. If there are errors in the listing, then Haiku will not be totally compatible, right? The existing BeOS programs, are they binary compatible with Haiku or do you have to recompile under Haiku first?


If there are errors in the listing, they would not be in sync with the public headers from BeOS R5 (which are still available for anyone who can install and use BeOS R5) these can be easily determined. They are the very same headers that were used to compile all BeOS software, so there's no mystery here - if the headers were wrong, the apps would fail to link, if Haiku's headers don't match R5's headers, then the binary compatibility is lost anyway.

They do not have to be recompiled unless they used something in BeOS R5 that Haiku has no re-created. There are a few APIs that were intentionally changed because they were "broken" in BeOS, but they were either the lesser-used ones, or all software utilizing them had suitable open-source replacements already and therefore did not require binary compatibility.

Reply Parent Score: 2

RE[4]: Please explain
by Kebabbert on Mon 27th Oct 2008 20:27 in reply to "RE[3]: Please explain"
Kebabbert Member since:
2007-07-27

Ok thanx for explaining this. One more question. The BeOS kernel might be totally totally different from the Haiku kernel. Is that a problem? We know that BeOS had great performance. The Haiku kernel, could it be built less optimal and have bad performance but still obey the BeOS api and therefore be binary compatible? Could BeOS kernel be super engineered whereas the Haiku kernel could be poorly engineered and have terrible performance? Could it be so? How do we know Haiku kernel is as good as BeOS kernel? We dont have the BeOS code?

Reply Parent Score: 2

RE[5]: Please explain
by umccullough on Mon 27th Oct 2008 21:43 in reply to "RE[4]: Please explain"
umccullough Member since:
2006-01-26

How do we know Haiku kernel is as good as BeOS kernel? We dont have the BeOS code?


That's what benchmarks are for ;)

Already, the Haiku kernel performs many operations faster than BeOS did.

Often times reading the code does not reveal its relative performance, that actually takes real-world tests anyhow. The "performance" of BeOS wasn't necessarily a result of any special coding tricks that only Be, Inc. coders knew, but rather certain design decisions that Haiku also follows in many cases.

I think if there was ever a comparison made between Haiku's code and BeOS' code, we'd find that the Haiku code might be cleaner and better-written largely because it's FOSS, and built from the ground up to re-implement the same functionality as BeOS.

The kernel Haiku forked from was NewOS, which was written by an ex-Be engineer originally.

Reply Parent Score: 2

RE[5]: Please explain
by mmu_man on Tue 28th Oct 2008 00:37 in reply to "RE[4]: Please explain"
mmu_man Member since:
2006-09-30

The BeOS kernel has really poor performance compared to even old Linux. It just had better design in some places (that Linux still didn't pick up), and so has the upper layers. The overall multithreading gives the impression it's faster, while the kernel is much slower.
Some parts of the BeOS kernel had gross hacks that allowed it to take shortcuts but wouldn't scale to today hardware.
Haiku has already much better code quality overall because it received a lot more peer review than BeOS ever had.

Reply Parent Score: 2