Is Wayland Becoming the Favored Way to Get a GUI on Linux? (theregister.com) 210
The Register shares its collection of "signs that Wayland is becoming the favored way to get a GUI on Linux."
- The team developing Linux for Apple Silicon Macs said they didn't have the manpower to work on X.org support.
- A year ago, the developers of the Gtk toolkit used by many Linux apps and desktops said that the next version may drop support for X11...
- One of the developers of the Budgie desktop, Campbell Jones, recently published a blog post with a wildly controversial title that made The Reg FOSS desk smile: "Wayland is pretty good, actually." He lays out various benefits that Wayland brings to developers, and concludes: "Primarily, what I've learned is that Wayland is actually really well-designed. The writing is on the wall for X, and Wayland really is the future." Partly as a result of this, it looks likely that the next version of the Budgie desktop, Budgie 11, will only support Wayland, completely dropping support for X11. The team point out that this is not such a radical proposition: there was a proposal to make KDE 6 sessions default to Wayland as long ago as last October...
- The GNOME spin of Fedora has defaulted to Wayland since version 25 in 2017, and the GNOME flavor of Ubuntu since 21.04.
- [T]here's now an experimental effort to get Wayland working on OpenBSD. The effort happened at the recent OpenBSD hackathon in Tallinn, Estonia, and the developer's comments are encouraging. It's already available as part of FreeBSD.
- A year ago, the developers of the Gtk toolkit used by many Linux apps and desktops said that the next version may drop support for X11...
- One of the developers of the Budgie desktop, Campbell Jones, recently published a blog post with a wildly controversial title that made The Reg FOSS desk smile: "Wayland is pretty good, actually." He lays out various benefits that Wayland brings to developers, and concludes: "Primarily, what I've learned is that Wayland is actually really well-designed. The writing is on the wall for X, and Wayland really is the future." Partly as a result of this, it looks likely that the next version of the Budgie desktop, Budgie 11, will only support Wayland, completely dropping support for X11. The team point out that this is not such a radical proposition: there was a proposal to make KDE 6 sessions default to Wayland as long ago as last October...
- The GNOME spin of Fedora has defaulted to Wayland since version 25 in 2017, and the GNOME flavor of Ubuntu since 21.04.
- [T]here's now an experimental effort to get Wayland working on OpenBSD. The effort happened at the recent OpenBSD hackathon in Tallinn, Estonia, and the developer's comments are encouraging. It's already available as part of FreeBSD.
My own personal experience (Score:5, Interesting)
Running Ubuntu desktop here I had problems getting my monitor recognised at the correct resolution (standard 4K). Running Ubuntu it in a VM under Windows I had problems with autoscaling to window size and really really bad performance as well. Both were fixed when I clicked the Wayland option at the desktop login screen.
To be clear I am sure there are other solutions as well, but the path of least resistance pointed to Wayland with neigh a console command to be seen, and ultimately I want to use my OS not fight with it.
Android is ! (Score:5, Funny)
Android is The Favored Way to Get a GUI on Linux.
Re: (Score:3)
Android is The Favored Way to Get a GUI on Linux
That's like saying 17" is the favored wheel when someone is talking about new tyre tech for heavy trucks.
Re: (Score:2)
Ubuntu might have jumped to Wayland a bit too soon. For a long time it was difficult to get screen sharing working properly because the communications applications and the browsers hosting the web app versions didn't support Wayland fully. However, during that same period, I started getting problems in other areas if I shifted back to X, like track pad configuration not working properly any more. So for some time my Ubuntu laptop was not practical to use for WFH. Fortunately the applications and browsers mo
Re: My own personal experience (Score:4, Informative)
Works for me - almost completely (Score:2, Informative)
I've been happily using it for quite a while. It's not perfect. Specific problems with some applications that access the screen of other applications. I'd say I rarely notice the difference and I do get benefits from the feeling that windows are actually protected from each other.
The probl
Re:Works for me - almost completely (Score:5, Informative)
The Xeyes thing is silly. Xeyes works as a test because it easily shows something that is possible on X11, but not on Wayland.
On X11, Xeyes can track the mouse pointer at all times, while on Wayland every application only has visibility into its own window -- it has no idea of where it is on the monitor, what's around it, and where the mouse is when it's outside its window.
You could easily do it without Xeyes, it's just a weird and quirky test that caught on.
Different protocol (Score:2)
while on Wayland every application only has visibility into its own window -- it has no idea of where it is on the monitor, what's around it, and where the mouse is when it's outside its window.
If there is a justification for an application to peer what is outside its own window's buffer (e.g. to take screenshots or to share the desktop in a video chat), there's xdg desktop portal - a dedicated API with access control (nowadays handled with pipewire).
You could easily do it without Xeyes, it's just a weird and quirky test that caught on.
(It's also a test of whether stuff like pointer sharing in desktop portal work).
Well, is about time isn't it? (Score:3)
Wayland has been in development for how long now? 15+ years or something?
It better be the most awesome graphical layer and compositor ever. Which, if I recall correctly, was/is the entire point of the Wayland project.
Glad they apparently finally "finished" it and I'm not surprised if it isn't something that kicks serious ass, software wise. It's FOSS after all and if a team of hardcore devs use their free time to "get it right" for nearly two decades I and everybody else suspects that they actually will and do get it right.
Bottom line: nice. Glad to hear this.
Re:Well, is about time isn't it? (Score:4, Insightful)
"Glad they apparently finally "finished" it and I'm not surprised if it isn't something that kicks serious ass, software wise"
Except for some minor things such as remote access which X11 has done since it was created in the 80s. And yes, some of us DO use it but the wayland devs have gone down the usual echo chamber approach of thinking that if they don't require some functionality then no one does.
Re: (Score:3, Interesting)
It exists, it's called Waypipe [freedesktop.org]. Some compositors support RDP.
And the X11 implementation is very bad these days. It was created for a different application model, and is barely usable as-is with modern applications. Making it anywhere near good requires the NX proxy.
Re: (Score:3)
That's not part of Wayland, it's an extra library added to externally add in missing functionality. End result is now the presence of remote windows and screen recording depends on the window manager equivalent, not being independent. So Eastland in it's drive for simplicity and lack of "cruft" has managed to couple the functions of putting windows on the screen with fetching them over the network.
That is not a good design.
Re:Well, is about time isn't it? (Score:4, Interesting)
As I understand, waypipe works everywhere. It's simply a proxy for the protocol, and makes a remote application look local to the compositor, so there's nothing to implement in the compositor to make it work. It's not really missing functionality as such, but that Wayland works via shared memory and not network sockets, and so needs a proxy for dealing with networking.
Regarding things like screen recording, IMO Wayland makes the right decision by not having it be something automatically possible, but something that the user/software may or not allow. Eg, in a security sensitive environment maybe you don't want any screen sharing. Certainly it shouldn't be possible for an application to just grab the entire screen without getting permission for it.
Re: (Score:2)
I may be mistaken about waypipe then.
Regarding things like screen recording, IMO Wayland makes the right decision by not having it be something automatically possible, but something that the user/software may or not allow. Eg, in a security sensitive environment maybe you don't want any screen sharing.
Wayland has gone about it completely wrong. X11 has security mechanisms. They're little used but they're there. This in Wayland isn't about security: it's just missing for some compositors. If it's only for se
Re: (Score:2)
Okay, let's see those security mechanisms.
SSH says -X "is subjected to X11 SECURITY extension restrictions by default". Great! So, I ssh -X into another machine, and run "xwininfo -tree -root". And it dumps a lot of stuff, eg, "0x2000003 "Discord": ("Discord" "Discord") 200x200+0+0 +0+0". So yeah, this security-enabled connection knows I'm running Discord.
Yeah, that's not quite there is it?
Wayland has no such functionality at all. Like as far as each application is concerned, it's floating in some feature
Re: (Score:3)
Yeah, that's not quite there is it?
Indeed it is not quite there: the security extension is a it more capable but there's not really any way of driving it yet. There's lots of mechanisms to make various X operations return blank information.
Wayland has no such functionality at all. Like as far as each application is concerned, it's floating in some featureless void and nothing outside it exists
That's great if you want the iPhone model of running large, monolithic "applications" which interact with nothing ou
Re: (Score:3)
And I guess there won't ever be, because if you look at the repo[...]
Classic Wayland fanboiism. It's a flaw in Wayland and all you can say in defense is "X is dead". That is not a defence of Wayland's design.
The Unix model is obsolete,
More standard Wayland fanboy garbage. "If you're not using the computer how I thing you should: fuck you."
Unix was made for a group of people sharing a machine,
This displays a fundamental misunderstanding of both the history of unix and its philosophy. The uni in unix is from
Re: (Score:2)
No, you can't without lots of pain. Modern Linux desktop assumes everything runs under the same user. Try to play sound under another user -- certainly doesn't work out of the box.
And SELinux is a great id
Re: (Score:2)
So now they just need to make the display side of waypipe a daemon and build the server side into the libraries so that it just works.
Re:Well, is about time isn't it? (Score:5, Insightful)
"Glad they apparently finally "finished" it and I'm not surprised if it isn't something that kicks serious ass, software wise"
Except for some minor things such as remote access which X11
Remote access is not a minor thing. It's a must-have.
I wish these funded FOSS teams would spend less time replicating the flaws in Windows and get on with producing better stuff.
Re: (Score:2)
"Remote access is not a minor thing. It's a must-have."
I know, I was being sarcastic.
" spend less time replicating the flaws in Windows"
Unfortunately the millenials and gen-z working on Linux graphics these days seem to use MS Windows as their design guide.
Re: (Score:2)
"Remote access is not a minor thing. It's a must-have."
I know, I was being sarcastic.
Sorry. The Internet is a very hard medium for sarcasm and irony.
Re: (Score:2)
"I know, I was being sarcastic."
Well, I stole your face!
Hardware composition (Score:3)
Unfortunately the millenials and gen-z working on Linux graphics these days seem to use MS Windows as their design guide.
Wayland is designed by the Xorg devs. The problem doesn't stem from whatever Microsoft is doing.
The problem is due to how modern application work...
Except for some minor things such as remote access which X11 has done since it was created in the 80s.
...and guess what else has big problems with remote access and works badly? modern X11 applications.
Because over the 4 decades since X11 was introduced, X11 applications have gone from "use a sequence of drawing primitive to draw stuff on the graphic card's frame buffer" (and these primitives are easy to serialise over a network connection because that's how cl
Re: (Score:2)
Says who? It might be part of your workflow, but that's far from a must-have, let's be objective.
The mere fact that Windows is the market leader and doesn't have remote access is proof enough.
Re: (Score:2)
If you like Windows that much, use Windows and leave Linux alone.
Re: (Score:2)
Dumb question as I don't use it and therefore really don't know.
Is waypipe a suitable replacement for X forwarding? Why or why not?
Re: (Score:2)
Except for some minor things such as remote access which X11 has done since it was created in the 80s.
Which is actually why it was created -- to support running applications on remote, more powerful, servers displaying back onto local, less powerful, workstations and/or thin(er) clients.
Re: (Score:2)
Except for some minor things such as remote access which X11 has done since it was created in the 80s.
Which is actually why it was created -- to support running applications on remote, more powerful, servers displaying back onto local, less powerful, workstations and/or thin(er) clients.
Isn't the machine doing the displaying the server and the remote machine running the application the client?
Re: (Score:2)
It still requires that the GUI libraries in apps support the X protocol in order to deliver on the promise of implementing network transparency. Except it looks like GTK is considering breaking that...
So one MAJOR promised feature is missing and needs implementation.
Wayland is pretty good, but so is X11 (Score:3)
Wayland still can't do remote connections unless you want to go down the bandwidth hogging RDP method.
Was there some reason we wouldn't have X12? Remove all the cruft from X11 but keep the good bits (ie remoting facilities) and fold in a lot of the extensions that should have been part of the core for a long time now.
Re: (Score:2)
Wayland still can't do remote connections unless you want to go down the bandwidth hogging RDP method.
I believe this was one of the reasons why they started working on wayland. X has a lot of features that add complexity or are insecure by design. Xhost + was cool for pranks on your collegues 30 years ago, but in this day and age a nightmare for security.
Re: (Score:2)
Thats not a good reason for not having remote functionality. For a start X has been ssh tunnelled for years now and if it was built in to a new version it would almost certainly have TLS or SSH built in.
Re: (Score:2)
I'm not saying it was a smart move. As a user, I like X, and see no reason to replace it. On the other hand I can imagine that it has become very complex from a developers point of view. You know how it goes.
Re:Wayland is pretty good, but so is X11 (Score:5, Informative)
The reason why Wayland has no remote functionality natively is that it doesn't use network sockets to communicate, but shared memory.
X11 has various drawing primitives -- "put a 20x20 box at 10,15". Wayland is "here's a buffer containing an image, put it on the screen somewhere".
There's Waypipe to act as a proxy and do networking. Seems to work just fine, and overall performs very well.
Re: (Score:2)
^ this, and I'll build up on it:
Wayland came from looking at what exactly the X11 server was still doing in the day and age of compositing window managers. There were 3 main answers
- input handling
- display detection
- pushing framebuffers around (maybe using the presentation extension... I'm fuzzy on the history)
input handling became libinput, display handling was already mainly done by compositors anyway (but now is getting helped by libdisplay-info), and the buffers were already the domain of compositors.
Re: (Score:2)
"My personal pet peeve are Client side window decorations. I absolutely hate those."
Speak for yourself. It allows huge flexibility. Also X has the advantage of if the program hangs you can still move/destroy the window unlike with MS Windows and Mac where the window is stuck in position because the app isn't responding to paint or move events.
Re: (Score:3)
> Speak for yourself.
I am... note the "personal"
and I did in fact mean to write: "Luckily at least KDE went the SSD way."
> MS Windows and Mac where the window is stuck in position because the app isn't responding to paint or move events.
That's client side decorations (CSD)... And that's one of the reasons why I don't like them. Gnome's Mutter (which does CSD by default) AFAIK has a way of doing that though. X11 is Server Side Decorations only (SSD).
The flexibility (which I acknowledge for programs the
Re: (Score:2)
"That's client side decorations (CSD"
Fair enough, I thought you were talking about window managers vs the X server.
Re: (Score:2)
Windows managers are server-side decorations (as God intended them). Windows has had CSD since nearly the beginning and that's why when the app freezes you can't move the window. Very annoying. Plus the propensity now of applications to cram all kinds of controls in the titlebar make it very hard to actually move windows now. Have to aim for a little clear spot. Unless the app decides to allow you to drag on controls.
GTK and Gnome are the worse offenders now when it comes to CSD. CSD is the preferred w
Re: (Score:2)
"Windows managers are server-side decorations (as God intended them)"
To be strictly accurate WMs are just clients too - they connect to the X server just like any other client.
X11 apps evolution (Score:2)
Wayland {...} doesn't use network sockets to communicate, but shared memory.
Yup that's part of the fact that modern applications expect hardware acceleration everywhere.
X11 has various drawing primitives -- "put a 20x20 box at 10,15".
Correct... 4 decades ago, back when the protocol was created.
But nowadays, ...
Wayland is "here's a buffer containing an image, put it on the screen somewhere".
...as serafean points out, that's also what modern X11 applications do, too.
Wayland just implements the used bits of X11 and throws everything else into XWayland.
Re: (Score:2, Informative)
Wayland still can't do remote connections unless you want to go down the bandwidth hogging RDP method.
I think you'll find that's the bandwidth hogging framebuffers method (aka. VNC). X11 and RDP both send drawing primitives over the wire and have caching on the client side so are much more efficient than the zRLE and JPEG painting bullshit that happens with framebuffer protocols.
X11: not nowadays (Score:2)
X11 and RDP both send drawing primitives over the wire {...} painting bullshit that happens with framebuffer protocols.
X11 used to send drawing primitives over the wire, 4 decades ago when the protocol was designed.
Modern X11 application instead send buffers around and expects hardware acceleration everywhere (as OpenGL,Vulkan, etc. when they paint their buffer and as hardware compositing when the display server composite all applications' buffers as windows on the screen).
Wayland is basically the Xorg devs decided to only implement the parts of X11 that are actually used nowadays.
Re: (Score:2)
Too bad they left out some frequently used bits.
Re: (Score:3)
I've thought along these lines for a while. I'm using Qt as an example here. Rather than low level drawing, consider the facilities provided by a toolkit like Qt, or perhaps the Chromium rendering engine. If I just want to display some HTML on the display server, all I really need to do is create a window with an WebView widget and sent it contents, and perhaps send through Javascript for it to execute. That avoids a lot of network round-tripping. If I want to create a UI with widgets, actually have a stand
Re: (Score:3)
Bandwidth hogging RDP? Sorry, no. RDP is extremely efficient, bandwidth-wise compared to remote X11 with modern apps. In fact over the years the use of X11 has tended more and more towards RDP-type of rendering anyway, where the client just pushes bitmaps to the server, but without all the optimizations of RDP. So with remote X11 you end up with pushing bitmaps, but with no compression and all the extra round-trips. This makes remote X11 quite slow and with lots of latency compared to RDP which works qui
App drastically different nowadays (Score:5, Interesting)
Wayland still can't do remote connections unless you want to go down the bandwidth hogging RDP method.
Note that modern X11 applications also behave badly over SSH for the same reasons.
Was there some reason we wouldn't have X12?
Yes, the way modern apps work has radically changed since 4 decades ago when X11 was designed.
Remove all the cruft from X11 but keep the good bits (ie remoting facilities) and fold in a lot of the extensions that should have been part of the core for a long time now.
That is basically the description of what the Xorg devs created when they set out to create the successor. They just called it Wayland instead of X12, among other because X12 is a completely unrelated network protocol (home automation).
The thing is you need to realise what " fold in a lot of the extensions that should have been part of the core for a long time now" and "Remove all the cruft from X11" entail in the light of modern applications.
4 decades ago, when X11 was created, the API offered drawing primitives. Client applications called them and got to draw on the graphic card's frame buffer.
(That was easy to serialize over a network connection - evermore so as a socket was the standard way for a client and a server to talk on some target platforms).
Nowadays applications work in a radically different way: they get their own private buffer, write whatever they want into it (usually done with hardware accelerated APIs like OpenGL or Vulkan). Then the display server get all applications' buffers and composite them as windows on the desktop using hardware acceleration.
Nobody is using the X11 primitives as a "glorified postscript- or SVG- renderer", the only part of X11 that are used nowadays are blits.
That's why modern X11 applications over network are sluggish: instead of sending a very compact stream of drawing instruction over the network, your sending whole updates of the application's output buffer - you're basically streaming video, and a very badly compressed one (because you rely only on SSH's compression). Even that output buffer will now usually fall back on much slower software rendering paths (unless stuff like AIGLX is present and active).
In short, modern remote X11 is slow as hell, because the GPU isn't local to the application (and everything expects hardware acceleration nowadays) and because you're streaming what boils down to uncompressed video in the form of output buffer updates.
Xorg devs recognized this and basically decided that an actual modern remote video streaming (à la VNC, etc.) would be better suited for remoting apps.
And that's how the extensions to bring Wayland to remote work: application still paints its own buffer (but now has access to the local GPU on the local Wayland server), then buffer is video-streamed over the network and exposed as another windows on the target Wayland server.
So in short:
- remote doesn't work easily anymore because apps have switched from screen drawing command, to painting their own (hardware accelerated) buffer, and then the display sever compositing all the buffers to the screen (hardware accelerated, too).
- Wayland boils down to the Xorg devs taking the couple of extensions of X11 that everything uses (related to painting buffers and compositing them on screen, all with hardware acceleration) with everything else ripped out and thrown (for backward compatibility) into XWayland.
Re: (Score:2)
"Nobody is using the X11 primitives as a "glorified postscript- or SVG- renderer", the only part of X11 that are used nowadays are blits."
Ever used xterm?
"Nowadays applications work in a radically different way: they get their own private buffer"
Ever heard of double buffering? Its been a thing for , oh , a while now even with X via the Xdbe extension. No reason whatsoever that the buffer used for it couldn't have been rendered locally (perhaps it is, I don't know) and streamed to the server via some RDP met
Re: (Score:2)
Ever used xterm?
Why would you use a remote xterm rather than just ssh? Seems a rather artificial example - plus very few folks use xterm anymore for heavy terminal sessions, there are way better terminals
Re: (Score:2)
Wayland still can't do remote connections unless you want to go down the bandwidth hogging RDP method.
Funny, it's the opposite for me. 99% of the time when I'm working with remote linux machines it's SSH, and in those remaining 1% when remote X11 might be the answer, turns out the program in question is TERRIBLE over a remove X11 connection to the point that VNC works better.
Re: (Score:2)
X works really well over low-latency connections. I use basically everyday this way. Bit it has severe problems though when latency is high. The reason is that X clients often serialize the requests to the sever, i.e. wait for a response before sending the next. This kills performance on low latency links. This could be fixed when the toolkits supported the protocol properly, because the X protocol can be used asynchronously. There are X proxies that work fine also over low latency links and they work by
I like X11 (Score:4, Interesting)
X11 is network-oriented, which I personally prefer.
Having said that, I'll use what the developers insist I use, whether I like it or not. That, to me, is a weakness of the development system and not a strength - I like having options. Open source is richest when there are options. When there's obligations, you find weaknesses.
However, I respect there just aren't enough GUI developers for X11 and Wayland. There weren't even enough GUI developers for X11 and GGI or KGI!
Wayland has strengths, yes, and I acknowledge those. It'll be better for gaming, for a start, but X11 was easy to program for - I wrote my final year degree project in OpenLook - and was gentle on the computer. I doubt Wayland will be as friendly. From the sounds of the remote connection issues people are having, it really isn't as nice.
This will also spell the end of Netrek and XTank. Netrek because nobody is going to port the game to Wayland, XTank because it would require a complete rewrite from the ground up to run under Wayland.
Re: (Score:2)
Wayland can more-or-less work over a network - see waypipe. My subjective view is that it works better than X11 over SSH.
No (Score:2)
It doesn't fix any problem I care about - yeah, yeah, security of X-sessions like that matters to anyone - and doesn't reproduce the one really big important feature of X11, which is remote access. Which I do care about.
Wayland is a toy project for its dev team. They're having fun working on it, sure, and it's useful in a limited number of scenarios. But it's their toy, not mine. It's certainly not good enough to replace X11.
Re: (Score:3)
It's a long term plan. I think Wayland is one of the parts needed for a modern, secure desktop. The unix model that targets a multi-user machine is obsolete. The new model is application sandboxing, where you can download a random game from Steam and know it won't secretly spy on you. For that sort of thing to work you can't have every application capable of showing a window being able to capture your keystrokes and record your screen.
And there's waypipe for remote access.
Re: (Score:2)
It's a long term plan. I think Wayland is one of the parts needed for a modern, secure desktop. The unix model that targets a multi-user machine is obsolete.
So X-session security isn't an issue, then.
The new model is application sandboxing, where you can download a random game from Steam and know it won't secretly spy on you. For that sort of thing to work you can't have every application capable of showing a window being able to capture your keystrokes and record your screen.
I have no faith in sandboxing protecting me from that anyway. I mean, why would I? I don't have a different keyboard and screen for each app.
Wayland is just a waste of time. It's the dev's own time and as long as they don't want to force me to waste my time too they're welcome to do whatever the fuck they like instead of something useful.
Re: (Score:2)
What do you mean?
Under Wayland, applications don't know anything about anything happening outside their window. That's why the Xeyes test for Wayland exists. Under X11, Xeyes can track your pointer all over the screen. Under Wayland, Xeyes only works so long the mouse pointer is over the Xeyes window, and the moment the pointe
Re: (Score:2)
Under Wayland, applications don't know anything about anything happening outside their window.
So, how does vnc or team viewer work under Wayland?
Re: (Score:2)
You need an extension. So under Wayland, depending on the compositor, you have one of 3 answers:
So this overall leaves a lot of room for serving whatever need one might have.
Wayland is ass (Score:4, Informative)
Until this gets fixed:
https://gitlab.freedesktop.org... [freedesktop.org]
At the moment we have the only DE which works nearly flawlessly with Wayland and that's Gnome. That's all you need to know how "ready" it is, more than 14 years after it's been devised.
The fact that every desktop environment of Wayland must recreate a graphics server is simply insane. You don't recreate a graphics server in Windows, MacOS, Android, iOS or any other major OS.
Wayland developers beg to differ. The result is obvious, it's just ass.
Re: (Score:2, Interesting)
Re: (Score:2)
At the moment we have the only DE which works nearly flawlessly with Wayland and that's Gnome. That's all you need to know how "ready" it is, more than 14 years after it's been devised.
Wayland doesn't work with gnome flawlessly:
- it doesn't support fractional scaling - just integer than downscaling
- it doesn't support server side decorations, with the worst workaround: run QT apps via XWayland where it does work
Re: (Score:2)
As soon as I see "freedesktop.org" I know it's going to be shit.
Re: (Score:2)
Weston? A PoC, nothing else, not used by any DE in any capacity. It lacks the very basics such as the task panel.
And this is exactly what almost everyone is doing.
Wayland is a non-solution looking for a problem (Score:2)
I've played 3D games just fine under X, run VR with the Valve Index while X was up, can generally work fine with international text and image pasting, etc, etc. I deeply value the ability to swap out to different window managers, although fvwm has worked well for me for a good while (after having gone through about 10 others). I value this because anyone designing how the window environment should work is very, very likely to break something fundamental, and often utterly fail to understand why it's a pro
Recent Wayland (Score:2)
(For this paragraph, my information is from a few years back, so let me know if Wayland has solved any of these below...) However, Wayland's pretty useless for many things given its:
* general lack of any way to run X programs (individuals windows) on the same host,
* a way emulate at least an X server for X programs to use (something I've written myself before, although I modified my X server to use an OpenGL texture format for the X server display buffer so I could map a display onto any object)
XWayland is here for that running X11 programs and emulating an X server, atop of a Wayland server.
(for the crazy mapping to textures, that's usually the realm of compositors, but I have no ideas about that).
* a way to run a program on one host that displays its windows to a different host - this ability is CRUCIAL in many applications
* (rare) a way to run a program that can display windows on several hosts simultaneously (like I said, even Emacs supports this... though the emacs proc will die if any of the X servers it's connected to do, which is a bit fragile)
and specially that part:
spread across all my hosts at home and whatever I'm using for work, in one big, shared environment - and I want that set up to be be resilient in the face of any host crashing, so that I can connect to that environment from any host, or reconnect if the one in front of me died, and still have most of it reappear when I log back in. Until we have something that gives that level of ease of use, we're still basically just using toys, regardless of how good the hardware acceleration is.
This is not going to be reliable even on classical X.
What you need is some forms of local display server where the application runs, that can then forward windows to remote display servers, with the possibility to dettach and reattach the remote as you go. (This way, when the rem
Re: (Score:2)
Oh, it's found its problem already.
a way to run a program on one host that displays its windows to a different host - this ability is CRUCIAL in many applications
All of those poor proprietary applications developers trying to figure out how to bill per user seat when the OS/display system is shifting their UI all over the country on the Internet. What you (and I) consider to be an ability is keeping the MBA suite awake at night trying to figure out their income stream.
30 years and only 3% (Score:2)
Re: (Score:2)
I hate the oversimplification some distros forced on us.
But I am still using Linux for 99% of my desktop work.
Why is Linux unusable for you?
Gentoo installer finds Linux unusable :o (Score:2)
You do realize you can choose your own desktop environment.
The Best Desktop Environments For Linux [itsfoss.com]
“I now use Windows 11 simply because Linux is simply too unusable even for an experienced user. And this is from someone who has installed gentoo and arch multiple times.”
Good grief, you managed to install Gentoo and find any of the other distros unusable. Personally I've never experienced such problems. Currently I'm giving anti
Re: (Score:3)
Gnome and Wayland made Linux a joke [...] I now use Windows 11 simply because Linux is simply too unusable
You're free to use Windows, but don't accuse linux in general just because you don't like Gnome. What are the popular desktop environment in Windows and how can you change the default in the system? Which alternative graphical servers are available in Windows? How do you prevent Windows from auto-updating the graphical system from that of Windows 10 to that of Windows 11? How do you keep the program manager of Windows XP rather than the recent versions?
I'm using KDE since 2003 and fluxbox since 2009, they w
Re: (Score:2)
There are choices other than IBM/Red Hat and Ubuntu.
I happily run Gentoo Linux without GNOME, Systemd, or Wayland. Although I have nothing in principle against switching to Wayland once it becomes better suited to my use cases.
Most desktops don't support it (Score:4, Informative)
I've tried it a bit and Wayland usually works okay on GNOME. Though it tends to be a bit flakey still under Plasma.
My main issue is stability. When Wayland crashes* (and it usually does frequently on my machines) it takes down the whole session. When an X window manager crashes the applications keep running and the window manager simply restarts.
* No, I don't use NVIDIA cards. This happens on Intel and AMD cards.
Puff Piece. (Score:2)
MATE or XFCE (Score:2)
It depends (Score:2)
VMware (Score:2)
Until wlroots based compositors (Hyprland) get "hardware acceleration" under VMware, Wayland can choke on a cock.
That is just a start, then there is the myriad of other problems people have listed that still haven't been solved.
Xorg just works. If it ain't broke, don't fix it, and Xorg is NOT broke, insecure, or any of the other FUD.
Re: (Score:2)
I'm still on X11 and probably will be for years. For lots of reasons. I think Wayland is a good idea but it is not currently implemented in a way that would work for me. I'm open to the possibility of that changing in the future.
But it is true that any malicious X11 window can see the input to any other. Whether that is a security risk or not depends primarily on whether you trust the software you run not to abuse that access. Since I run Gentoo, I compile almost all of my software from source (not dir
Re: (Score:3)
X11 theoretically has security model where you isolate clients against each others. That never was fully exploited to isolate clients on Linux, because programs of the same user can access each others data anyway. So it was kind of pointless. It would make sense in a containerized model, but people now claim that this is a fundamental flaw of X that it can not do this and this is why we need Wayland. This is, of course, nonsense. It is a fundamentally flaw of Wayland that programs that need to interact (e.g
Re: (Score:3)
Oh. My. GOD. Finally someone else who knows this!
The number of people repeating flat-out incorrect claims about X is very high.
It is a fundamentally flaw of Wayland that programs that need to interact
Not according to the true believes. The iPhone model where you run one "application" which can never interact with another is the goal. They hate the unix philosophy of small, single purpose tools working well together and they seem intent on destroying that.
Hooray for laptops (Score:3)
Screen recording simply does not work (Score:2)
It Makes Sense (Score:3)
How X used to be used:
Application/High level toolkit-> Xlib/XFonts/XToolkit/XVideoExtensions/XCompositor/XRenderingExtensions/XInput/XGL -> X Drivers -> Kernel Video Driver -> Display
How X is used now:
Comprehensive Toolkit (Fonts, 3d, compositor, etc...) -> MESA/LibInput -> XCB/XGL -> XVideo Driver -> Kernel Video Driver -> Display
How Wayland works:
Comprehensive Toolkit (Fonts, 3d, compositor, etc...) -> MESA/LibInput/XWayland -> Wayland -> Kernel Video Driver -> Display
All X is used for these days is a HAL between Mesa and the video driver. All the low level API facing stuff is handled by MESA, and all the hardware stuff is handled by the display driver (and an event framework for input stuff) X just passes everything through with a nice interface.
That being said, there's nothing inherently wrong with X, other than it does a ton of stuff most people don't need or use any more. It's mature and stable and perfectly fine for a lot of use cases. However, Wayland is designed from the ground up to fill exactly those use cases in an easier and more efficient fashion.
Xgamma (Score:3)
Let's ask Betteridge... (Score:2)
Betteridge says... no
And still the big FU to remote users (Score:3)
Every time I see one of these articles I end up Googling Wayland remote to see if sanity has kicked in.
So there are lots of results if you want to switch to Ubuntu. I do not want to switch to Ubuntu. Even less do I want to have anything to do with Gnome. I can tell you where to shove Ubuntu and Gnome.
X doesn't care what distro or applications I run, what lightweight unknown window manager or big heavy mainstream desktop I choose. Remote is always an option. Well.. it gets a little tricky if the application calls for 3d effects but nothing virtualgl can't sort out.
I'm sure there's some way to do it. Something involving layering compositors on top of one another available only after reading 10,000 man files that all feel like they were written by Lennart Poettering. But it shouldn't take a degree in OS development just to get a f'ng remote desktop.
Nor should it require switching to a mainstream desktop manager or distro.
Re:Nothing new there (Score:5, Interesting)
Yes, turns outs developing a desktop system is really hard, and in the modern world a desktop system needs more than just window compositing and if the compositing system gets in the way, that's a problem. No amount of declarations of "out of scope" actually fix that.
The other problem is that no amount of declarations of "cruft" about the supposedly inferior system actually improve the new one. Despite ragging on the X extension mechanism (what new API additions were called in 1987), Wayland have not in fact either solved the library versioning problem or solved the problem of ensuring a new version is semantically equivalent to a prior version.
Weird, huh?
And the over all system is now much more complicated too, not simpler. Originally the claim was a minimal compositor was more or less code size equivalent to a minimal window manager. That's nice but on X that window manager works. On Wayland lots of stuff like screen recording won't work, so you need to add a bunch of extra stuff like pipewire integration etc just to get the very basics working.
And in the effort to strip "cruft" and be "modern", they managed to miss the boat on high DPI, and worse on high bit depth, something X11 supported since 1987. Really. It supports up to 10bpp. Lots of stuff will break because for years people have been ignoring the bit depth reported by the server and assuming 8bpp because it was so ubiquitous, but no system protects against malice. The stuff from the elder days when every vendor had a different format, like xterm and FVWM will work fine!
Re: (Score:2)
Yes to what? I think you replied to the wrong comment.
Re: (Score:2)
I think you replied to the wrong comment.
D'oh!
Re:RDP is not AI friendly (Score:5, Funny)
"RDP/Wayland is not AI friendly. "
Weyland-Yutani is Alien Intelligence-friendly.
It's 2023, get over it. (Score:5, Interesting)
RDP/Wayland is not AI friendly. At least X11 had an object oriented protocol designed both for rendering graphics in a human centered world, and for easy parsing in a scripting and bot centered world.
There's a grain of truth under this gibberish: when initially designed, the X11 protocol was all about drawing primitives, like most of the graphical API of the era.
So just by listenning on the X11 protocol, you get a rough idea of what is being drawn on the screen.
Except that...
Wayland's design philosophy is purely human centred, which is a real shame.
...except that it's 2023 now. And it's absolutely not how modern app work at all.
Wayland is designed around the way virtually all modern GUI app work: they use the graphical API to blit rendered buffers on the screen using hardware acceleration.
A modern display server's role, be it Xorg or Wayland, is to manage windows. It provides low-level API to a hardware accelerated compositor, it doesn't serve the purpose of a "glorified Postscript- or SVG- renderer" any more.
(When there is primitive drawing nowadays, it happens entirely within OpenGL, Vulkan or some more specific modern API and only the final rendered buffer is composited onto the screen by the display server).
As most of the Xorg devs have repeatedly explained, the part of the X11 API that is used in modern settings has nothing to do with the API that was designed 4 decades ago.
Wayland is in a way a modern re-write of only those very recent X11 extensions that current apps use, with all the legacy API and older extensions that nobody uses any more ripped out and thrown (for backward compatibility purpose) into their own dedicated XWayland server.
Re:It's 2023, get over it. (Score:5, Interesting)
There are advantages to ALSO having a glorified Postscript processor running on the backend. There are times when that's simply a more efficient way to get the job done. Furthermore, you can have Postscript run code, it's not limited to drawing. (There was actually a fully-functional web server written in Postscript, floating around some time back...)
So, yes, being able to blast images to the screen is very useful - especially for games - but it should still be possible to get the backend to do heavy lifting at times, because that is actually quite a useful feature. You really do want both, so that the processing is done where it is best to have it done.
The ideal setup is to use a protocol that requires the least bandwidth possible for the same result. In the case of anything graphics intensive (bitmap editing, games, etc), then obviously the least bandwidth is consumed by sending over pre-processed images, have all your heavy lifting done in advance. In the case of anything that is graphics-light (editing wireframes/line diagrams/text), then you want all your processing done as late in the day as possible because the processed data will be much heavier than the raw description of it.
This is because although modern networks have lots of bandwidth, there's no need to use the most possible. Rather, you still want to use the least possible, because it's your most constrained resource and it's your slowest resource.
(One reason Berlin failed to take off was because it was TOO network-intensive. It was a brilliant concept, a brilliant design, it was astonishingly powerful, but it required more bandwidth than networks could provide and died out. Even on today's machines, it would run far too slowly, because it ate so much bandwidth.)
So you ideally want to use a hybrid approach. I'm not convinced X11 is capable of running a hybrid approach well - the protocol is far too heavy where it is flexible, and far too limited where it is light - but I'm not convinced Wayland has the right balance either. It seems to be designed for pre-processed data only, with a lightweight display. Absolutely ideal for many uses, but absolutely horrid on bandwidth for others.
Still, I can accept Wayland as being a good step, provided future GUIs allow for a flexibility that no longer exists and hasn't done for some time.
(Technically speaking, there hasn't been a PostScript backend since the days of InterViews. But X11, in the early-to-middling days did offer something of a hybrid approach.)
Re: (Score:2)
Re:It's 2023, get over it. (Score:5, Informative)
Yes, Wayland essential is a rewrite of some X extension modern apps use. A such, it breaks compatibility without any good reason, is - after 15 years - still catching up, and breaks X forwarding.
Re:It's 2023, get over it. (Score:5, Interesting)
It is the usual story. Some developers managed to convince their managers that rewriting everything fix all problem and make everything simpler. "not maintabnable" is just some bullshit argument in this context. Sure, the code was old, but it was maintained just fined for along time and X works extremely well, which would not be the case if it were indeed "unmaintainable". Wayland took 15 years to be somewhat usable and still has problems, which does not convince me about its superior design. Hopefully some people step up and will continue to maintain X. But yes, one can not force anybody to do this. But if this does not happen, we will sadly loose a lot: Long-term compatibility with decaded-old protocol and seamless remoting with perfect integration.
Re: It's 2023, get over it. (Score:3, Insightful)
Except âall the stuff ripped outâ(TM) is what almost every app uses out there and what made X11 the standard to begin with. Does Wayland support remote compositing, server/client, can I even just run my Wayland app in a Docker container and have it pass through to the host in the way X11 can - the answer is probably no.
If you wanted security, you couldâ(TM)ve layered TLS and authentication on X11, acceleration has been done just as well. This seems more like a systemd approach âletâ
Re: (Score:3)
As most of the Xorg devs have repeatedly explained, the part of the X11 API that is used in modern settings has nothing to do with the API that was designed 4 decades ago.
We should have a contest: what's the oldest code or design philosophies still in active use. The X11 libraries and protocol has to be one of them. There's got to still be code written by MIT undergrads in 1985 still in use deep in the core X libraries.
Other oldies but goodies: the x86 instruction set, Bourne shell syntax (although probably none of the code). The Unix user/kernel model. Maybe parts of glibc. The TCP/IP architecture (but probably no actual code). I wonder if Win11 still has any MS-DOS code in
Re: (Score:2)
Just as soon as Wayland delivers on that promised network transparency without resorting to X to do it.
Re: (Score:3)
Too bad Wayland screwed the pooch by not simply defining a "modern" subset of the X protocol that made sense as a starting point. Instead, they came up with this "thing" that throws out very much useful and even necessary features and then started a program of gaslighting about how we didn't REALLY need those other features and claiming Wayland would support those use cases "any day now".
Well, here we are a few years later and we DO need those features and the Wayland devs haven't a clue how they might go a