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