After more than forty years, everyone knows that it’s time to retire the X Window System – X11 for short – on account of it being old and decrepit. Or at least that’s what t…
I am not sure about that. They have different designs for sure. Mostly because one was designed 25 years later. I guess you mean they have different goals because Xorg did not incorporate some goals in its design (like security). But is it a goal of Xorg to be insecure? That feels like a stretch.
There are design goals in X11 that are not included in Wayland. Take asking the display server to draw primitive shapes for you as an example. But modern X11 apps do not do that either. That is not how things like Qt and GTK work. So, more of a “25 years later” thing than a true difference in goals. The “compositor” approach. The DDX layer. These are more of a reflection of “how things work today” on both systems than they are differences in goals.
Perhaps you mean things like “network transparency” as I hear that one a lot. Wayland’s design is to have a simple core that can be extended. But the same capabilities exist for Wayland. For example:
What goal does Xorg have that Wayland does not? Again, other than poor security (not a goal).
The lack of security in Xorg makes many things easier. Wayland apps run in a sandbox which makes some things harder. Many complaints I see ultimately boil down to this difference. Flatpaks are also sandboxed and a lot of the solutions on Wayland are similar (eg. XDG desktop portal). But again, am not sure crap security was really a “goal” of Xorg. It is simply convenient.
Because of security, things have to be explicitly supported on Wayland while X11 apps can just do them. There is no official way to capture a screenshot on X11 even after 40 years. But any X11 app can do it pretty easily as all apps have access to the entire display (even contents of other windows). On Wayland, there is a protocol for screen capture. There has to be, or it would not be possible. The same is true for many other features. And, I fully admit, some protocols for Wayland to do things done by some x11 apps do not exist yet (or are not yet widely supported by compositors or apps).
But again, I do not really see “poor security” as an x11 design goal. It was simply born in an era where that did not matter as much. Projects that want to modernize X11, like Xlibre, will have to break things on X too. Time will tell what that looks like.
X11 is a display server. Wayland is a presentation layer. Different goals. I have run graphical multi-seat systems using x11. Something like that will never be possible in the same way for Wayland because it is out of the design scope
Xorg is a display server. In Wayland, your compositor is the display server.
“I have run graphical multi-seat systems using x11. Something like that will never be possible in the same way for Wayland”
I have to give you this one. Wayland is not designed to be multi-seat. I do not know about “never” but you are right that multi-seat is a design difference.
I am not sure about that. They have different designs for sure. Mostly because one was designed 25 years later. I guess you mean they have different goals because Xorg did not incorporate some goals in its design (like security). But is it a goal of Xorg to be insecure? That feels like a stretch.
There are design goals in X11 that are not included in Wayland. Take asking the display server to draw primitive shapes for you as an example. But modern X11 apps do not do that either. That is not how things like Qt and GTK work. So, more of a “25 years later” thing than a true difference in goals. The “compositor” approach. The DDX layer. These are more of a reflection of “how things work today” on both systems than they are differences in goals.
Perhaps you mean things like “network transparency” as I hear that one a lot. Wayland’s design is to have a simple core that can be extended. But the same capabilities exist for Wayland. For example:
https://www.mankier.com/1/waypipe
or even better:
https://github.com/wayland-transpositor/wprs
What goal does Xorg have that Wayland does not? Again, other than poor security (not a goal).
The lack of security in Xorg makes many things easier. Wayland apps run in a sandbox which makes some things harder. Many complaints I see ultimately boil down to this difference. Flatpaks are also sandboxed and a lot of the solutions on Wayland are similar (eg. XDG desktop portal). But again, am not sure crap security was really a “goal” of Xorg. It is simply convenient.
Because of security, things have to be explicitly supported on Wayland while X11 apps can just do them. There is no official way to capture a screenshot on X11 even after 40 years. But any X11 app can do it pretty easily as all apps have access to the entire display (even contents of other windows). On Wayland, there is a protocol for screen capture. There has to be, or it would not be possible. The same is true for many other features. And, I fully admit, some protocols for Wayland to do things done by some x11 apps do not exist yet (or are not yet widely supported by compositors or apps).
But again, I do not really see “poor security” as an x11 design goal. It was simply born in an era where that did not matter as much. Projects that want to modernize X11, like Xlibre, will have to break things on X too. Time will tell what that looks like.
X11 is a display server. Wayland is a presentation layer. Different goals. I have run graphical multi-seat systems using x11. Something like that will never be possible in the same way for Wayland because it is out of the design scope
X11 and Wayland are both protocols.
Xorg is a display server. In Wayland, your compositor is the display server.
“I have run graphical multi-seat systems using x11. Something like that will never be possible in the same way for Wayland”
I have to give you this one. Wayland is not designed to be multi-seat. I do not know about “never” but you are right that multi-seat is a design difference.
My mind goes to this project again: https://github.com/wayland-transpositor/wprs
But wprs only runs one compositor so it does not inherently address multi-seat. Support for that would need to be added.