Hard real time implies that you get to choose what runs and when. It allows you to treat user input and output (arguably the most important aspect of using a computer) as a high priority affair and to guarantee that the user will never have to wait for their computer to respond to them. If there is one thing that irritates me about modern day computing then it is that it is in many ways slower (in spite of having 100 times the clock speed of a machine from the early 90's) than the box I had on my desk back then (which was running QnX).
There are exactly zero reasons why this is the case other than a stupid ego war between Andrew Tanenbaum and Linus Torvalds who was gung-ho on recreating an OS from the 70's.
If there is one thing that irritates me about modern day computing then it is that it is in many ways slower (in spite of having 100 times the clock speed of a machine from the early 90's) than the box I had on my desk back then
This irritates me as well, but blaming it on the kernel strikes me as absurd. Blame it on all the layers of abstraction and general lack of caring in applications instead.
It's true that there are cases where the Linux scheduler gets in the way of a good desktop experience, but desktop latency is too high even when the scheduler isn't a bottleneck. And if anything, good scheduling gets harder in a microkernel, not easier, because you have less insight into what is going on at a system level. (Ultimately, the distinction simply shouldn't matter though -- not for desktop experiences, that is.)
But that's just wrong. There are a lot of reasons for those input delays that have absolutely nothing to do with the kernel. A bloated Electron app will not suddenly be blazing fast just because it runs on a real-time kernel. The true issues with the modern software stack lie in userspace.
You are missing the point entirely, but that's fine, I don't have the time right now to debate this to the point where you will understand. But unless you have used a microkernel based OS with a desktop interface (and chances are that you haven't) it is probably better to try to find access to something like that first (say an older single disk QnX installation) and play around with it for a bit to understand what I'm getting at.
Yes, there are plenty of problems in user space. But those are not the root cause and without addressing the root cause you will not be able to solve the problem even if you don't have bloated software.
While I agree that hard real time is desirable, it isn't necessary for responsive interfaces. Plenty of older, comprehensive operating systems managed to be responsive without it, BeOS and the Amiga being examples.
Both BeOS and Amiga took a lot of leaves out of the book of realtime and their schedulers were top notch. So 80% there I would say. But to be able to have user processes with real time guarantees makes so many applications easier to write. For instance video players, midi sequencers, real time audio processing and so on. Right now we rely on ridiculously long buffers to ensure that we never run out of data but on a real time OS you could do this with minimal latency.
There are exactly zero reasons why this is the case other than a stupid ego war between Andrew Tanenbaum and Linus Torvalds who was gung-ho on recreating an OS from the 70's.