3 ms·

> 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 wer

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

by zokula 9y ago

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.