2
|
1
|
#+setupfile: ../clean.theme |
0
|
2
|
* NOTE WL vs X |
|
3
|
:LOGBOOK: |
|
4
|
- State "NOTE" from [2024-02-18 Sun 11:55] |
|
5
|
:END: |
|
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. |
|
9
|
|
|
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. |
|
12
|
|
|
13
|
It's an odd debate though. I think there are many misunderstandings. |
|
14
|
|
|
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 |
|
18
|
shame. |
|
19
|
|
|
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 |
|
23
|
around it. |
|
24
|
|
|
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. |
|
29
|
|
|
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. |
|
36
|
|
|
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. |
|
41
|
|
|
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). |
|
50
|
|
|
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. |
|
57
|
|
|
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. |
|
61
|
|
|
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. |
|
68
|
|
|
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. |