Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

QNX and BeOS were the only operating systems I tried in the early '00s that could make old single-core mid-90s Pentiums feel excellent and snappy to use. Far, far better than any Windows version, or Linux.

I assume it's mostly scheduler stuff and much better multimedia stacks, in both cases. I always hoped the operating systems of the future would feel more like that. Closest we've got is probably iOS and it cheats by killing processes all the time. The future is lame.



BeOS was “pervasively” multithreaded, which in non marketing speak means the kernel did not have a giant lock (since it was designed as a many core system from day #1). Its contemporary OS’s at the time had a giant single lock. BeOS also had 750ms preemption interval (or was it 3ms, I dont remember) while Linux and Windows had 20ms, then later 10ms, so this is what you fealt. A couple of decades later and most OS’s matched the finer locking granuality in kernel space, minus the premption interval (argument being throughput vs latency, since scripted OS benchmarks measure overall throughput, not GUI responsiveness). A perfect example is media buffers that benefit from smaller buffer sizes, at the cost of less throughput. Musicians notice better responsiveness in BeOS, hence the monicker “Media OS”.

Also, in GUI space, the BeOS/Haiku app server still offers a more distributed workload compared to other desktop environments. Every windows is assigned its own thread, the app gets its own thread, and the app and application server have 1 thread per app and window to ensure they are not blocked waiting for slow app message parsing. So minimum BeOS app with graphical “Hello World” window is 4 threads. So even if the app is busy, the rest of the system still feels responsive.

All this comes at a throughput cost, as well as an app development complexity cost, especially for ported apps. Haiku needs to marshall Qt/Gtk/toolkit messages from many windows into a single message queue to prevent multithreaded bugs from popping up (since in their original environment, all app message loopers were not multithreaded). This marshalling needs additional lock/unlock calls in Haiku even when not needed (messages to same window).

Haiku native apps, on the other hand, are smooth as ice. See this screenshot of Medo video editor where all windows are working in their own threads (https://raw.githubusercontent.com/smallstepforman/Medo/refs/...). On modern systems, this app is smooth as ice, which for a video editor is heresy. Disclaimer: I wrote the linked Haiku app.


> BeOS also had 750ms preemption interval (or was it 3ms, I dont remember)

3ms vs almost a second is a pretty big difference...


I non-ironically dream for the day that a modern computer is as snappy booting as my old Commodore 128, as fast to reset, and as responsive to all keystrokes.


devuan on vbox boots ~2x slower than CCS64 under emulation. If you're talking about "to a desktop" or something, i don't do that, i just boot to a shell on devuan and COMMODORE 64 BASIC V2 on the CCS64


Just install FreeDOS on it :)


Although they’re cheating, I give them props for trying. I abandoned Android when even Samsung didn’t make an honest effort to make their phones responsive. It’s nice that Apple consistently values responsiveness because then Google, Samsung and Microsoft have some incentive to address their bloated products.


As someone also have used BeOS and OS/2 Warp, I miss the snappiness of old systems. (I never got my hands on QNX)

What OS nowadays is the closest to that snappiness? Haiku OS? (I'm a happy M1 Macbook user, but it sometimes feel note nough.)


I worked with QNX on a floppy and it was the first time, after years of Windows, Mac and DOS in the 90's, that something felt so magical.

Every OS has a delay between mouse click and impact on the UI. Only QNX has ever felt sub 30ms in response time.


>What OS nowadays is the closest to that snappiness? Haiku OS?

Probably Haiku running native Haiku apps.


FreeDOS, KolibriOS, maybe ReactOS.


I never ran QNX, but my experience with BeOS were similar to yours in that a Pentium 90 felt great!

Another data point:

SGI IRIX has an unusually good scheduler. I ran a 30Mhz machine for a while and it's desktop was pretty snappy.

One day, I compiled AMP and fed it a list of .mp3 files, most being 192kbps. The program could decode 256kbps without skipping, just FYI.

Those files were on an NFS share.

When I ran the gr_osview program, CPU was 95 percent utilized, and still the file manager was responsive and that music did not skip.

Frankly, just decoding higher bitrate > 192kbps mp3 files at 30Mhz was impressive.

Doing it with a full X Window system desktop, while playing he files off an NFS share, while remaining responsive speaks to a lean and mean network stack and scheduler that performed even on low spec hardware.

Was IRIX 5.3 FYI. Indigo Elan

A friend and I enjoyed operating systems and ran Be on an old Pentium 90, and like the parent comment says, it was snappy!

Linux also has a part in this:

After a water event, that Pentium 90 was no longer reliable. Used non parity RAM and Windows NT would go slowly senile eventually blue screening over and over.

For funzies, we put Red Hat 5.2 on that box and it ran fine! The syllog had a bunch of entries every second too. Open X console, and just watch them go by...

That box served up the company web page for a coupla weeks just for fun too.

Good times.


I feel sad that people don't remember OS/2 anymore. It was also able to run multiple dos windows, have video running in the background etc, and that was in the late 90's.


There is still ArcaOS[1] that can run OS/2 applications.

[1] https://www.arcanoae.com/arcaos/


I had OS/2 Warp 4 and it was one of the best pieces of software I ever had: from the box design to contents, included software and its quality; and even voice recognition.


iOS has very strict process/resource management because it wants to preserve both available RAM (for responsiveness) and your battery life. I wouldn't call it cheating (even in jest); it's a very deliberately and carefully designed feature of the OS.


Sure, and that's fair, but to me the "cheating" is more about how it is limited to only certain types of computing. On a Mac, or indeed any non-Apple OS since Windows 3.1, you've been able to for instance, start a long-running, resource-intensive process like encoding a video, minimize that window, and open say, Minesweeper or read a text file for an hour, all knowing that the OS wouldn't dare interfere with your background task. In iOS you can be assured that the moment you background an app, iOS can and will send something to kill it at any minute, and there's not even a way to explicitly allow a certain app to be immune from being killed, even on a one-time basis.

All of this is totally by design (and thinking only of phone handsets I'm sure some people would defend this), but it is maybe the #1 thing that prevents this otherwise capable hardware from being used for more things. (Not to mention how much it hamstrings iPad OS).


This was most certainly not the case when using CD burners in windows 9x. I remember my friend being afraid of even moving the mouse while burning a CD.


Yes, but that was actual contention for resources resulting in the CD-R drive's buffer not being filled in time to keep the write operation going.

That's quite different from the operating system choosing to shoot the CD writing software in the head because you looked away from it for a moment.


most people just want a phone, to check email, watch a youtube video, check tiktak, etc. they don't want to do serious computing on their phone. I'm in that crowd. I have more computers than you can throw a stick at, I don't need that out of my phone.


And yet I can't get more than a full days use out of it if I use the phone to read news during my commute etc.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: