1. NOTE WL vs X

In the past few months there has been drama regarding Wayland vs X. It seems to be on everyone's minds after Artem's freakout issue and the follow up YT vids/comments.

I admit that it made me reconsider the fitness of WL as a whole - there was a github gist that made some scathing arguments against it.

It's an odd debate though. I think there are many misunderstandings.

So first off, if we look at the homepage https://wayland.freedesktop.org/, Wayland claims it is a replacement for X11. It now has manifest destiny, which in my opinion is a great shame.

X-pros seem to agree that Wayland has manifest destiny - like if you are building softwares that look remotely like a window system, it's a successor to X. That's the model of doing things and there's no way around it.

The disagreement starts with how this destiny - of an X2 - should be fulfilled. X-pros want a fork of X, but it's too late for that. WL-pros want X to run on top of Wayland compositor: https://wayland.freedesktop.org/xserver.html.

Xwayland is a problem for me. From the project description: 'if we're migrating away from X, it makes sense to have a good backwards compatibility story.' Full disclosure: I have never done significant work on Xwayland, so perhaps my opinion is unwarranted. But I have no intention of attempting to maintain a computer system that uses Wayland and X clients at the same time.

To me, X is ol' reliable. Every distro has first-class X support, and it runs on most systems with very little user intervention. Where it doesn't, there is 20+ years of dev history and battle-tested workarounds for you to find your solution in.

Wayland is the new kid on the block, born just in 2008. It's a fresh start to one of the most difficult challenges in software - window systems. A re-write would be pointless though, and so the real value-add is in design. Wayland is designed as a protocol and collection of libraries which are implemented in your own compositor. Coming from Lisp - with ANSI Common Lisp and SRFIs, this feels right even if the implementation is something very different (compositor vs compiler).

With X, it is assumed to be much harder to write an equivalent 'compositor'. Here's the thing though - with a significantly complex X client implementation, it is impossible to replicate in WL. This is really the crux of Artemi's argument in his issue. He asked for a 1:1 equivalent X/WL comparison when no such thing exists, and in my opinion it is a waste of time.

The WL core team is fully aware of this dichotomy, but also that this is in no way a problem or weakness in either system. It means they're different systems, goddammit.

If it was up to me, Xwayland wouldn't exist. I understand why it does, and that it does make things easier for developers who need to support both, and users who have multiple apps with multiple windowing requirements. It's a bandaid though, and one that is particularly dangerous because it re-enforces the idea that Wayland is just X2 and that they're fully compatible.

What interests me in the Wayland world right now is the idea of a small, modular, full-stack Wayland compositor API. There are several 'kiosk' based compositors for single applications (cage), but these aren't complete solutions. It is possible to get much closer to the metal, and that's where I want to be so that I can build my own APIs on top - I don't want to live on top of X, and I certainly don't want to live on top of X on top of WL. I want a pure solution that hides as little as possible, exposing the interesting bits.