[vidarh]

An X11 wm is childs play compared to a Wayland compositor. I have been eyeing River and various other Wayland options too, in case I find myself compelled to switch to Wayland at some point, but the sheer complexity of the Wayland side has held me back.

[bitwize]

Given that X11 is going away, the server (except for Xwayland) is unmaintained, and in a few years modern software just won't support it at all... the sooner you switch, the better.

[vidarh]

There are plenty of Wayland compositors that supports X backends, so app support for X is moot because 1) most of the apps I run are my own - the only thing I really depend on is browsers, and 2) once Chrome and Firefox abandons X entirely, and no other browsers based on their engines supports X, there are options to run them with a Wayland compositor with an X backend in "kiosk mode" that basically gives them a single window just like before.

So that leaves how long I will have a working X server, and frankly I suspect I'll have ended up writing a display server years before that becomes an issue (whether that'll be X or Wayland or a mix, who knows, but I doubt I'll be able to resist very long).

It's just not a concern that's anywhere near the top of my list (or the top 100 of my list)

[Vecr]

You can run an X window manager on a Wayland compositor, as you said the problem is when programs stop running on X at all.

[vidarh]

Well, no, even that isn't a problem, because you can run a Wayland compositor on X too.

E.g. I tested, and Firefox runs fine in Weston in kiosk mode w/X as the backend.

So even when Firefox drops X, it will still run on X as long as a single compositor with an X backend is still running.

[Vecr]

Great, my Firefox on Weston on i3 on XWayland on Gamescope idea is a go (when I get around to implementing it).

[vidarh]

The funny thing is in theory it might work reasonably well, as Weston at least uses the DRI3 extension to get the underlying X server to just pass the DRI filedescriptors up, so if the rest also supports it you'd in theory just get a game of passing the fds through multiple layers and then the client doing direct rendering via shared memory. Though in practice there's of course plenty of things that might go wrong.

[yjftsjthsd-h]

I go back and forth on this kind of thing; if the better option really is EOL, is it better to keep using it until it actually breaks, or is it better to take the pain up front? I don't have an actual answer in the general case, but on the bright side Xorg is still not dead even though the pro-Wayland crowd says so at every single opportunity; it has a nonzero number of maintainers, gets commits on a slow but regular cadence, and appears likely to continue working for the forseeable future. If we assume for a moment that the X server will really actually die when Red Hat stops maintaining it (questionable; the BSDs appear more attached to it than RH), that merely gives us until the end of RHEL 9 around 2032, which is far enough away that I feel comfortable not worrying about it.

Also, as sibling comment points out, a simple solution exists in the form of rootful xwayland; we can keep a working X11 environment and just swap out the actual rendering layer.

Or put differently: "Given that X11 is going away, the server (except for Xwayland) is unmaintained," just isn't true, and even if it was it wouldn't necessarily justify the claims you make on that basis.

[erik_seaberg]

A modern app needs to be able to run in datacenters and render on my GPU (whether desktop, laptop, tablet, or phone). That’s how and where our capacity is evolving.

If X dies, I assume we’re going to end up with Javascript or Wasm frontends to everything.

[vidarh]

Maybe you'll end up with those frontends. I won't. Part of the point for me with my rewrites of essential parts of my computing experience is that I control an increasing proportion of my stack, and that proportion will keep increasing.