The Linux Kernel Has Been Forcing Different Behavior For Processes Starting With "X"

[deusexmachina]

Still better than Wayland by far

[Developer12]

This is exactly the kind of thing Windows does, except microsoft is smarter about it.

Windows tests both the name and the hash of the executable against it's database before inserting a shim that alters behavior.

[justinkb]

I doubt there's anyone running bleeding edge kernels with old ass X userspace, so this shouldn't give too much issues

[Developer12]

Classic example of Linux-quality code.

I'd say the usual stuff about crap running in supervisor mode and microkernel multiserver systems being the way forward, but effort.

Microkernels are fun and all, but there's absolutely no property to them that prevents bad code like this. It could have just as easily been written into the GPU server.

[bug77]

Both are just protocols tho. X.org on the other hand is a particular implementation with (apparently) very poor code quality. Plus, pretty much unmaintained.

Long ago, you could make that distinction, yes. These days, X11 and X.org are used pretty much interchangeably.
The thing is, this unmaintained pile of poor quality code, not only works where Wayland implementations are still WiP, but it also does things Wayland doesn't because "it's not the compositor's job".

[archkde]

I don't think you realize the overwhelming amount of microkernels there are.
Redox is a microkernel. L4 is a microkernel. You don't have to make a microkernel at all, they exist in copious quantities. Did you write this post under some strange assumption that microkernels are entirely theoretical?
An OS is useless by itself, which is why nobody uses them. You need drivers, otherwise the OS is literally just a mundane abstraction with nothing to abstract. That's why nobody uses anything besides Linux and Windows, all the drivers are for those.
Your comment about why monolithic kernels are successful is also incredibly ignorant. Windows is a hybrid design based off a microkernel design but simplified for performance reasons. Linux just happened to be at the right place at the right time, it was actually inspired by Minix, a microkernel, but Linux was just more popular with hobbyists. Linux is also a hybrid design these days, so actually, there are no popular strictly monolithic OSes anymore.
The simple fact of the matter is, a microkernel is useless. It doesn't matter if critical OS drivers like the disk controller or USB stack crash. Either they hard crash the OS because they're in kernel mode, or they politely ask the OS to shut down because they're in usermode but still critical to the OS to actually do it's job (there are many usermode components in Windows that do this). The only thing that really needs to be in usermode is third party drivers, for stuff like graphics cards and printers, which both Windows and Linux do. That provides you all the stability you need, anything more than that is needlessly excessive and an unwarranted engineering effort.

Yeah, I don't want to write a microkernel for the sake of having a microkernel, you're right there are already options for that. I'd really love to try out some crazy ideas for IPC and drivers.

Also, I think more stuff can recover than you seem to imply in your post. USB stack crashes, no problem, it's like ripping out all USB devices at once and re-plugging them. TCP stack or the firewall crashes, nothing more than a small blip in the network connectivity. GPU driver crashes, screen flickers and then comes back, like it already does on Windows. In addition, a buffer overflow in the TCP stack is no longer able to execute arbitrary malware or install a rootkit. Not to mention that the buffer overflow wouldn't exist in the first place, because I'd write everything in memory-safe languages.

[karolherbst]

Yeah, I don't want to write a microkernel for the sake of having a microkernel, you're right there are already options for that. I'd really love to try out some crazy ideas for IPC and drivers.

Also, I think more stuff can recover than you seem to imply in your post. USB stack crashes, no problem, it's like ripping out all USB devices at once and re-plugging them. TCP stack or the firewall crashes, nothing more than a small blip in the network connectivity. GPU driver crashes, screen flickers and then comes back, like it already does on Windows. In addition, a buffer overflow in the TCP stack is no longer able to execute arbitrary malware or install a rootkit. Not to mention that the buffer overflow wouldn't exist in the first place, because I'd write everything in memory-safe languages.

If it only were this simple...

[openminded]

Looks like a thing mirmirmir or AlexMitter would do right?

[justinkb]

If you are a) writing a program and b) need to use this atomic capability and c) absolutely have to have a process name starting with X for some absurd reason, there is a workaround by using 2 for the request value in the drm capability setting function for atomic cap

[sinepgib]

Yeah, I don't want to write a microkernel for the sake of having a microkernel, you're right there are already options for that. I'd really love to try out some crazy ideas for IPC and drivers.

If you actually have those ideas you can probably program, it's a matter of time (not that it's easy to find the time really). You may use an existing microkernel as a base.

Also, I think more stuff can recover than you seem to imply in your post. USB stack crashes, no problem, it's like ripping out all USB devices at once and re-plugging them.

This is a bad example IMO. You would need to make sure to reap references to the USB stack from other places. Think your VFS server that thinks there's still a pendrive connected. It's not really trivial to handle I think.

TCP stack or the firewall crashes, nothing more than a small blip in the network connectivity. GPU driver crashes, screen flickers and then comes back, like it already does on Windows. In addition, a buffer overflow in the TCP stack is no longer able to execute arbitrary malware or install a rootkit.

These are much better examples as their functionality is much more self-contained (and there are actual user space implementations able to run on Linux IIRC, check out lwip).

Not to mention that the buffer overflow wouldn't exist in the first place, because I'd write everything in memory-safe languages.

OK, but for this part it doesn't matter whether your design is monolithic or not.