One of the more amazing bits of technology in Windows is that which allows the graphics drivers to crash and restart without taking down the system. They've spent so long fighting buggy third parties that this is the solution.

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.

I have been quite impressed with VS Code. I’m....honestly shocked I’m using it but it’s doing what it advertises and is doing it pretty well. Sublime is getting less use these days.

Memory consumption and speed are apparently not important for you then, and that's fair enough. To each their own. I can only use so many resource hogs before my laptop says no. It starts with battery life and memory consumption. Speed (and benchmarks) is a good early warning sign.

I only use it because it is the best Rust experience on GNU/Linux and I am not willing to pay for CLion just for the debugger.

For everything else I do use native editors.

Tip: when X hangs, press Ctrl-Alt-F1 or F2 to switch to console mode, then Ctrl-Alt-F7 (or F8 on some distros) to go back to X. While in terminal mode you can investigate which process is reponsible for the X issue (high CPU? memory? disk I/O?) If that does not fix it, Ctrl-Alt-Backspace will kill X and every X application and you won't have to reboot.

That only works if console mode and X escape keys are configured.

Which is usually not the case on desktop oriented distributions.

X escape is usually not configured, but personally i haven't seen any desktop distribution to disable virtual terminals. Regardless, even if that is the case, it only takes a single PC restart for you to notice that the terminals are disabled and enabled them back so next time you need them they'll be there.

Yep, now explain that to a regular macOS/Windows user.