X Window System Turns 38 Years Old

[Old Grouch]

JustK
Thank you for the optimistic viewpoint.
I've never been a display system programmer, but I have used the X Window System for a long time (I don't care to say how long), and I'm still learning.

[JustK]

Old Grouch
In case of the X server, relevant functionality has long been pulled out of it (KMS/DRM, libpciaccess*, libinput), what's still usable is still used under wayland (libxkbcommon). Modern apps barely interact with X directly anyway, they use toolkits like GTK or Qt, which in turn don't touch X drawing APIs, they merely push rendered images to X so in can compose the screen. And guess how X does that, right it passes it to a compositing manager and gets the final image back, which it then passes to the kernel.

*To you remember the time when X used to run as root to read through /dev/mem to find PCI IDs of video cards? Those were the days.

But fear not! Xorg won't disappear any time soon and valid use-cases will get a wayland implementation one way or another.

[MorrisS.]

Is it no more simple to make a new operating system based on pure Wayland?

[Old Grouch]

Until enough of the needed functionality found within current implementations of the X Window System can be replicated using Wayland, possibly, or even probably, with additional software to fill the gaps between the Wayland architecture and the X Window System implementation (with all it's 'cruft' (1)), Wayland will remain unused by a group of people. The Wayland architecture might well be 'better', having benefited from several decades of experience with display software, but people with entirely valid use-cases not covered by Wayland are going to be unhappy. The best way of dealing with that it to encourage the development of solutions to cover the use-cases excluded from Wayland.

There will of course, be things that Wayland can't do. Just like LED lamps can't do some thing candles can: like conveniently heat sterilize a needle. We still have candles. The X Window System will be around for as long as it is useful enough for people to motivate them to organize the resources needed to keep maintaining it while everything else changes around it.


(1)'cruft': remember, cruft is there because it was useful to somebody at some time.

Joel on Software: April 6, 2000 by Joel Spolsky: Things You Should Never Do, Part I

The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they’ve been fixed. There’s nothing wrong with it. It doesn’t acquire bugs just by sitting around on your hard drive. Au contraire, baby! Is software supposed to be like an old Dodge Dart, that rusts just sitting in the garage? Is software like a teddy bear that’s kind of gross if it’s not made out of all new material?
...
Each of these bugs took weeks of real-world usage before they were found. The programmer might have spent a couple of days reproducing the bug in the lab and fixing it. If it’s like a lot of bugs, the fix might be one line of code, or it might even be a couple of characters, but a lot of work and time went into those two characters.

When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work.

[theriddick]

Wayland is a better way of handling things (similar to how windows does with userspace stuff I guess).

Unfortunately I've never had much luck in wayland, lots of issues still. Maybe 2030? maybe...

[jacob]

Because some of these features allowed us to easily boost our productivity.

But many of those features are like GOTO in programming languages. Yes, it's quick, easy and convenient in various situations but that doesn't make it a good thing. It also doesn't mean that branching is prohibited, but that it should be done right. Similarly, those features will be supported (most of them already are) through purposefully designed APIs like pipewire and compositor extensions.

[JustK]

...
The Wayland approach looks interesting, but anything that starts off with a chmod 777 disturbs my security hinky sense.

As for the throwaway comment: it is not for managing profiles, although it could be used for that with some security advantages; I just used it as an example. It is very useful to have multiple user accounts throwing output up on a common display.

OK, I guess edit my example then to use ACLs in case people actually copy&paste it.
Thx archkde

[archkde]

Synergy and game devs are nobody then?

If it's not done via Wayland protocol, then at least there should be a standard way of doing it.... (AT-SPI2 is almost, but not 100% standard)

Games should not need any of the listed functionality. Synergy is indeed among one of the few developers that need to care about the implementation of such things. Apparently rkvm works with Wayland (but it's pretty much a hack as well, I agree that compositors should expose such functionality - but not in the display server protocol).

[archkde]

You remember it wrong. There was an issue with minimum system requirements and Intel cheating with their atrocious GPUs but that had nothing to do with Windows. WDDM worked perfectly and I don't remember any applications misbehaving due to it.

Sorry if I wasn't clear. I didn't mean to say WDDM is a bad thing in itself (in fact, it was probably one of the most important changes that ultimately made Windows better). Manufacturers dragging their feet on implementations was the problem from what I read (I have not experienced this myself, since the only Windows version before 8 I had to do with was XP).

Wayland on the other hand breaks almost everything: global shortcuts, systray, screen casting/recording, automation, etc. etc. etc. I remember they dragged for years the support for basic stuff like drag-n-drop and clipboard.

Global shortcuts, systray, screen recording and automation don't belong in a display server protocol, these are solved via DBus and Pipewire. Drag-and-drop and clipboard support being spotty until a year or so ago, I agree, but that's not the Wayland's fault either, just like the WDDM issues were not Microsoft's fault.

Lastly Windows 10 can work on a fucking rock which supports VESA 2.0 while Mutter/KWin won't even launch on that.

Wayland developers: "let's break everything and make sure you've got proper drivers or GTFO".

Nonsense again. As far as I know, the statement about Windows 10 is correct (although in practice, it would be unbearably slow on such a system), but at least KWin is supposed to be able to run in framebuffer mode as well.

[tildearrow]

You see, this argument will go nowhere. I can also say I can blow out a candle but not a lightbulb. What matters is having a usable desktop. Nobody except some developers need to care whether the resolution is set (or the window list retrieved) via Wayland or DBus.

Synergy and game devs are nobody then?

If it's not done via Wayland protocol, then at least there should be a standard way of doing it.... (AT-SPI2 is almost, but not 100% standard)