Comment by MisterTea | Hacker News Reader

Comment by MisterTea | Hacker News Reader

Parent Full thread

The CPU monitor program was called Pulse and early versions allowed you to turn all the processors off and crash the machine. I think it was fixed in 3.something or 4.0.

The 8-way PIII Xeon was a Compaq someone tested BeOS on before it went into production. I Remember it being posted on some BeOS news site. There should be another screenshot or two with 25 avi files playing and a crap load of CPU hungry programs running at once. Impressive feat circa 2000. Edit: browse the screenshot directory for the other two. Amazing they survived time, internet, bit rot and my memory: http://birdhouse.org/beos/8way/

The BeOS scheduler prioritized the GUI and media programs so you could load the machine down to 100% and the GUI never stuttered and windows could be smoothly moved, maximized and minimized at 100% CPU. Rather, your programs would stutter. And everything was given a fair chance at CPU time.

Very nice design and the OS was built from the ground up for multimedia and threading for SMP. It was a real nice attempt at building a next generation desktop OS. Had no security even though it had basic POSIX compatibility and a bash shell. Security bits meant nothing.

I remember circa 2000 being able to simultaneously compile Mozilla, transfer DV video from a camcorder into an editor, check email, and surf the web on a dual Pentium Pro system with no hint of UI stutter or dropped frames in the firewire video transfer. It was at least another decade before SSDs and kernel improvements made that possible on Linux, Windows, or OS X.

The tradeoff was the throughput of your compilation was terrible. BeOS wasn't magic, it just prioritized the UI over all else. That's not advanced, it's just one possible choice.

MacOS prior to OS X had the same property: literally nothing else could happen at the same time if the user was moving the mouse, which is why you had to take the ball out of the mouse before burning a CD-R on that operating system.

Oh, sure, it was obviously limiting the other tasks. The point was that this is almost always the right choice for a general purpose operating system: no user wants to have their music skip, UI go unresponsive, file transfers to fail, etc. because the OS devoted resources to a batch process.

You’re only partially correct about classic macOS: you could definitely hang the OS by holding down the mouse button but this wasn’t a problem for playing music, burning CD-Rs, etc. in normal usage unless you had the cheapest of low-end setups because a small buffer would usually suffice. I worked with a bunch of graphic designers back then and they didn’t get coasters at a significant rate or more than their Windows-using counterparts, and they burned a lot of them since our clients couldn’t get large files over a network connection faster than weeks.

You can down play it all you want but it was a really nice OS for its time. It's smooth GUI was very competitive to other clunky windowing systems of the time. The advanced part was threading and smp support were woven into the system api making smp development a first class programming concept. Other operating systems felt like threading was bolted on and clunky. And thanks to the smp support prioritizing the GUI made 100% sense. And I believe there were some soft real time abilities of the scheduler so processes with high priority ran reliably.

Thanks for this. I remember being at MacWorld and watching a movie play while holding down menu items. On Classic Mac, which I was used to, this would block the entire OS (almost). BeOS seemed space-age.

Oops, probably too late but the memorial day videos were included with BeOS. It was a bunch of the Be employees tossing a few broken monitors off the roof of their office building. https://www.youtube.com/results?search_query=beos+memorial+d...

Reply on news.ycombinator.com