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