Hacker News Reader

Comment by bitwize | Hacker News Reader

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.

View on HN

Terrible comparison, Windows is still catching every one of those inputs and handling them. The diff is the amiga is doing maybe three things total.

This isn't even apples to oranges, it's apples to radish farm.

doesn't seem all that different to me, the user. how many things am i doing at once, really?

Why not run an amiga as your daily driver, then?

It's not comparing 'the things it's doing' it's comparing the UX. That's apples to apples. Begone radish farm.

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.

Eh. I disagree and agree at the same time.

<< 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 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. :)

https://learn.microsoft.com/en-us/windows/win32/procthread/p...

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.

I really wish BeOS has taken off. Personal computing has taken a real hit over the years.

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.

> Mainframe operating systems like Unix (incl. Linux) and NT do not

> I think macOS might

macOS is Unix. Specifically, it's a derivative of BSD.

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!

Reply on news.ycombinator.com