The kernels policy is not to break userspace and RHEL 8 which still supports X is 2 years into a 10 year support term.

Also nvidia still provides drivers for 18 year old hardware for x under solaris

If you want the current version built this year for Linux instead of the legacy version you will have to move up 2010 hardware though.

I find it quite amusing that proponents of insert technology here seem to come in 2 stripes.

A) Those who believe new thing is superior and think you ought to try it

B) People smugly stating that you must move to new thing because the other options are going away see wayland systemd gnome.

It reminds me of a supervisor at a telecom support center who gleefully explained that the new system would hang up on people who kept mashing zero on the automated phone menu that preceeded getting to a person to make you go through it.

He didn't understand that people didn't want to use the new automated process because in general such systems are crappy and confusing.

The kernel can choose to not support new hardware with old interfaces. If the X11 can't interface with new hardware, that's game over. No broken userspace necessary.

Choosing not to support said interfaces would be the biggest breakage of userspace in 3 decades of Linux history. Such a course of action is nowhere specified by the people who would be responsible. As best I can see you have constructed it from whole cloth from suppositions that seem to be ill considered.

Edit: To be clear breaking user space is when a change happens in the kernel level wherein software that used to work no longer works because the public interface presented differs. If you have evidence that this is actually going to happen other than your own misunderstandings please link it.

There is a lot of detail about this in the kernel docs: https://www.kernel.org/doc/html/latest/gpu/drm-uapi.html#ope...

The gist of it is that breakage is OK if the userspace isn't open-source and that new uAPIs come around every few years due to the rapid pace development of GPUs.

I worked on Chrome OS graphics for years on and one of my earliest projects was to bring DRM/KMS (then a newish interface) to the Cirrus display card (an ancient card that QEMU happens to emulate).

Does it specifically mention the kernel breaking X? One would think that would be the topic of discussion years before anyone actually did it.

I don't think the kernel guarantees that if X runs against Linux today, then it will run against the same X on new kernels on new hardware in perpetuity. It's more along the lines of, "if I one calls the read syscall with parameters a, b, c, it won't suddenly require a 4th parameter, or demand they be in a, c, b order."

Anyways, if the kernel developers decided they wanted to invent a brand new uAPI that does graphics, I wouldn't at all be surprised if new GPU drivers only implemented the new uAPI if their target userspace programs all use the new uAPI instead of an older uAPI. Nothing in userspace is "broken" because it will seem to the old uAPI using userspace as if there is no driver for the new GPU.

To be clear in the Wayland fetishists fantasies they wouldn't need to convince people to all switch to wayland circumstances would foreclose on any further debate in reality all players have an incentive to keep existing software working.

If one calls the _ syscall with parameters a b and c it won't suddenly require a 4th or demand they be in a c b order is literally what makes X11 continue working against newer kernels. Providing new functionality wherein if you don't call foo before calling _ with a b and c it fails to perform its function would be functionally the same as changing the order of parameters it would be breaking user space.

I don't see how you could possibly lawyer yourself past that, I don't see that the adults in the room who have to support customers in rhel 8 through 2029 can do anything but keep doing minimum work to keep x and the kernel playing nicely. I don't see how nvidia is going to go from supporting hardware for 10-18 years even on niche hardware to dropping support for X so quickly. I also don't see how you can meaningfully talk about the kernel dropping support for X without basing your discussion on actual kernel developers who logically would talk about kernel foo will be the last to support X probably years before it actually happens. I'm totally sure that python 2 -> 3 took over a decade after it was a completely suitable replacement but we will totally manage to replace X before its replacement is fully baked and the kinks worked out.

In short the whole premise is completely and totally premature wishful thinking by people who want their own way. I'll pour one out for X when its actually and in fact dead.

New software doesn’t get better just because it is new, but it is short-sighted to not evaluate (or evaluate on not enough context) a possibly better solution. The very people working on X decided to continue development on Wayland, do you think they would got with an inferior solution?

Yes, I do. I very much believe that the Wayland architectural decisions are motivated by non-technical reasons (look at who pays them, and who stands to benefit by controlling the majority of commits across the whole fd.o stack).

Well, you can imagine some evil behind everything if you wish..

Or just look at a technical video about it: https://www.youtube.com/watch?v=GWQh_DmDLKQ

I don’t see these conteos regarding linux, especially goddamn desktop with the minuscule user share. It is literally a hobby thing for some graphics enthusiasts without any sort of money. Yeah sure, red hat or whatever..

Except, I've seen this same exact song and dance routine played out already with systemd. Some RedHat developers make a thing no one wants to use, so they tightly couple many orthogonal concerns into one giant hairball, and they go on a road show to get a few crucial players (like GNOME and ConsoleKit, which was deprecated by the systemd devs) to hard-depend on it so distros have to choose between using the hairball or losing something that was entirely unrelated. It's a great play by RedHat, because now things are so interdependent that you need full-salaried developers working full-time on it, since the cognitive overhead required to understand how everything interacts now precludes a loosely-connected network of part-time volunteers from maintaining it themselves.

Oh, and this whole affair has the obnoxious side-effect of stirring up all the /r/linuxmasterrace dipshits into a feeding frenzy that spills over onto HN, where they scramble over themselves to spam everyone who dares disagree with the same half-assed links and excuses.

Or how about systemd actually providing features not found in its predecessors at all and it does solve system init and service life cycle management?

Do you think that the majority of the debian team that voted democratically multiple times on the issue voted purely because... Red Hat? Come on, it is ridiculous. I hope you are not as blind when it comes to real-life politics, because denying reality to this degree is dangerous.

You don't think that Debian choosing systemd had anything to do with things regarded as core components like gnome being tied to same and not wanting to maintain a fork of the same functionality?

Accusing the other side of an argument of being deluded doesn't foster useful discussion.

Interestingly enough the much smaller gentoo maintainers managed to package gnome without systemd..

It depends on dbus not systemd and that is replaceable module.

Just because you don't see the politics at work doesn't mean that it doesn't happen. Thanks for proving my point about /r/linuxmasterrace, btw.