* NOTE WL vs X

 :LOGBOOK:

 - State "NOTE"       from              [2024-02-18 Sun 11:55]

 :END:

 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.