Hacker News Reader

Comment by arp242 | Hacker News Reader

The core Wayland and X.org don't exist in a vacuum. I have written a lot of code over the years that works only on X, as have many others. I have not directly contributed to the X.org server, but have to the "wider X ecosystem". I will have to rewrite some of that. This is the case for many people.

View on HN

"I have not directly contributed to the X.org server, but have to the "wider X ecosystem". I will have to rewrite some of that. This is the case for many people."

This is a fair point, but the quality of Wayland isn't really at issue for this -- Wayland could be much better than X by all accounts and it would still require you to rewrite software for it. (Assuming XWayland doesn't suit your needs, anyway.)

Yes, but motivation and enthusiasm are important when it comes to spare time projects done by hobbyists.

You're far more likely to get people to expend the requisite time and effort if it's indisputable that the end result will be worth it.

    > it would still require you to rewrite software for it

As I understand, most complex apps in the 2020s are using something like Gtk or Qt. These already have Wayland rendering backends. (I assume other widget toolkits have done the same.) Unless your GUI directly uses Xt or Xlib, I don't think that any rewrite is required. Do I misunderstand your point?

A good part of why so may of us are cautious about Wayland is precisely that one or more of the things we rely on doesn’t support it. For example, my window manager doesn’t. I use that window manager every single day, and there is nothing out there which works the way it does. It’s a vital part of my workflow.

Does Wayland support the entire Xcompose system or an equally powerful alternative?

Wayland does genuinely sound interesting, if flaky and half-baked (it reminds me of systemd in that way). Certainly, the world doesn’t owe me a port of my window manager. But if the Wayland transition forces me to use GNOME then my life will be worse.

    > if flaky and half-baked (it reminds me of systemd in that way)

In 2025, is systemd still considered "flaky and half-baked"? As I understand, the "init.d war" was lost; systemd is the clear winner on Linux and continues to improve. That said, lots of good developers died on that hill.

Strongly disagree. For operating system components backwards compatibility should always be a primary and non-negotiable goal. If the backwards compatibility isn't 100% transparent that's a quality issue.

Reply on news.ycombinator.com