3 - State "NOTE" from [2024-02-18 Sun 11:55] 5 In the past few months there has been drama regarding Wayland vs X. It
6 seems to be on everyone's minds after Artem's freakout issue and the
7 follow up YT vids/comments.
9 I admit that it made me reconsider the fitness of WL as a whole -
10 there was a github gist that made some scathing arguments against it.
12 It's an odd debate though. I think there are many misunderstandings.
14 So first off, if we look at the homepage
15 https:
//wayland.freedesktop.org/, Wayland claims it is a replacement
16 for X11. It now has
/manifest destiny/, which in my opinion is a great
19 X-pros seem to agree that Wayland has
/manifest destiny/ - like if you
20 are building softwares that look remotely like a window system, it's a
21 successor to X. That's the model of doing things and there's no way
24 The disagreement starts with how this destiny - of an X2 - should be
25 fulfilled. X-pros want a fork of X, but it's too late for
26 that. WL-pros want X to run on top of Wayland compositor:
27 https://wayland.freedesktop.org/xserver.html.
29 Xwayland is a problem for me. From the project description: 'if we're
30 migrating away from X, it makes sense to have a good backwards
31 compatibility story.' Full disclosure: I have never done significant
32 work on Xwayland, so perhaps my opinion is unwarranted. But I have no
33 intention of attempting to maintain a computer system that uses
34 Wayland and X clients at the same time.
36 To me, X is ol' reliable. Every distro has first-class X support, and
37 it runs on most systems with very little user intervention. Where it
38 doesn't, there is 20+ years of dev history and battle-tested
39 workarounds for you to find your solution in.
41 Wayland is the new kid on the block, born just in 2008. It's a fresh
42 start to one of the most difficult challenges in software - window
43 systems. A re-write would be pointless though, and so the real
44 value-add is in design. Wayland is designed as a protocol and
45 collection of libraries which are implemented in your own
46 compositor. Coming from Lisp - with ANSI Common Lisp and SRFIs, this
47 feels right even if the implementation is something very different
48 (compositor vs compiler).
50 With X, it is assumed to be much harder to write an equivalent
51 'compositor'. Here's the thing though - with a significantly complex X
52 client implementation, it is
/impossible/ to replicate in WL. This is
53 really the crux of Artemi's argument in his issue. He asked for a 1:1
54 equivalent X/WL comparison when no such thing exists, and in my
55 opinion it is a waste of time.
57 The WL core team is fully aware of this dichotomy, but also that this
58 is in no way a problem or weakness in either system. It means they're
59 different systems, goddammit.
61 If it was up to me, Xwayland wouldn't exist. I understand why it does,
62 and that it does make things easier for developers who need to support
63 both, and users who have multiple apps with multiple windowing
64 requirements. It's a bandaid though, and one that is particularly
65 dangerous because it re-enforces the idea that Wayland is just X2 and
66 that they're fully compatible.
68 What interests me in the Wayland world right now is the idea of a
69 small, modular, full-stack Wayland compositor API. There are several
70 'kiosk' based compositors for single applications (cage), but these
71 aren't complete solutions. It is possible to get much closer to the
72 metal, and that's where I want to be so that I can build my own APIs
73 on top - I don't want to live on top of X, and I certainly don't want
74 to live on top of X on top of WL. I want a
/pure/ solution that hides
75 as little as possible, exposing the interesting bits.
