Back in the day X was a great protocol that reflected the needs of the time.
- Applications asked it to draw some lines and text.
- It sent input events to applications.
People also wanted to customize how their windows were laid out more flexibly. So the window manager appeared. This would move all of your windows around for you and provide some global shortcuts for things.
Then graphics got more complicated. All of a sudden the simple drawing primitives of X weren't sufficient. Other than lines, text and rectangles applications wanted gradients, rounded corners and to display rich graphics. So now instead of using all of these fancy drawing APIs they were just uploading big bitmaps to the X server. At this point 1/3 of what the X server was previously doing became obsolete.
Next people wanted fancy effects and transparency (like drop shadows). So window managers started compositing the display. This is great but now they need more control than just moving windows around on the display in case they are warped, rendered somewhere slightly differently or on a different workspace. So now all input events go first from X to the window manager, then back to X, then to the application. Also output needs to be processed by the window manager, so it is sent from the client to X, then to the window manager, then the composited output is sent to X. So another 1/3 of what X was doing became obsolete.
So now what is the X server doing:
- Outputting the composited image to the display.
- Receiving input from input devices.
- Shuffling messages and graphics between the window manager and applications.
It turns out that 1 and 2 have got vastly simpler over the years, and can now basically be solved by a few libraries. 3 is just overhead (especially if you are trying to use X over a network because input and output need to make multiple round-trips each).
So 1 and 2 turned into libraries and 3 was just removed. Basically this made the X server disappear. Now the window manager just directly read input and displayed output usually using some common libraries.
Now removing the X server is a breaking change, so it was a great time to rethink a lot of decisions. Some of the highlights are:
- Accessing other applications information (output and input capture) requires explicit permission. This is a key piece to sandboxing applications.
- Organize the system around frames to avoid tearing except for when desired (X doesn't really have the concept of a frame).
- Remove lots of basically unused APIs like fonts, drawing and many others.
So the future is great. Simpler, faster, more secure and more extensible. However getting there takes time.
This was also slowed down by some people trying to resist some features that X had (such as applications being able to position themselves). And with a few examples like that it can be impossible to make a nice port of an application to Wayland. However over time these features are being added and these days most applications have good Wayland support.
https://xkcd.com/963/ (October 2011)
[Mouseover text] Thomas Jefferson thought that every law and every constitution should be torn down and rewritten from scratch every nineteen years--which means X is overdue.
Applications needs some coordination between each other in order to act like you would expect - things like one window at a time having focus and thus getting all keyboard and mouse inputs. As well as things like positioning on the screen and which screen to render to, the clipboard, and various others things.
X is a server and set of protocols that applications can implement to allow all this behaviour. X11 is the 11th version of the server and protocols. But X was also first created in 1984, and X11 since around 1987. Small changes have been made to X11 over the years but the last was in 2012.
Which makes it a very old protocol - and one which is showing its age. Advances in hardware since then and the way we use devices have left a lot to be desired in the protocol and while it has adapted a bit to keep up with modern tech it has not done so in the best of ways. I also believe its codebase is quite complex and hard to work with so changes are hard to do.
Thus is has quite a lot of limitations that modern systems are rubbing up against - for instance it does not really support multi cursors or input that is not a mouse and keyboard. So things like touch screens or pen/tablets tend to emulate a mouse and thus affect the only pointer X has. It is also not great at touchpads and things like touch pad gestures - while they do work, they are often clunky or not as flexible as some applications need.
It is also very insecure and has no real security measures in place - any GUI application has far more access to the system and input then it really requires. For instance; any application can screen grab the screen at any point in time - not something you really want when you have a banking web page open.
Wayland is basically a new set of protocols that takes more modern hardware and security practices in mind. It does the same fundamental job as X11, but without the same limitations X11 has and to fix a lot of the security issues with X.
One big difference with X though is that Wayland is just a protocol, and not a protocol and server like X. Instead it shifts the responsibilities of the X server into the window manager/compositor (which used to manage window placement and window borders as well as global effects such as any animations or transparency). It also has better controls over things like screen grabs so not every application can just grab a screen shot at once or register global shortcut keys or various things like that. Which for a while was a problem as screen sharing applications or even screenshot tools did not work - but over time these limitations have been added back in more secure ways than how X11 did them.
There's a very nice (albeit somewhat outdated) talk here.
In a nutshell, both X11 and Wayland are protocols that define how software should communicate to (hopefully) display stuff on your screen.
Protocols as in there's a bunch of documentation somewhere that says which function a program must call to create a window, without specifying how either program or function should be implemented.
This is great because it allows for independently written software to be magically compatible.X11 is the older protocol, and was working
finegood enough for many years, but has issues handling a bunch of modern in-deman technologies - issues which can't be fixed without changing the protocol in a way that would make it incompatible with existing software (which is the entire point).
Plus its most used implementation - Xorg, consists of a huge and complex codebase that fewer and fewer people are willing to deal with.Wayland is the newer protocol, that mostly does the exact same thing, but better, in a way that allows for newer tech, and completely breaks compatibility in order to do so.
The trouble with the whole situation was that in order to replace X with Wayland basically the entire Linux graphics stack had to be rewritten - and it was, with raging debates and flame wars and Nvidia being lame.
They also wrote a compatibility layer called Xwayland that lets you keep using older X-only apps which somehow manages to outperform Xorg.Now we're at the point where major distributions are not only switching to Wayland by default, but also dropping support for Xorg completely, and announcing that they'll no longer maintain it, which is why posts about it keep popping up.
I feel like you guys aren't really "explaining like I'm 5". Let me show you:
Sometimes, when a mommyboard and a daddy graphics card fall in love, the daddy graphics card puts his connector pins inside the mommyboard's expansion slot. Then when they both get turned on, millions of tiny electrons surge out of his connector pins and into her expansion slot, where they travel up through mommyboard's data bus, and into one of her memory cards. Meanwhile, there are thousands of image files inside mommy's storage drives waiting to come to life, and every once in a while one of them ventures out of the storage drive and into her memory card. And if the electrons and the image file happen to meet at the same time, then 9 milliseconds later, a picture of a baby appears on the monitor!X (not formerly twitter) is decades old and is built around deprecated ways of doing things as well as a lot of legacy functions.
Wayland is a relatively new project with the aim of replacing X as a more "modern" display server.
Wayland had some stability issues, but they've since improved.
I'm sure Wayland is good and all, but I can't be arsed replacing X yet. I don't really have any skin in the game, I just don't replace functioning components just because they're old (FYI, bash turns 35 this year). While X does what I need it to do, I'll keep using it. I'll probably move over when my distro does.
I'll leave the technical explanation to someone else.
X.com is a centralized internet platform that is known for hatespeech, harmful content and being controlled by a single person with questionable opinions.
Wayland.social is part of a federated internet platform that is known for its diverse communities, independence from any centralized authorities and interoperability with other federated internet platforms.
/s
unless you are a developer, there’s not a whole lot to worry about – you’ll switch from one to the other when your distro switches and, chances are, you’ll never notice
the drama comes from the fact that the Linux community loves choices (and arguing over those choices) and, as @skullgiver points out, most of the choices have fallen by the wayside over the years
x is slow and dumb but the standard, wayland is fast and based but still being worked on
X is old and works for the most part but fixing stuff or adding features is hard.
Wayland is new and is supposed to be a successor to X, do what it couldn't do and don't repeat the mistakes from it. It should be a drop-in replacement like pipewire but isn't. Features take long time to develop as devs are engrossed thinking of the best solution to make it happen. A lot of proposed solutions are dismissed as well.
Basically a long time ago Linux/Unix was run on big machines in a separate room with all the fancy graphics hardware, and you’d have a dumb little machine at your desk that could barely draw pixels on a screen. So X11 was designed with all these fantastic neat server-client mechanisms that made it great for running on a mainframe.
Fast forward 30 years and all that stuff is useless now that everyone has built in graphics (as well as several other issues with X11’s archaic design). So some smart people who didn’t know any better made a new thing that everything has to be rewritten for (because they were smart, but didn’t know any better). Then someone who did know a little better was like, what if we take the old bloated one and rewrite it for the new lean one. So now everything runs in an X11 session inside a Wayland server, which has to be rewritten for everything because Wayland is a protocol, not a server.
But one of the really nice things about it is that everything has to be rewritten, so we can make newer, fancier bugs.
Edit: I don’t want you to take the impression that I think Wayland is bad. Wayland is way better than X, it just sucks that we have to rewrite a bunch of stuff for it and figure out new ways of doing things that were dead simple in X, but very insecure.
X is old and very hard to maintain. A lot of rules about how displays work have changed drastically since X became a thing. X went along with most of those changes, which meant the introduction of more and more hacks to keep it running.
Over time X became worse and worse to work on and people realized that it's easier to write something new from scratch instead of trying to fix the decade-old technical debt in X.
That new thing was Wayland and over time most if not all people that where interested in working on desktop compositing pivoted away from X.
Wayland (as it is always the case with new software of that size) didn't hit the ground running. It had various issues at the beginning and also follows a different desig philosophy than X.
Despite a lot of issues being fixed some people are still very vocal about not wanting to use wayland for one reason or another. While some of those reasons are valid, most come from ignorance or laziness to adapt.
X/X11 is a client-server protocol from the age of 10Mbps networks, intended for a bunch of "dumb terminals" connected to a mainframe that runs the apps, with several "optimizations" that over time have become useless cruft.
Wayland is a local machine display system, intended for computers capable of running apps on the same machine as the display (aka: about everything for the past 30 years).
Nowadays, it makes more sense to have a Wayland system (with some RDP app if needed), than an X11 system with a bunch of hacks and cruft that only makes everything slower and harder to maintain. An X11 server app acting as a "dumb terminal", can still be run on a Wayland system to display X11 client apps if needed.
I don’t see a real „versus“ here. Wayland will definitely become the standard display server for Linux distributions. This is not sysV init vs systemd or something else. As pointed out by lots of ppl here X11 is old and insecure because it is from another time and does not fit into modern systems and requirements, thus it is way easier to start new and fresh instead of working around for any feature needed and maintain such a old code base. The only downside for me personally is that Wayland does not support always on top windows automatically. So either right click the window or use plugins for videos from Firefox for example. AFAIK this is also for security reasons. I run Wayland on my main machine for years now, no problems at all. If I got the choice I would always go for Wayland. Even Cinnamon has experimental Wayland support now and hopefully will make the switch soon.
Wayland is cringe and X is based
t. KDE Wayland daily driver
Dude come on. Make an effort. If you really haven't a clue then start by reading the KDE developer's blog "Pointiest Stick" and github user Probonopd and his article + links https://gist.github.com/probonopd/9feb7c20257af5dd915e3a9f2d1f2277
