Back in the day I downloaded the BeOS 5 Personal Edition, found a way to install it on a harddisk partition ( there are still people who claim this can't be done - even though the image comes with the partitioning tool and the installer ), later even bought the Pro Edition ( mostly to get the book and the PowerPC version ). There was also a ( rather weird ) version of Opera for it.
Either way, the company went titsup ages ago, there have been successor products ( like Zeta ), leaked betas ( Dano ) and a bunch of projects to recreate either the BeOS desktop or the whole thing from scratch.
So, a few days ago I got the latest iso from Haiku (https://www.haiku-os.org/) - the one successor projects ( of the recreate the whole think kind, which explains the long development time ) that is still around - and installed it on an old PC.
The good news:
- 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
The bad news:
- 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
Don't get me wrong though - hardware support has been modernized a lot since R5. It comes with a bunch of SATA drivers ( didn't exist back then ), USB2, lots more network hardware ( including some wifi chips ), half of which didn't exist when R5 came around, IPv6 is supported too ( was around but not widely used at the time. AIX had it since the mid-1990s for example. )
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?
http://blog.reverberate.org/2007/07/why-all-os-except-beos-have-failed-on.html
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.
Incidentally, I was just having a discussion about this very subject a couple of days ago: http://my.opera.com/community/forums/findpost.pl?id=15041082
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.
Maybe he doesn't have that great of connection speed? I have ten megs down and slow page loading seems to come down to the site itself. That is unless another process is misbehaving to the extent that slow the entire machine.
Haiku seems interesting and do have a couple spare harddrives sitting on that shelf.
But we're talking about the GUI responsiveness, not page loading time. Opera remaining more responsive while the page is loading is just one aspect of 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?
It's supposed to be a re-implementation of BeOS R5 first, with some improvements thrown in. So I think the answer is yes.
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.
That's not hard to do even on Windows. On my old job back in .de I had to write a bunch of GUIs for Windows NT and ran into just that, longish periods of work where the GUI would just sit there, not being redrawn or anything. Plain old win32 kind of pushed you there, by having a function that's called for all UI events ( clicks, redraw requests, mouse movement etc. ) and people would just put everything in there, or have everything being called from there. The result is, as long as that function does not return from handling one event there will be no further events delivered to the program, so the GUI is stuck. Having the event handler just interact with one or more threads that do the actual work is easy enough, there are lots of ways to synchronize things, pass data around etc.
Beats the hell out of me why people don't do that more often. Back then the excuse was that most of the threading stuff wasn't available on win9x and the like but that should have been out of the window a decade ago ( thank goodness we dealt only with NT and later 2000 at that time )
I'm sure it's fairly easy if you know what you're doing, but you've got to admit that not requiring any extra effort is probably better. ;)