6 ms·

One of my favorite anecdotes about BeOS was that it had a CPU usage meter[1], and on the CPU meter there were on/off switches for each core. If you had two core

One of my favorite anecdotes about BeOS was that it had a CPU usage meter[1], and on the CPU meter there were on/off switches for each core. If you had two cores and turned one off, your computer would run at half speed. If you turned both off, your computer would crash. Someone once told me that this was filed as a bug against the OS and the response was "Works As Intended" and that it was the expected behavior. (These are fuzzy memories from ~25 years ago. It would be nice if someone could confirm this story or tell me if it's just my imagination.) [1]: http://www.birdhouse.org/beos/8way/8way-1.jpg http://www.birdhouse.org/beos/8way/8way-1.jpg

MisterTea 7y ago
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/ 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.
- acdha 7y ago
  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.
  - forwhomst 7y ago
    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.
    - acdha 7y ago
      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.
      - forwhomst 7y ago
        Well in 1994 a CD-R without a buffer was neither cheap nor low-end. It was the only thing you could get, cost as much as a car, and was bigger than a laser printer.
    - MisterTea 7y ago
      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.
- statico 7y ago
  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.
- MisterTea 7y ago
  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+day https://www.youtube.com/results?search_query=beos+memorial+d...
numlock86 7y ago
Reminds me of a game called NieR:Automata. You play as an android and the skill/attribute-system is designed as a couple of slots for chips. There were chips for things like the minimap and various other overlays along with general attributes, so if you decided you want to exchange your experience gauge for another chip with more attack speed, you could totally do that. Among these chips was one called "OS chip" you had from the very beginning. If you'd try to replace that or simply exchange it for another one you "died" instantly and were greeted by the end-credits.
colinstrickland 7y ago
It also has an `IsComputerOn` system call.
- tragomaskhalos 7y ago
  int IsComputerOn() { return 1; } ??
  - colinstrickland 7y ago
    if i recall correctly, if the computer is off the return value is undefined.

MisterTea 7y ago

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/ 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.

acdha 7y ago
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.
- forwhomst 7y ago
  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.
  - acdha 7y ago
    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.
    - forwhomst 7y ago
      Well in 1994 a CD-R without a buffer was neither cheap nor low-end. It was the only thing you could get, cost as much as a car, and was bigger than a laser printer.
  - MisterTea 7y ago
    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.
statico 7y ago
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.
MisterTea 7y ago
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+day https://www.youtube.com/results?search_query=beos+memorial+d...

numlock86 7y ago

Reminds me of a game called NieR:Automata. You play as an android and the skill/attribute-system is designed as a couple of slots for chips. There were chips for things like the minimap and various other overlays along with general attributes, so if you decided you want to exchange your experience gauge for another chip with more attack speed, you could totally do that. Among these chips was one called "OS chip" you had from the very beginning. If you'd try to replace that or simply exchange it for another one you "died" instantly and were greeted by the end-credits.

colinstrickland 7y ago

It also has an `IsComputerOn` system call.

tragomaskhalos 7y ago
int IsComputerOn() { return 1; } ??
- colinstrickland 7y ago
  if i recall correctly, if the computer is off the return value is undefined.