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

[anarki2]

I'm not a C dev, but doesn't

 && req->value == 1

mean that only a process named "X" would enter in this condition?

No.

I'm not saying it's not a questionable solution, but if it's true then maybe it didn't affect as many processes as they thought.

It doesn't matter if it "only" broke sometimes, it's just bad logic. Process naming patterns shouldn't be used to determine application behavior, period.

[anarki2]

How is the kernel having a bad workaround for supposedly depreciated software the fault of the depreciated software and not the fault of the kernel? How is this even Xorg vs Wayland?

It's X's fault because we need kernel workarounds for X's shortcomings. Because X is unmaintained. And Wayland isn't. That's how.

[sinepgib]

Linux is also a hybrid design these days, so actually, there are no popular strictly monolithic OSes anymore.

What do you mean with Linux being hybrid? Everything in Linux runs at the same address space AFAIK, isn't that pretty much monolithic?

It doesn't matter if critical OS drivers like the disk controller or USB stack crash.

For a kernel driver crashing is really just a best case scenario. Misbehaving code can corrupt memory which can in turn end up modifying the filesystem, among other things. Microkernels, ideally, reduce how much harm memory corruption can cause.

[furtadopires]

no, it does not mean anything of the sort, this isn't a check on the length of the process name or something? req->value is an unsigned 64-bit integer value that corresponds to the value to set for the capability, in this case the atomic cap. it can only be 0 (incapable) or 1 (capable). the "&& req->value == 1" simply makes it so the function errors out with -EOPNOTSUPP and a info message if atomic cap is trying to be enabled for these X* processes. there is no issue if the function is trying to set atomic cap off, so then it doesn't need to error out and print that message. only the first character of the process name is checked.

Thanks for the explanation. Again I'm not a C developer so I thought this was a length validation.

[bug77]

It's X's fault because we need kernel workarounds for X's shortcomings. Because X is unmaintained. And Wayland isn't. That's how.

I think the most amazing part of Wayland is that it's a replacement for X, when X has shortcomings, but it is "just a protocol" when the shortcomings are in Wayland.
But really, off-topic at post #1, how rare is that? Oh, wait...

[Weasel]

If this is true:
0. You learn something interesting every day.
1. A certain company will soon have to resort to non-printable ascii characters for versioning. They have already used '1', '2', '3', '7', '8', '9', 'M', 'N', 'V' and 'X'. Maybe I am still forgetting something. I would love to see them name a version "beep" (not the word, the sound)...

I don't think apps written for Windows 10 will ever only look at the first character. So at least until Windows 20 they're safe.

20 could be a problem though, with Windows 2000 and all.

[sinepgib]

I think the most amazing part of Wayland is that it's a replacement for X, when X has shortcoming, but it is "just a protocol" when the shortcomings are in Wayland.
But really, off-topic at post #1, how rare is that? Oh, wait...

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.

[mdedetrich]

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.

Linux is actually closer to the "monolithic" kernel side of things rather than a hybrid kernel. This is because the only guarantee that Linux has for not breaking is user space sys calls, which is a must smaller scope than something like Windows. For example Windows has a stable ABI for graphics drivers with backwards and forwards compatibility which is what allows you to install newer graphics drivers on older windows (all they way up until Vista) and older graphics driver's on newer windows. This is much closer to a microkernel (at least if you treat the ABI as message passing) where as Linux has no such thing, DKMS only works for a single stable Linux release.

This is also the same reason why when a new graphics card comes out (i.e. right now with the new Radeon series) you have to get the latest Kernel (in this case 6.2) to have support for the graphics card. On windows you can just install the newest driver on whatever version of Windows you happen to be using as long as its not ancient (i.e. pre Vista).

[furtadopires]

No.

I'll wait the movie about this detailed explanation.

It doesn't matter if it "only" broke sometimes, it's just bad logic. Process naming patterns shouldn't be used to determine application behavior, period.

Hence why I've said

I'm not saying it's not a questionable solution

justinkb already gave me a explanation about the

req->value

parameter, so now I understand why it can affect any process starting with "X"

[Weasel]

It's X's fault because we need kernel workarounds for X's shortcomings. Because X is unmaintained. And Wayland isn't. That's how.

Yeah it's so unmaintained that this was fixed 3 years ago in Xorg.

Even says so in the article, nice reading skills. Wayland is church for a bunch of clowns as always.

You're probably going to ask so what's this hack for, then?

Well newsflash, it's called old versions of Xorg. No matter how maintained a software is, the old version will remain broken, unless fixes are backported. Wayland is not immune to this. Dumbass.