Meanwhile, an Amiga with a half meg of RAM and a 7 to 25 MHz processor never fails to respond instantly to user input unless it's totally hosed.
We seem to have forgotten this very fundamental principle: the user's desires, expressed through input, are paramount for a desktop OS, which means that the OS must be designed from the ground up to respond to input at a very high priority. Mainframe operating systems like Unix (incl. Linux) and NT do not have this critical bit of forethought. Haiku probably does, and I think macOS might, especially on Apple Silicon.
The comparison might not be equal in terms of how much they’re doing, but the Amiga was doing it on a single core CPU, so it could quite literally only do one thing at a time.
A modern OS running on a multi-core CPU has even less reason to hang - one of the cores should always be available to immediately switch context to handle UI events, even if the other cores are running a million processes. There’s no -technical- reason for it to hang, just poor programming.
Edit: Upvoted because despite disagreeing, your comment seems to have sparked a ton of discussion, and that's always great. :)
One important difference was that AmigaOS bumped the priority of threads that dealt with user input - the user always had priority over other tasks.
Somehow this simple trick seems to have been forgotten or is ignored in modern OS development - or if modern operating systems still do this, their process schedulers seem to be pretty terrible at handling priorities.
<< The diff is the amiga is doing maybe three things total.
This is indeed the crux of the problem. Windows Start is trying to do everything at once including guessing what the user may be thinking of wanting including, but not limited to semi-random bing searches. Some would argue that less is more.
However, this is not a popular opinion these days. User is assumed to be an idiot and to not know what they want. As a result, MS menu does 3000 things as opposed to 3 Amiga did.
The way this is implemented in Windows seems to be fundamentally broken though, because when my laptop is busy compiling in Visual Studio, I cannot even scroll UI views with the touchpad - exactly this would never happen on an Amiga, no matter how many things it does at the same time (my uneducated guess is that the touchpad driver - or any other thread related to input processing - isn't priority-boosted as well).
To be fair Linux DE's all seem to have this problem too, so it's at least decently hard. I really wish it had some interest in the desktop space: no matter how loaded up my system gets, with what type of storage subsystem. there should never be a reason that my environment stops responding to user inputs.
As it is, it seems like a ton of stuff is done in the "yeah we'll just mmap and let the kernel sort it out" which is absolutely the wrong approach for UI.
Fucsia's kernel (Zircon) is hard real-time I think, which is what you want if you value predictability and low latency over all else.
Though you don't need an RTOS to make a responsive app, of course. It's just there's such a tendency for systems to bloat and become a tangled mess of RPCs and process activations, while using an RTOS tends to tie your hands and keep you from getting into such a mess.
The thing that's a bummer with deprioritizing performance is it makes people less willing to experiment/try things/dabble. With immediate response times there's no cost to saying hell with it and searching for other possibilities in the start menu (as an example related to this). Instead we just do what we've always done because we have to wait for far too long.
The desires of the user cease to matter by the time they have purchased the product. After someone has purchased a computer, wishing it were faster is a very expensive item to action.
MacOS has a system for adjusting process priority based on what the user is doing. Whatever program is in the foreground is high-priority, and any programs that it calls with blocking mach-port-based IPC are temporarily promoted to the same priority. This helps quite a bit with responsiveness!
We seem to have forgotten this very fundamental principle: the user's desires, expressed through input, are paramount for a desktop OS, which means that the OS must be designed from the ground up to respond to input at a very high priority. Mainframe operating systems like Unix (incl. Linux) and NT do not have this critical bit of forethought. Haiku probably does, and I think macOS might, especially on Apple Silicon.