The whole "Wayland breaks everything" post is a huge distraction.
One of the best ways to aid your "enemies" is to attack them with hastily-drawn conclusions, untested assumptions, and sheer stubbornnes.
#Wayland has some real problems, and so does #X11.
There are undeniably many scenarios* where the Wayland devs never thought to do something differently, or just refused to do so for reasons they believe to be rational and for the greater good.
Making a list of very low-level features and APIs that Wayland doesn't support is a waste of time. The only response you will get will be "We never wanted to support that," and the rest of your argument will fall on deaf ears.
Sadly, the article does have some cogent points about how Wayland was designed, but they're lost in the volume of noise about features that most people (even most neckbeards) aren't nearly as concerned about.
Thankfully, Wayland is growing and slowly getting better, although there are MANY annoyances to this day.
Forgive me for not actually constructing a useful list here. The simple truth of it is that I'm not an expert, and I'm not trying to construct a detailed polemic, but just an overall statement regarding the right approach to disagreements such as these.
@rl_dane@thelinuxEXP The post, as so many other anti-Wayland writings, comes from people wanting bug-for-bug compatibility. This was never about use cases. Wayland development is pretty open to new (and old) use cases (as long as you are nice about it). It's about people wanting things to work in exactly the same hacky, wild-west, screen-tearing way it has since the 90s.
Neither X or Wayland are perfect (I have used and written code for both). But unlike X, Wayland will improve.
Add comment