No, that has direct influence on all consumers of the products. These things aren't free. People are paying for Xorg to continue to work, and the people paying most are probably those maintainers who are telling you this is not sustainable. As a user of Xorg or Wayland, you are the recipient of the work of people who put effort into those products. If you want to pay the costs associated with maintaining your preferred solution, go ahead.
Maybe I'm getting the wrong message here, but it seems that the author is claiming to be the victim because other people won't pay for their preferred solution, so they attempt to shame the people who are paying.
I'd rather have a "dry" comparison between Wayland and Xorg in a variety of topics instead of all the vague stuff mentioned here. It'll be much better and more useful regardless of which system you prefer.
(and as someone who prefers Xorg i'd find it useful to see a state-of-the-art comparison in the areas where Xorg allegedly lacks to see if that is still the case, why that happens and possible improvements that could happen that go beyond a simple "make it better" - if nothing else, something more concrete may help someone just try and improve the program)
I finally got screensharing in chrome and firefox working on wayland with sway and pipewire.
So we now only have to wait for Electron 12 to reach stable and Teams and Slack to Update accordingly.
1. Change is hard. No one will write their program to support protocols that are not widely adopted in the first place. At the same time, no one will switch to wayland, if there are no or not enough applications supporting it.
In some transitioning state there will be a point where two protocols would have to be supported, if you want to serve your software (although for Wayland there are several workarounds to run X-applications in Wayland).
Also we are seeing some momentum finally and big desktops/distros adopt wayland as their default. So the boss battle you talked about seems over, as X.org will no longer be actively developed. Now it's the question how to smoothly transition.
2. I want everything to work out of the box and not care about the internals. ("Do Windows users care what Microsoft calls its own display manager? Do Mac users care about theirs? Android users? No one cares. They care that they can watch videos and play games.")
If you really only care about that, Mac might be a better choice for you. I enjoy linux because of it's transparency here and the opportunity to dig into some code, understand the internals and modify stuff to your liking. A sound protocol would be the basis for that.
There are still some reasons, why you should care: - If developing software is easier, you will obviously benefit in the long run. Especially with open source software. It will be easier to contribute to projects like window managers. - It's okay, if you don't care about DPI, but you do care if your hiDPI does not look good, which seems to be an issue for X.org in multi-monitor setups (which are quite common).
Personally, I am more surprised that the whole _let's replace X.org_ effort was such a niche project, although a sound window server is just such a fundamental aspect of a OS that supports GUIs. So you might rant about, why are there only one monolith and one possible alternative - and why do we have a fundamental part of the system which is so hard to replace and not abstracted by a more general protocol. The real critique that points to why getting wayland to work would point more to the past in my opinion.
In that regard it's also no surprise that it is taking so long. You realize that so many basic things (clipboard, screenshots, window managers) where directly bound to a specific display server because it allowed most things you wanted due to it's _wild_ freedom.
So for your wishes I think it goes like this: 1. Replace X.org with a sound protocol (I can only see Wayland) - getting rid of X.org and establish a protocol 2. Let's have competing protocols from there on, or let's just have the major interest in Wayland and developed it together. If we're over X.org, there will be a natural interest and hopefully development and adoption will be quicker from then on.
Starting with restrictive security and take the struggle of seeing how far you get is something, you as a user should appreciate. You talk about all the other security issues, but if all the other devs would also have that mindset, maybe things would work out to be more secure.
As security is mostly hidden from users (even techie users), I cannot support the statement _functionality > security_. Set security=0 and you're always on the right track?
For every feature where you have to sacrifice security, you should be able to give good reasons. A single security issue could make _all_ features of the program insecure.
In a good security model you will also be able to hand over permissions, so I expect Wayland to make it possible for me as a superuser to allow for some apps to have some permissions (like screenshot apps to access the rendering of other applications) or some apps to log your keystrokes - but once entering to a password field, Wayland could also take those permissions back... For all of these things, having a secure and restrictive starting point and work on from there is necessary.
P.S: I do not know the wayland protocol in detail, so I don't know if the right choices have been made. But I like that they did not chose the easier part of starting with: We need to support exactly the same as X.org does (which would probably lead to similar problems) but to make the window server part right and enforce other parts of the systems to change as well, where things are just not the job of the window server.
