One thing I love about debugging on Windows is that a program being debugged cannot grab the mouse and keyboard. On Linux, if you break a program that has a context menu open, you can say goodbye to your ability to interact with the PC.

You can enable grab break actions with "setxkbmap -option grab:break_actions" and then use Ctrl+Alt+KP/ to break grabs and Ctrl+Alt+KP* to kill the applications with grabs (note that setxkbmap -option blah adds the blah option to the existing options, which might interfere with this - you can try and reset all options by typing just "setxkbmap -option" without a parameter and then typing "setxkbmap -option grab:break_actions").

This is useful both when debugging and when dealing with broken applications.

I believe this is one of things that Wayland fixes. (Unless, of course, neither your debugger and application support Wayland natively and they both end up running in XWayland.)

QnX did that in ... 1983.

I too remember the QnX demo disk with a web browser and desktop environment on a single floppy. But Linux still doesn't do this kind of isolation, partly due to philosophical opposition.

Edit for the audience: http://toastytech.com/guis/qnxdemo.html

In the famous Torvalds - Tanenbaum discussion Torvalds got it terribly wrong, but Linux was good enough to get off the ground anyway so in the longer term might made right. But a microkernel based Linux would have been a serious game changer rather than a re-run. After all we already had plenty of free Unixes back then, and the descendants of those are all still more or less alive today.

The major sticking point in that whole discussion is that Tanenbaum may have been right in principle but Minix was not a very good illustration of what a micro kernel could look like. QnX on the other hand was awesome and to this day powers a very large chunk of the embedded sphere.

Tanenbaum was certainly right, given the adoption of micro-kernel like architectures across the industry, specially on embedded.

Even containers are a kind of workaround for achieving the same goals.

I still have a clone of 32 bit QnX sitting on my harddrive, maybe one day I'll have enough time and energy to attempt to port it to x64 and/or Arm 64.

I'm not sure comparing an RTOS to a really old school monolithic kernal is fair. Windows wasn't designed to be like QnX. I really wish QnX was open source though and had a thriving community behind it.

It's perfectly fair. QnX had a fully functional desktop environment and a large chunk of functionality that experimental OS's like Plan9 popularized.

Whether or not Windows as designed to be like QnX is immaterial, the question is what would be the better OS to serve as the engine behind a computer interacting with its users and my vote definitely goes to a real time operating system using a micro kernel. Because in my opinion that's by far the best match for that workload.

Stability, speed of interaction driver isolation and so on are much much better when using something like QnX vs a monolith. And a GUI is a real time affair.