That is by no means clear cut - X is competing against specialist applications like VNC and there is a real question mark over whether a critical application uses OpenGL. X can easily win on toy benchmarks that play to its strengths, but it is rare in the extreme for that to matter.
Why do we need a remote server to provide a GUI that doesn't involve OpenGL? It happens, but not often enough to be an advantage. SSH + VNC is a more reliable and general combination, the X protocol is a maintenance and security liability. Personally if I'm logging in to strange servers I'd rather be learning cross-platform skills that carry between Windows, Mac and Linux.
I stay with X because it lets me have multiple independent logins with their own desktops. The last time I checked, Wayland doesn't support this, and this is well outside of what VNC does. This is a very important facility to me.
So the effect is a bit like VNC in that you can remotely access a desktop, but the desktop you see is not a copy of the one being actually displayed on the machine's monitor. It's entirely its own thing, only visible to that particular login.
Actually, not necessarily; you can use Xvnc to achieve this with X+VNC. It's an X server that serves over VNC.
Can Wayland do this? Yes! But, the problem is that there is no singular Wayland "display server". This is both a big strength and big weakness of Wayland. In this case, it means that I can't point to a single correct way you can do this. However, with the compositor I currently use, SwayWM, it's very trivial: I can start Sway inside of an existing compositor or X server to get a nested desktop. You could use this with Waypipe or X11 forwarding for example. It can also be started with wayvnc inside, to expose a VNC server from Sway, though this is not really any different from starting an Xvfb and running a VNC server inside of it.
Interesting. I remember asking some Wayland devs a few years back about this and they said this use case would never be supported. I'm glad that's changed! It means that if the day comes that I have to use Wayland, I won't necessarily lose functionality.
(Just for clarity, I'm not opposed to Wayland if it can do what I want. But I'm not excited by it, either, because the benefits it does provide are ones that don't really matter to me)
Does wailand supports window managers ?
Wayland doesn't have a single display server. Most of what was the X11 display server is moved to the kernel and libraries. So, the WMs ARE the display server.
xv, xpdf, xterm should work fine. xsnow should work, but will only see X windows. fvwm2, it can run on some Wayland compositors, but the better option here would be a compatible replacement: as far as I know, we still don't have an fvwm2 equivalent, but SwayWM exists as a replacement for i3, for example.
Excuse me, but BS. At least for anything of actual relevance.
X11 networking works okay for stuff that looks like a classic X11 app. That's things like xcalc. Any modern text editor, web browser, or anything else is going to be dog slow.
X11 has a bad networking protocol that's way too latency sensitive, and as a result is nigh unusuable without something like NX, which puts a local cache in front to get rid of that latency.
No, I'd say X11 wasn't designed to be run on the network, in that no particular care seems to have been taken to deal with latency and bandwidth issues. It's more of a feature that could be had for free, because if you can use an UNIX socket, you can also use a TCP one with minimal work, so might as well allow it.
That's just wrong. X11 was designed from the ground up to be used on the network. It just happens that nowadays requirements are different from when it was originally designed.
Running X11 on the network was quite a thing in Unis all over the world, where you could have dedicated dozens of X11 graphic terminal servers (tektronix used to make good ones) connected (100Mbits) to a single mainframe, and everyone running an Xemacs session without slowdown.
Wayland design is all about framebuffers, which clearly shows how focus has shifted. X11 was not designed for pixmap heavy, shader heavy scenarios.
Serving X applications (eg: Chromium) from the Raspberry Pi I'm targeting to the Mac I'm developing on is an exercise in futility, even if it does make 'download this to the target' easier. It's a lot faster to run Safari on the Mac and scp the download to the Pi, just because of interface latency issues.
Granted though, it does nothing for apps using Electron. However, try e.g. the Dolphin file browser on a 4K display over the network, and you'll find it is clearly faster than should be possible.
Probably I should've made it clearer, but imo the bigger problem is that tweaking Waypipe to replace old uses of ssh -Y shouldn't be needed; it should be possible for it to determine what possible options can be used and switch things around to deal with CPU or network bottlenecks most effectively. Easier said than done. There's also still some bugs under Waypipe; it's an understandably challenging problem.
Remote X over fast low latency networks is fine, a near local experience-- even running things like firefox or gimp. (And for classic apps it's indistinguishable from local). The wayland world alternatives like using RDP are painful to the point of usability even over a 10gigbit network, peg the cpu... and are really only good for rescuing something that's stuck or providing a bit of tech support.
Yes, over a high latency network remote X is sucky but seldom much worse than RDP.
That's very wrong, the whole point was to run over the network.
It worked exceedingly well even in the earliest 90s (modulo bandwidth expectations of the time) and continues to work wonderfully 30+ years later.
Modern apps draw all their UI client-side onto a surface which is then sent to X for display. IF ONLY we had a windowing system that was based around simply compositing together the various surfaces that the apps draw into a complete image of the desktop. Since this is a step away from the complexity of X, we could give it a name starting with W...
Don't know what to tell you, your experience is different.
Many of my computers are on a rack and I run everything on them over X displaying to my desktop. Works just fine.
Go ahead, I'll wait. Literally, I'll wait.
HDR support has been in the works for years. Why? Well, nothing terribly specific to do with Wayland: there has been a ridiculously deep dive into the entire space of color management, wide-gamut colorspaces, etc. to try to build HDR protocols that don't merely just get things out the door, but ideally support current and future use cases for the foreseeable future, have good backwards compatibility and handling of unaware apps, etc. These things are non-trivial and can't be solved by writing code or staring at GDB. (Not to mention there are few drivers that can currently support this, so it's also a bit of a chicken and egg problem.)
That is to say, Wayland is a lot less of a software problem than it is a design and social problem. And as you can probably see, ultimately, Wayland will be nobody's favorite, but hopefully with time, it can at least be everybody's favorite.
From my experience, Windows RDP has always worked way better, and when we were confronted with the need of having to do RDP access, we always found the more primitive VNC far superior.
But even that is the past. Today you can stream your entire desktop over the network with highly efficient modern video codecs, courtesy of the hardware encoders built into your GPU.
It is clear to me as a FreeBSD user that Wayland is primarily developed first hand for Linux.
To me, Wayland looks like a threat rather than something I should embrace.
I remember when it was a given that free software was developed to support a wide eco system. What happened?
“There is even one for macos” XD
There are some anti-patterns in the Wayland ecosystem that lead to arguably unnecessary dependency on things like DBus, but Wayland itself doesn't actually need much and you should find that SwayWM works fine on FreeBSD. However, the graphics stack and drivers for BSDs are a little bit behind, which is arguably a bigger threat.
- Hardware support. NVIDIA support is spotty still. Easily the biggest issue IMO, though it's better than it was.
- Network operation. X will always be better here because it was designed to be (at least with toolkits that can still take advantage of XRender.) That said, Waypipe can work well too, but I find myself needing to tweak it for best performance. Having a better out of box experience would be nice.
- Apps. Electron and Chromium still default to XWayland and still have a laundry list of (mostly small) issues. VS Code currently is unstable in native Wayland mode. Qt QDockWidget works poorly in native Wayland: it was unusable in Qt 5. OBS crashes more often in Wayland, on top of being impacted by the dock widget problem.
(There are other issues, e.g. no obvious/general answers for automation, but these ones in particular make me weary of generally recommending people switch to Wayland.)
Until then, there's no point in pushing harder. These problems are showstoppers for many.
P.S.: Not all UNIX environments have good Wayland support but since its a common misconception, Wayland is not inherently limited to Linux and some compositors will run on BSD and there is even one for macOS, albeit more in the vein of XQuartz.