3 ms·

> Ahhh, NeXT... probably the nicest environment/OS/machine that never took off.... That would be BeOS.

by _pmf_ 11y ago

qubex 11y ago
I'm so delighted to find somebody else who remembers BeOS.
- nickpsecurity 11y ago
  I regularly cite it as an alternative to mainstream desktops and example of a microkernel system that performed well. Here's a post with it and a bunch of other systems with excellent properties worth copying: https://news.ycombinator.com/item?id=10957020 https://news.ycombinator.com/item?id=10957020
  - buttershakes 11y ago
    I loved Beos. I still have R4 disks lying around, very nice system.
    - nickpsecurity 11y ago
      We were discussing microkernels vs monolithic recently with BeOS as example. Opponent believed compilation times and apps doing many file accesses (web server) should be really slow on such a system vs Linux or Windows. Did you do either of those on BeOS and alternatives? If so, what was your experience with that? Note: BeOS is a special case since the filesystem is a database. So it cant prove his point unless it has XFS or something. But still curious.
jernfrost 11y ago
I was a big BeOS fan back in the day, but honestly in retrospect I think NeXTStep was a more advance and better thought out system. BeOS went with C++ for GUI programming e.g. which is a terrible language to do GUIs in. I wasted about 10 years of my life doing GUI programming in C++, and any C++ solution which didn't totally suck essentially ended up duplicating in a crappy way what had already been figured out in Objective-C. BeOS approach to multithreading was really just a dead end. Nobody does multithreading that way anymore. NeXT also had a more sophisticated display system, based on 2D vector graphics. They had the bundle concept and a lot of other things which I think in sum made it a better system. What I liked about BeOS was the heavy use of the file system attributes, and the translators were you could just drop in a GIF translator and then all you graphics apps could suddenly read GIF images.
- nickpsecurity 11y ago
  "BeOS approach to multithreading was really just a dead end. Nobody does multithreading that way anymore." I was about to start digging up more on its multithreading due to interesting things I read in architecture documents. Not to mention their multimedia demos. Read lots of positive stuff with interesting tricks like "benaphores." So would you clarify why you think it was a bad design and why nobody will use it any more? And did their concurrency or other design efforts get anything right in your eyes?
  - rvense 11y ago
    I programmed for BeOS a little (mostly before I really understood programming, though), and what I remember is just the shear number of threads. Each window (maybe even subregions of windows, don't remember) would spawn two, I think. You'd have to lock to do the simplest things. A lot of rote, manual management of shared mutable state.
    - nickpsecurity 11y ago
      I got you. So it's not tge architecture or how threading worked under hood but the developer experience the API's forced was bad? Right? That could be fixed easily in a knockoff.

> Ahhh, NeXT... probably the nicest environment/OS/machine that never took off.... That would be BeOS.

by _pmf_ 11y ago

> Ahhh, NeXT... probably the nicest environment/OS/machine that never took off.... That would be BeOS.

qubex 11y ago

I'm so delighted to find somebody else who remembers BeOS.

nickpsecurity 11y ago
I regularly cite it as an alternative to mainstream desktops and example of a microkernel system that performed well. Here's a post with it and a bunch of other systems with excellent properties worth copying: https://news.ycombinator.com/item?id=10957020 https://news.ycombinator.com/item?id=10957020
- buttershakes 11y ago
  I loved Beos. I still have R4 disks lying around, very nice system.
  - nickpsecurity 11y ago
    We were discussing microkernels vs monolithic recently with BeOS as example. Opponent believed compilation times and apps doing many file accesses (web server) should be really slow on such a system vs Linux or Windows. Did you do either of those on BeOS and alternatives? If so, what was your experience with that? Note: BeOS is a special case since the filesystem is a database. So it cant prove his point unless it has XFS or something. But still curious.

jernfrost 11y ago

I was a big BeOS fan back in the day, but honestly in retrospect I think NeXTStep was a more advance and better thought out system. BeOS went with C++ for GUI programming e.g. which is a terrible language to do GUIs in. I wasted about 10 years of my life doing GUI programming in C++, and any C++ solution which didn't totally suck essentially ended up duplicating in a crappy way what had already been figured out in Objective-C. BeOS approach to multithreading was really just a dead end. Nobody does multithreading that way anymore. NeXT also had a more sophisticated display system, based on 2D vector graphics. They had the bundle concept and a lot of other things which I think in sum made it a better system. What I liked about BeOS was the heavy use of the file system attributes, and the translators were you could just drop in a GIF translator and then all you graphics apps could suddenly read GIF images.

nickpsecurity 11y ago
"BeOS approach to multithreading was really just a dead end. Nobody does multithreading that way anymore." I was about to start digging up more on its multithreading due to interesting things I read in architecture documents. Not to mention their multimedia demos. Read lots of positive stuff with interesting tricks like "benaphores." So would you clarify why you think it was a bad design and why nobody will use it any more? And did their concurrency or other design efforts get anything right in your eyes?
- rvense 11y ago
  I programmed for BeOS a little (mostly before I really understood programming, though), and what I remember is just the shear number of threads. Each window (maybe even subregions of windows, don't remember) would spawn two, I think. You'd have to lock to do the simplest things. A lot of rote, manual management of shared mutable state.
  - nickpsecurity 11y ago
    I got you. So it's not tge architecture or how threading worked under hood but the developer experience the API's forced was bad? Right? That could be fixed easily in a knockoff.