Where debating everything under the sun is only the beginning

• it boots, it knows how to deal with the graphics card ( a Radeon R3xx in this case ) and the network card ( 3Com EtherLink XL )


• it comes with a webkit-based browser instead of the even back then outdated NetPositive. A Mozilla port has been around since the old R5 days.


• it looks and feels very much like BeOS R5 with a bunch of improvements ( new BSD-ish network code, things like a PDF reader are included, etc. )


• boots in a matter of seconds, even from CD, just like the original


• no crashes, trips to kernel debugging land etc.


• the UNIXy base system is more POSIX compliant, so porting non-GUI software should be a lot easier. Things like openssh are included.


• the boot manager found my NetBSD partition, automatically included it in the menu, and had no trouble booting it either ( take that, Microsoft )


• it knows how to deal with a real time clock running on UTC so it won't step over other UNIXy OSes that might be installed

• not much hardware support as far as I can tell, still feels quite fast though. No surprise for an Alpha release. Now that the kernel and filesystem parts are working properly they'll probably start to tackle that.


• doesn't come with a driver for the audio card I happened to have in that PC ( some Ensoniq PCI thing ) - there are patched drivers for the original BeOS which might work though


• no hardware OpenGL, but R5 didn't have that either ( R4.5 had it on some chipsets ) - no big deal for me

The programmer doesn't have to be diligent, the programmer doesn't have to have experience with the threading library; but automatically, without even trying, the app gets a separate thread for every window that is distinct from the main event loop. That means that even if the event loop spends some time doing something expensive, the GUI will continue to redraw, resize, render button clicks, etc. just as smoothly as if nothing were happening.

That's a big part of what made the BeOS GUI faster on late 90s hardware than Windows, Linux, OR OS X are on today's hardware.

So problem #1 is that today's GUI frameworks suck. They let the GUI become unresponsive far too often by failing to isolate the UI's responsiveness from long-running work that the application should be doing in the background.

Quote from: woj-tek

I concur - I've switched to firefox but the sluggishness of UI is plain annoying, compared to blazing fast and fluid UI of Opera 12 (and earlier). But... I' surviving, and it's million times better than Opera 15 both feature and resource wise...

It's because they're measuring exactly those aspects that have the least to do with whether the browser feels slow and sluggish or not. The Opera/Presto UI responds when you do things, possibly at the expense of page loading time but who cares? Only Safari also understands how important responsiveness is, at least on Apple's mobile devices. It stops rendering when you interact with it.

It's because they're measuring exactly those aspects that have the least to do with whether the browser feels slow and sluggish or not. The Opera/Presto UI responds when you do things, possibly at the expense of page loading time but who cares? Only Safari also understands how important responsiveness is, at least on Apple's mobile devices. It stops rendering when you interact with it.

BeOS has some unique software design that to my knowledge wasn't even attempted again until Apple's iOS. I would assume Haiku implements it?

So problem #1 is that today's GUI frameworks suck. They let the GUI become unresponsive far too often by failing to isolate the UI's responsiveness from long-running work that the application should be doing in the background.