4 ms·

Very true. Wayland is now stable enough to be used in a lot of "production" environments and I've been using Sway as my desktop for years, and yet still, there

by jchw 3y ago

Very true. Wayland is now stable enough to be used in a lot of "production" environments and I've been using Sway as my desktop for years, and yet still, there is work left to be done: - 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.

roenxi 3y ago
> 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 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.
- JohnFen 3y ago
  > X is competing against specialist applications like VNC 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.
  - jchw 3y ago
    Can you elaborate on this one? You can of course have multiple Wayland displays at once, and/or multiple VNC servers. But, presumably, you're talking about something entirely different here.
    - JohnFen 3y ago
      X lets me log into a machine multiple times simultaneously, with each login having its own, independently operating desktop. Wayland doesn't support this (or didn't the last time I checked). VNC does something entirely different from this -- it just shares an existing desktop remotely rather than providing a unique independent desktop (complete with different resolutions and such, if you like). 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.
      - jchw 3y ago
        > VNC does something entirely different from this -- it just shares an existing desktop remotely rather than providing a unique independent desktop. 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.
dale_glass 3y ago
> Network operation. X will always be better here because it was designed to be 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.
- alphablended 3y ago
  > No, I'd say X11 wasn't designed to be run on the network [...] 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.
  - ekidd 3y ago
    Also, X networking was mostly used within local university and company networks, and not over the internet backbone. Well-designed local networks can be very low latency, often noticeably lower latency than disk I/O.
    - spacedcowboy 3y ago
      To be fair, X doesn't work that well over even local networks with modern apps. 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.
Cthulhu_ 3y ago
I just had to look it up; Wayland has been around for 14 years already. How much software takes 14 years and still isn't stable? How big and / or complicated is this problem and the codebase anyway?
- shlip 3y ago
  Ever heard of GNU Hurd ?
- jchw 3y ago
  For one thing, Wayland is a protocol, not a specific piece of software. But mostly, that progress has been non-linear. A ton of it is not about writing code, or even about Wayland itself; much of it tied into the modernization of the Linux and general open source graphics ecosystem, moving it away from being oriented around X.org specifically and implementing modern features like generic buffer management and kernel modesetting. A lot of setbacks have been simply waiting on NVIDIA to support these modern facilities well in their still-very-popular proprietary drivers. 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.
- Maken 3y ago
  PulseAudio is still not there after 19 years.
  - e12e 3y ago
    On the other hand, PipeWire is?
Condition1952 3y ago
I can’t get to launch obsidian on arch-sway without the ozone flags :/
torginus 3y ago
X hasn't been good at network in the past 2 decades. From my experience, Windows RDP has always worked way better, and when we were confronted with the need of having to do RDP access on Linux, 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.
- gjvc 3y ago
  In 1999 or 2000 I read a paper which compared remote desktop protocols and RDP was the clear winner, even then.
Gud 3y ago
Regarding your post scriptum, 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
- jchw 3y ago
  I disagree, though. Wayland itself is definitely not meant to be a threat to BSD. 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.

by jchw 3y ago

roenxi 3y ago

> 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 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.

JohnFen 3y ago
> X is competing against specialist applications like VNC 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.
- jchw 3y ago
  Can you elaborate on this one? You can of course have multiple Wayland displays at once, and/or multiple VNC servers. But, presumably, you're talking about something entirely different here.
  - JohnFen 3y ago
    X lets me log into a machine multiple times simultaneously, with each login having its own, independently operating desktop. Wayland doesn't support this (or didn't the last time I checked). VNC does something entirely different from this -- it just shares an existing desktop remotely rather than providing a unique independent desktop (complete with different resolutions and such, if you like). 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.
    - jchw 3y ago
      > VNC does something entirely different from this -- it just shares an existing desktop remotely rather than providing a unique independent desktop. 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.

dale_glass 3y ago

> Network operation. X will always be better here because it was designed to be 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.

alphablended 3y ago
> No, I'd say X11 wasn't designed to be run on the network [...] 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.
- ekidd 3y ago
  Also, X networking was mostly used within local university and company networks, and not over the internet backbone. Well-designed local networks can be very low latency, often noticeably lower latency than disk I/O.
  - spacedcowboy 3y ago
    To be fair, X doesn't work that well over even local networks with modern apps. 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.

Cthulhu_ 3y ago

I just had to look it up; Wayland has been around for 14 years already. How much software takes 14 years and still isn't stable? How big and / or complicated is this problem and the codebase anyway?

shlip 3y ago
Ever heard of GNU Hurd ?
jchw 3y ago
For one thing, Wayland is a protocol, not a specific piece of software. But mostly, that progress has been non-linear. A ton of it is not about writing code, or even about Wayland itself; much of it tied into the modernization of the Linux and general open source graphics ecosystem, moving it away from being oriented around X.org specifically and implementing modern features like generic buffer management and kernel modesetting. A lot of setbacks have been simply waiting on NVIDIA to support these modern facilities well in their still-very-popular proprietary drivers. 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.
Maken 3y ago
PulseAudio is still not there after 19 years.
- e12e 3y ago
  On the other hand, PipeWire is?

Condition1952 3y ago

I can’t get to launch obsidian on arch-sway without the ozone flags :/

torginus 3y ago

X hasn't been good at network in the past 2 decades. From my experience, Windows RDP has always worked way better, and when we were confronted with the need of having to do RDP access on Linux, 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.

gjvc 3y ago
In 1999 or 2000 I read a paper which compared remote desktop protocols and RDP was the clear winner, even then.

Gud 3y ago

Regarding your post scriptum, 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

jchw 3y ago
I disagree, though. Wayland itself is definitely not meant to be a threat to BSD. 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.