Then I encourage you to take up leadership to get some development going on the bare metal xorg server. Odds are, within a year or two, it will need serious patches to keep working with up to date kernels, mesa, and nvidia drivers.

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.

Not sure what have I missed but how is X window system a "friendly design"?

Friendly compared to Wayland. X Windows offers many features that the designers of Wayland decided to exclude to keep their protocol simple, and for some security theatre reasons. But this simplicity is deceptive, as it means that implementing all the excluded features, and deciding on relevant interfaces, is left to the Wayland compositors. This is the reason "Wayland" (or, more correctly, Wayland compositors) still miss many important features that are

* expected by users of X11, Windows, or Mac

* expected by power users

* needed by the visually impaired

And it is also the reason why the Wayland ecosystem is destined for horrible fragmentation of interfaces, features and implementations.

Another consequence is that the X11 model of having the possibility of easily making a window manager to one's liking is not possible with Wayland, as compositors are monstrous beasts compared to window managers.

I also wrote about all this in some of my previous comments, e.g. there was a large thread here: https://news.ycombinator.com/item?id=24886074

EDIT: there's another perspective to this that I didn't express very well, so here are some quotes from Arch BBS:

By user neosix:

> You can't send keystrokes, move mouse, move windows, you can't even get active window. And all that because of security?

> But guess what it's not safe walking down the street, something can kill you, so let's just stay in the house and never go out again :)

By user Trilby:

> While I place a very high value on security and well designed software, the strategy of saying "you shouldn't want to do that" is not a sane policy. Yet this has been the approach of wayland from the start. Can you have a system panel? No, you should not want to have one. Can you have one client talk to another client? No, you should not want to do this. Can you turn on your computer and do anything even remotely productive with it? No, you should not want to be productive: here, watch a cat video.

Emphasis mine.

That's not a Wayland problem. The features you're asking for are probably still there but they're implemented at a different spot in the stack instead of trying to stuff everything into the same protocol like in X11. This is actually done to reduce fragmentation. Make a service its own daemon with a dbus interface or something like that, and then it can run the same on X or on any Wayland compositor.

In my experience it's actually the simplicity of building window managers in X11 that's misleading. It's easy to get something up and running that lets you move windows around, but to build a full desktop that does everything you'd expect is a giant task, and X11 only really gets in the way of that.

> That's not a Wayland problem.

Exactly, "not a Wayland problem". That's the problem with Wayland, nothing is a Wayland problem.

> Make a service its own daemon with a dbus interface or something like that

I don't know if I should cry or laugh at this.

Not sure why you'd laugh or cry. Dbus is just an example. You can use another mechanism to build another daemon, it doesn't have to be built on anything in particular. I'm just saying, if you expect that Wayland is going to solve every problem you had with your desktop, you're setting yourself up to be disappointed. It solves a few specific problems. You can solve the other problems in ways that reduce fragmentation, but you'll have to look in other places.

> solve the other problems in ways that reduce fragmentation

> look in other places

There's a contradiction here. How do you expect to avoid fragmentation if adding additional protocols alongside Wayland is required? I mean, obviously there won't be just one protocol. This idea is actually a common joke, there's even an XKCD on the topic.

You misunderstand. In both situations, you're making a new protocol. The only difference is you'd be making your own thing instead of adding new packet types to Wayland. And why add new packet types to Wayland if the thing you're trying to do can be done outside the Wayland socket? Best example is Pipewire and screensharing. People ask for screensharing in Wayland but it makes a lot more sense to have it in Pipewire because it can handle all the other tasks related to video streaming like format negotiation and compression. It works headless and independent of any compositor, the fact that it can also be used to do screensharing is a benefit of its design.

> Can you have a system panel? No, you should not want to have one.

Yes you can, wlroots has an extension for that, that will work on every “niche” wm based on it. You could not really get a system panel to work on plasma and gnome as well on X.

> Can you have one client talk to another client?

It is way too vague (generally, what does it have to do with the display manager? Pipes, IPC, dbus), but if it means something like drag’n’drop, it is supported.

> Can you turn on your computer and do anything even remotely productive with it? No, you should not want to be productive

This is just utterly stupid.

> Yes you can, wlroots has an extension for that, [...]

Exactly my point.

Have you tried reading the rest of my comment? Reading may help you in other areas of life as well...

I read your entire comment. Be civil.

> Wayland compositors) still miss many important features that are

> * expected by users of X11, Windows, or Mac

Windows & Mac have been in a compositor-only world for over a decade now. They are firmly in a wayland-style world, not an X11-style one. Android, too, has only ever had a wayland-style world.

The only thing that exists like X11 is X11. So nobody on Windows or Mac will be expecting anything like it.

It's certainly much friendlier to write programs for.

Yeah, but why would anyone want to write programs? Oh, wait...