Other people mentioned the real preemptive scheduling — and the general overall better worst-case latency — but another factor was the clean design. The other operating systems tended to be okay in the absence of I/O content but once you hit the capacity of your hard drive you would find out that e.g. clicking a menu in your X11 app did a bunch of small file I/O in the background which would normally be cached but had been pushed out, etc. A common mitigation factor in that era was having separate drives for the operating system, home directory, and data so you could at least avoid contention for the few hundred IOPs a drive could sustain.

Bear in mind that resolutions back then were much lower than now, and not all computers had 24 bit color frame buffers. Video cards ran one monitor for the most part, with no others attached.

Be had well written multi threading and preemptive multitasking implemented on a clean slate - no compatibility hacks required. That meant it worked well and was quick/responsive. There were still limits, and the OS didn't have many security protections that would get written in today.

I think it was their thread/process scheduler. It had a section of priorities which got hard realtime scheduling, then lower priority stuff got more "traditional" scheduling. (Alas, I don't know too much about thread/process scheduling so the details elude me.) That way the playback threads (and also other UI threads such as the window system) got the timeslices they needed.

Real pre-emptive multitasking? I seem to recall that was one of the huge differentiating factors of it against Mac / Windows.

> without crashing like Windows

That depended _very_ heavily on your graphics card at the time. In 2001, I could get X to crash on my work computer if I shook my mouse too fast. At home on my matrox card, yes, it was rock stable.

High definition playback is still not as smooth as it could be in browsers on Linux (or if your CPU is fast enough, it will drain your battery more quickly), because most browsers only have experimental support for video acceleration.

https://wiki.archlinux.org/index.php/Hardware_video_accelera...

In 2001 I could still hang X Windows as much as I liked.

And it still happens occasionally, while my Windows 10 userspace drivers just reinitialize instead of locking the OS.

Linux could do that only if your system was lightly loaded. Once you started to have I/O contention, none of the available kernel schedulers could reliably avoid stuttering.

I had this experience too, my video card was so shitty that I wasn't able to watch 700mb divx videos in windows, I had to boot into linux and use mplayer.

Don't forget about xanim

Windows 2000 was rock solid stable with uptime measured in "how long do I keep running before I get bored if bragging about my uptime?"

No comment in regards to the 9x line. ;)

This would be challenging with modern codecs using delta frames. The only way I can see it work is precomputing all frames from the preceeding keyframe. Doable, but decent effort for a fairly obscure feature.

But did video formats back then use delta frames?