5 ms·

I disagree. BeOS was also "built on top of Unix", to the extent that it ran bash and a standard UNIX-like command-line environment. Most Linux programs compil

I disagree. BeOS was also "built on top of Unix", to the extent that it ran bash and a standard UNIX-like command-line environment. Most Linux programs compiled fine for it (with the notable exception of mmap() which was not implemented yet). In my opinion BeOS was technically superior in the sense that it was far more pervasively multithreaded, which meant UIs never locked up just because they were waiting on some slow computation or network resource. I still believe it's the case that BeOS on circa-2000 hardware was more responsive than any UI I ever used before or since, including MacOS X on 2017 hardware. Even just resizing a Finder window in 2017 on my MacBook lags the cursor in a way that never happened on BeOS.

eight_ender 9y ago
Oh my yes. I still have a Toshiba Portege that boots BeOS R5 because at the time Windows 98 was a slow beast, and linux was terrible on the desktop. BeOS was amazing on that tiny thing. It was like the modern day equivalent of using a MacBook Air or Ultrabook for the first time. This small laptop can do everything I need and quickly.
fulafel 9y ago
Pervasinve multithreading and C++ would have meant a very unforgiving app development platform.
- pjmlp 9y ago
  Yeah because C makes it so much better.
  - deleted 9y ago
    [deleted]
  - fulafel 9y ago
    NeXT used Objective-C + events. The concurrency model is the major unforgiving factor, though apparently the NeXT Objective-C language and tools were ahead of the time in many ways as well.
    - pjmlp 9y ago
      My project supervisor had a Cube on his office, and my thesis was to port a particle simulation framework from Objective-C into Visual C++/Windows 98. Using Objective-C is just like C++ in regards to shooting yourself with the C subset common to both languages. Foundation did not have that much support for heavy multi-processing. At least not at the same level as OS X. It was all about UNIX programming model + Mach ports and tasks. If you want to read about it, this is one of the few places where the documentation is still available online. http://www.nextop.de/NeXTstep_3.3_Developer_Documentation/ http://www.nextop.de/NeXTstep_3.3_Developer_Documentation/
      - fulafel 9y ago
        Interesting! I grant that NeXT would have been more difficult for develop for when you did require parallelism for running compute intensive tasks on multiprocessor systems, but this was not the NeXT target market. BeOS got the ability to do parallelism by choosing the more fragile concurrency model, and apps paid for it in all cases. NeXT didn't do parallelism in the GUI apps, and was easier to develop for as a result.
qubex 9y ago
Much as I loved BeOS, I disagree with you regarding the Unix part. NeXT was built from the ground up as a UNIX. BeOS most certainly was not ”built on top of Unix”: it had a POSIX compatibility layer (but then, so did Windows NT) and that may enable certain superficial similarities, but at the base it was a very different, and somewhat indifferent, beast. For example BeOS never had, and never planned to have, multi-user support and different permissions.
- rvense 9y ago
  > For example BeOS never had, and never planned to have, multi-user support and different permissions. Oh, it did. The system was the same as Unix, only difference is you got logged in as root, but it was certainly there.
  - qubex 9y ago
    I'm sorry but you're just plain wrong. According to the canonical BeOS Bible there is a POSIX layer and some rudimentary kernel support for multiuser permissions, these were never fully implemented nor exposed. (Developed BeOS applications in the late 1990s.) https://www.amazon.com/BeOS-Bible-Scot-Hacker/dp/0201353776 https://www.amazon.com/BeOS-Bible-Scot-Hacker/dp/0201353776
    - rvense 9y ago
      It might have been added with R5.
fractallyte 9y ago
BeOS was only (mostly) POSIX compliant - very different from being 'built on top of Unix'.
badsectoracula 9y ago
> Even just resizing a Finder window in 2017 on my MacBook lags the cursor in a way that never happened on BeOS This might in part be because the compositor which syncs screen updates at 60Hz (or whatever your monitor uses) while the mouse cursor is drawn on top of that via the GPU. It is one of the reasons i really dislike compositors, they make everything feel sluggish. The only exception i know of is XFCE's compositor which has an option to not do any form of vsync so you get immediate updates. (although TBH i do not use compositors at all since i do not see the point, considering they are mainly used for frilly stuff like translucent windows with shadows that i personally avoid anyway)
zokula 9y ago
> In my opinion BeOS was technically superior in the sense that it was far more pervasively multithreaded, which meant UIs never locked up just because they were waiting on some slow computation or network resource. I still believe it's the case that BeOS on circa-2000 hardware was more responsive than any UI I ever used before or since, including MacOS X on 2017 hardware. Not true at all, the BeOS ui locked up plenty when using any real apps that is. GoBE office suite would slow BeOS and its ui to a crawl, Mozilla would too, a few IDEs that were around did too. Trying to do anything beyond dail-up networking was a joke. There are a few other apps that did slow BeOS as well but they escape me as I haven't really used BeOS in 15 years. BeOS was no more than a toy OS, I lost interest in it because Windows 2000, FreeBSD and Linux were more stable and just as fast on 2000-2004 era hardware.
- acdha 9y ago
  > Not true at all, the BeOS ui locked up plenty when using any real apps that is. GoBE office suite would slow BeOS and its ui to a crawl, Mozilla would too, a few IDEs that were around did too. That certainly doesn't match my experience: some apps like Mozilla could block their own window contents (but not window manager operations like moving or resizing) but the overall UI never blocked for anything except a video driver crash – and then only for a couple seconds as the kernel restarted that process. As an example, on a dual P-90 I could simultaneously stream video to disk from a FireWire camcorder (which was actually a real-time challenge on that minimally-buffered hardware which Win98 & OS/2 couldn't meet except with a completely idle system), compile Mozilla (which, IIRC, took about an hour), and not even notice the impact on my email and web browsing activity. Aggregate disk transfer performance would be slower but a good real-time scheduler meant that you didn't have huge lags while reading every small file. Windows and macOS still fail that test unless run with SSDs, and then only when e.g. Windows Update or the Xcode updates aren't running in the background.

eight_ender 9y ago

Oh my yes. I still have a Toshiba Portege that boots BeOS R5 because at the time Windows 98 was a slow beast, and linux was terrible on the desktop. BeOS was amazing on that tiny thing. It was like the modern day equivalent of using a MacBook Air or Ultrabook for the first time. This small laptop can do everything I need and quickly.

fulafel 9y ago

Pervasinve multithreading and C++ would have meant a very unforgiving app development platform.

pjmlp 9y ago
Yeah because C makes it so much better.
- deleted 9y ago
  [deleted]
- fulafel 9y ago
  NeXT used Objective-C + events. The concurrency model is the major unforgiving factor, though apparently the NeXT Objective-C language and tools were ahead of the time in many ways as well.
  - pjmlp 9y ago
    My project supervisor had a Cube on his office, and my thesis was to port a particle simulation framework from Objective-C into Visual C++/Windows 98. Using Objective-C is just like C++ in regards to shooting yourself with the C subset common to both languages. Foundation did not have that much support for heavy multi-processing. At least not at the same level as OS X. It was all about UNIX programming model + Mach ports and tasks. If you want to read about it, this is one of the few places where the documentation is still available online. http://www.nextop.de/NeXTstep_3.3_Developer_Documentation/ http://www.nextop.de/NeXTstep_3.3_Developer_Documentation/
    - fulafel 9y ago
      Interesting! I grant that NeXT would have been more difficult for develop for when you did require parallelism for running compute intensive tasks on multiprocessor systems, but this was not the NeXT target market. BeOS got the ability to do parallelism by choosing the more fragile concurrency model, and apps paid for it in all cases. NeXT didn't do parallelism in the GUI apps, and was easier to develop for as a result.

qubex 9y ago

Much as I loved BeOS, I disagree with you regarding the Unix part. NeXT was built from the ground up as a UNIX. BeOS most certainly was not ”built on top of Unix”: it had a POSIX compatibility layer (but then, so did Windows NT) and that may enable certain superficial similarities, but at the base it was a very different, and somewhat indifferent, beast. For example BeOS never had, and never planned to have, multi-user support and different permissions.

rvense 9y ago
> For example BeOS never had, and never planned to have, multi-user support and different permissions. Oh, it did. The system was the same as Unix, only difference is you got logged in as root, but it was certainly there.
- qubex 9y ago
  I'm sorry but you're just plain wrong. According to the canonical BeOS Bible there is a POSIX layer and some rudimentary kernel support for multiuser permissions, these were never fully implemented nor exposed. (Developed BeOS applications in the late 1990s.) https://www.amazon.com/BeOS-Bible-Scot-Hacker/dp/0201353776 https://www.amazon.com/BeOS-Bible-Scot-Hacker/dp/0201353776
  - rvense 9y ago
    It might have been added with R5.

fractallyte 9y ago

BeOS was only (mostly) POSIX compliant - very different from being 'built on top of Unix'.

badsectoracula 9y ago

> Even just resizing a Finder window in 2017 on my MacBook lags the cursor in a way that never happened on BeOS This might in part be because the compositor which syncs screen updates at 60Hz (or whatever your monitor uses) while the mouse cursor is drawn on top of that via the GPU. It is one of the reasons i really dislike compositors, they make everything feel sluggish. The only exception i know of is XFCE's compositor which has an option to not do any form of vsync so you get immediate updates. (although TBH i do not use compositors at all since i do not see the point, considering they are mainly used for frilly stuff like translucent windows with shadows that i personally avoid anyway)

zokula 9y ago

> In my opinion BeOS was technically superior in the sense that it was far more pervasively multithreaded, which meant UIs never locked up just because they were waiting on some slow computation or network resource. I still believe it's the case that BeOS on circa-2000 hardware was more responsive than any UI I ever used before or since, including MacOS X on 2017 hardware. Not true at all, the BeOS ui locked up plenty when using any real apps that is. GoBE office suite would slow BeOS and its ui to a crawl, Mozilla would too, a few IDEs that were around did too. Trying to do anything beyond dail-up networking was a joke. There are a few other apps that did slow BeOS as well but they escape me as I haven't really used BeOS in 15 years. BeOS was no more than a toy OS, I lost interest in it because Windows 2000, FreeBSD and Linux were more stable and just as fast on 2000-2004 era hardware.

acdha 9y ago
> Not true at all, the BeOS ui locked up plenty when using any real apps that is. GoBE office suite would slow BeOS and its ui to a crawl, Mozilla would too, a few IDEs that were around did too. That certainly doesn't match my experience: some apps like Mozilla could block their own window contents (but not window manager operations like moving or resizing) but the overall UI never blocked for anything except a video driver crash – and then only for a couple seconds as the kernel restarted that process. As an example, on a dual P-90 I could simultaneously stream video to disk from a FireWire camcorder (which was actually a real-time challenge on that minimally-buffered hardware which Win98 & OS/2 couldn't meet except with a completely idle system), compile Mozilla (which, IIRC, took about an hour), and not even notice the impact on my email and web browsing activity. Aggregate disk transfer performance would be slower but a good real-time scheduler meant that you didn't have huge lags while reading every small file. Windows and macOS still fail that test unless run with SSDs, and then only when e.g. Windows Update or the Xcode updates aren't running in the background.