Linked by Thom Holwerda on Tue 30th Jan 2007 23:40 UTC, submitted by anonymous
Permalink for comment 207615
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 06/20/13 6:17 UTC, submitted by MOS6510
Linked by Thom Holwerda on 06/19/13 23:02 UTC, submitted by M.Onty
Linked by Thom Holwerda on 06/19/13 22:28 UTC
Linked by Thom Holwerda on 06/18/13 22:33 UTC
Linked by Anonymous on 06/18/13 22:26 UTC
Linked by Thom Holwerda on 06/18/13 22:25 UTC
Linked by Thom Holwerda on 06/18/13 17:45 UTC
Linked by Thom Holwerda on 06/18/13 17:32 UTC, submitted by poundsmack
Linked by Thom Holwerda on 06/17/13 17:58 UTC
Linked by Thom Holwerda on 06/17/13 17:52 UTC
More News »
Sponsored Links



Member since:
2005-07-10
BeOS was pretty interesting at the time when you compared it to Mac OS 8/9, Windows 98/NT and Linux 2.0 (maybe RH5 or 6?). It had some cool features and pushed processing into SMP territory which was pretty rare back in the late 90's on a desktop computer.
The BeBox was pretty nifty by losing the L2 cache in favour of twin 603e CPU's, but nowadays it's quite slow from personal experience the last time I checked it out. The later Intel BeOS 5 ran circles around it on 400+ mHz Intel boxes with superior graphics hardware that had proper drivers.
Probably the biggest fault BeOS had was it didn't really have the driver support it needed compared to Linux's kernel drivers as well as no true blue Unix compatibility layer (it did support quite a bit, but not as much as GNU/Linux with X, libraries, etc). Just getting critical mass to support the BeOS API's was a bit of a tough ask.
These days again and again it's hardware support and application support that matters. All "the snap" and "way cool API's" don't mean much if you can't run the hardware you own and you can't run the applications you own.