Linked by Hadrien Grasland on Sat 19th Feb 2011 10:24 UTC
Hardware, Embedded Systems Okay, source material is more than 10 years old so this is not exactly news, but I think it's interesting anyway. This BeOS promotional video is a good reminder of how powerful modern hardware truly is, what hardware should be needed for light computer use, and how laughable modern desktop&mobile OSs are as far as performance is concerned. Here are part 1 and part 2 on YouTube.
Thread beginning with comment 463281
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: beos is well done
by _xmv on Sat 19th Feb 2011 20:58 UTC in reply to "RE: beos is well done"
_xmv
Member since:
2008-12-09

With BeOS/Haiku you don't need the application support for most threading. It's really from the ground up.

Unfortunately I do not possess a system with 1000 cpus :p

But booting Haiku with -smp 100 (emulates 100 CPUs) works just fine for example.

And yes every BeOS app has minimum 2 threads. It means apps cannot lock up as one is dedicated to the UI.

But it's not just that. The filesystem is threaded. The GUI framework is also threaded (it makes porting apps kinda difficult also). Etc.
Basically the API is async. Coding ain't as easy. But the result is there.

I would suggest "BeOS: porting UNIX applications
By Martin C. Brown" for example

Reply Parent Score: 3

RE[3]: beos is well done
by ciplogic on Sat 19th Feb 2011 21:17 in reply to "RE[2]: beos is well done"
ciplogic Member since:
2006-12-22

Today the difference in memory consumption is in abstraction level and in libraries.
BeOS have small libraries, Windows 95 will work like lighting (with patch to not start with a division by zero) booting in 5 seconds or so, without SSD.
XFCE + Linux can run today on those specs (you need to pin down libraries).
Where are antialiasing fonts? Where is Compiz or any composite support? Where are huge res support that may consume more memory.
Windows NT 4 delivers likely similar outcome in the same specs, excluding that threading support was likely beter, and for certain Windows 2000.
2 threads per app are nice, but if the fact is that your UI will remain responsible is the single benefit. Few applications are here. Writing your application multithreaded in a framework like Qt, will give today the same perceived fastness (as Google Chorme does it multiprocess). So don't cry for a dead man that looked amazing in Windows 95 world, but would look just nice today.

Reply Parent Score: 2

RE[3]: beos is well done
by malxau on Sun 20th Feb 2011 01:00 in reply to "RE[2]: beos is well done"
malxau Member since:
2005-12-04

With BeOS/Haiku you don't need the application support for most threading. It's really from the ground up...

And yes every BeOS app has minimum 2 threads. It means apps cannot lock up as one is dedicated to the UI.


That's a nice feature, but as you say, the benefit here is to prevent locking up the UI. It won't really distribute computation across cores - you're not really spending one core rendering UI, right? If you want to saturate a quad core machine, you'll need to distribute more than just farming out UI. The compute bound task itself needs to be distributed.

But it's not just that. The filesystem is threaded. The GUI framework is also threaded (it makes porting apps kinda difficult also). Etc.
Basically the API is async. Coding ain't as easy. But the result is there.


And that's true in NT too. The filesystem is quite parallel - NTFS has four different locks per file, for example, and the native API is fully asynchronous. But that only benefits you if the app uses asynchronous operations without immediately waiting for completion, which isn't generally done, since it's much harder for applications. So we end up with an OS that supports SMP really well, but the overall result still frequently falls short.

Reply Parent Score: 2

RE[3]: beos is well done
by Soulbender on Sun 20th Feb 2011 05:44 in reply to "RE[2]: beos is well done"
Soulbender Member since:
2005-08-18

It means apps cannot lock up as one is dedicated to the UI.

Uhm , no it doesnt. I had plenty of apps lock up back when I used BeOS.

The filesystem is threaded.


Doesn't mean it always performs well though. A fun experiment you could do back in the day (might have been solved with Haiku's OpenBFS since) was to have thousands of emails in a folder. Deleting a single email would take, and I don't make this up, minutes and sometimes much more. I remember trying to delete all of them and waiting for hours for the delete operation to complete. So much for built to scale.

Hey, BeOS was really neat (but so was the Amiga before it) but it was by no means the perfect OS.

Basically the API is async.

just like many other API's out there.

Reply Parent Score: 2

RE[3]: beos is well done
by phoudoin on Tue 22nd Feb 2011 07:35 in reply to "RE[2]: beos is well done"
phoudoin Member since:
2006-06-09

To be factual...

But booting Haiku with -smp 100 (emulates 100 CPUs) works just fine for example.


... this is false.

Haiku only supports up to B_MAX_CPU_COUNT, which is currently set to 8 for ABI backward compatibility.
Only first 8 emulated "CPUs" will be used, not the whole 100.

Otherwise, I agree fully.

Reply Parent Score: 2