4 ms·

What lessons have been learned and what has changed that give confidence wayland wont end up in a similar state?

by gumballindie 3y ago

dralley 3y ago
To start with, Wayland isn't a server, it's a protocol.
- yobert 3y ago
  X11 is a protocol too :p
- yjftsjthsd-h 3y ago
  That just pushes the problem to the compositors
  - hsbauauvhabzb 3y ago
    Does the multiple compositor situation result in duplicated effort and/or constraints for the end user such as being unable to run Konsole on Gnome3 etc?
    - yjftsjthsd-h 3y ago
      My understanding is that simple applications like Konsole should be fine because they only use widely-implemented protocols. Where it goes off the rails is when you want to do exotic things like take a screenshot, and GNOME, KDE, and wlroots have each implemented a different protocol to do so.
      - t0b1 3y ago
        > exotic things like take a screenshot I'm not sure but is this meant ironically? Because taking a screenshot is a thing people do very often. Capturing your screen is, too. Even by third-party programs. And yet they never put it in the protocol but just said to go to dbus. > GNOME, KDE, and wlroots have each implemented a different protocol Is that true? My understanding was that GNOME never put forth a protocol but always did their dbus thing. I know that wlroots proposed a bunch of protocol extensions but those never went anywhere since, well, GNOME didn't want to implement them[1]. Nowadays I think every compositor(?) just implements the xdg-portal stuff. [1]: https://gitlab.freedesktop.org/wayland/wayland/-/issues/32#note_367228 https://gitlab.freedesktop.org/wayland/wayland/-/issues/32#n...
        eadmund 3y ago
        I think to the Wayland folks, anything other than using Windows is an exotic use case. They’re not entirely wrong, but if we wanted to use Windows, we … would be using Windows. The great thing about Linux was that we could do more than Windows or macOS permitted.
        jdiff 3y ago
        Weird take. Windows and macOS both let you do things Wayland doesn't currently have widely adopted protocols for. Only thing Xorg can do that any of the others can't is let a client application manage windows, and it's only macOS that really doesn't like that.
        yjftsjthsd-h 3y ago
        > I'm not sure but is this meant ironically? Because taking a screenshot is a thing people do very often. Yes, I was intending to mock Wayland for failing, after 15 years of development, to have a single way of taking screenshots that works in all environments. I understand wanting to make things modular and flexible and make as much optional as possible[0], and I understand wanting to ship the core protocol first and then follow up with drafting other things and building consensus, but the fact that this thing was allowed to hit end-users with screenshots this broken - and that it still hasn't been fixed, and AIUI never will be fixed because GNOME seems to think that the situation doesn't need fixing - is a fairly damning incitement of Wayland as a whole. > Is that true? My understanding was that GNOME never put forth a protocol but always did their dbus thing. I know that wlroots proposed a bunch of protocol extensions but those never went anywhere since, well, GNOME didn't want to implement them[1]. Nowadays I think every compositor(?) just implements the xdg-portal stuff. I think it's true, though it's honestly hard to tell. Most of the screenshot tools I could find are using the wlroots protocol, KDE's official tool notes, > Spectacle is a screenshot taking utility for the KDE desktop. Spectacle can also be used in non-KDE X11 desktop environments. which doesn't really explicitly say much, and in fact the only tool I could find that claimed to be able to support everything was ksnip, which seems to work fine with wlroots but beyond that https://github.com/ksnip/ksnip#known-issues https://github.com/ksnip/ksnip#known-issues outlines the situation well enough; KDE is at least only temporarily broken, but GNOME isn't going to improve because GNOME did that on purpose. Now, that readme says you can use xdg-desktop-portal, but I have a GNOME+Wayland machine on hand, and I couldn't get it to actually work. I think what's supposed to happen is that every time I do a screenshot it prompts for permission, which I wanted to verify so I could complain that that was totally unreasonable, but what actually happens is that it just fails, which is... not better. Oh, and while searching for solutions to that I found flameshot, but that just refuses to even run. So... maybe someday the portal solution will work; in the meantime, I feel comfortable describing the situation as Wayland not having a uniform working way of taking screenshots. [0] In particular, so we can avoid the situation from X11 where a load of drawing primitives are baked in that nobody has any use for anymore.
    - csande17 3y ago
      You definitely get discrepancies in hardware support. Historically, different Wayland desktops had wildly differing support for Nvidia cards, for example, from "works perfectly" to "deliberately rejects them because the maintainer is angry about their lack of commitment to Wayland".
- zlg_codes 3y ago
  What semantics do you think you're conveying? If you implement the protocol, you have a server. A protocol without a server implementation is useless.
- bitwize 3y ago
  So is X11. Xorg is a server.
MadnessASAP 3y ago
There's been volumes written about the problems with X and what would've been done differently. Of course given enough time I'm sure Wayland will end up in the same place, it does have the advantage that it was designed to be extended upon and for implementations to be built from interoperating components (vs the monolithic Xorg). The big difference really comes down too that X was designed to connect applications, input devices, and displays (including printers!!) across a network in a time when the concept of a untrusted network didn't really exist. Neither was there a concept of a GPU as they exist now. Conversely Wayland was designed to connect those items (sans printers) within a computer and to default to providing the minimum amount of trust to those things, particularly applications.
- yjftsjthsd-h 3y ago
  I don't think the network thing actually matters; modern Xorg doesn't expose anything to the network by default, and IIRC will actually fight you about trying to do so to the extent that when I wanted to use it that way I ended up using socat to bridge TCP to the local socket. The general comment about trust and security is true, though; ex. the usual complaints about any X11 application being able to keylog any other (which XACE exists to counter, but since nobody seems to have done so I'm assuming it had problems!?)).
  - cptskippy 3y ago
    > I don't think the network thing actually matters; modern Xorg doesn't expose anything to the network by default... It matters from the design and architecture perspective. It's foundational underpinnings we're constructed to support remote terminals. That really hasn't been a usecase for a very long time but the core architecture was built with that in mind and the monolithic nature of the code makes it very hard to change that.
roenxi 3y ago
The issues that got us to where we are with X are twofold and unlikely to repeat: 1) The nature of the hardware changed completely. The core X protocol [0] was designed around 2D shapes and is prepared to do things like FillPoly or PutImage. This means it was largely caught unaware by the move to shader-based graphics and the absurd amount of processing power we have todaty in graphics cards. Wayland from what I understand just manages buffers which is better design. Things like OpenGL were tacked on to X as an extension, and now pretty much everything wants to be handled through OpenGal, but the X design wasn't prepared for that. 2) That would have been enough to kill X from what I've seen, but ... the major vendors had horrible binary drivers that only supported X, so every fork or new project died. The big change was AMD buying ATI and taking the drivers open source from 2007, since then there have been the sound of plate tectonics as the Linux graphic stack has reformed because now it is possible to develop deep in the graphics stack independently of AMD/Nvidia support. Note that if Wayland needed to work well on Nvidia it would have likely died a decade ago. So the positive things are Wayland probably won't be hit by the same level of hardware change, and if it is it is much easier to replace. Really what has changed is that the majority of vendors have open source drivers, and Nvidia is eventually going to fold and join the club. Not that it matters, anyone who cares in the Linux ecosystem buys AMD - this deep learning thing has been an unfortunate stumbling block but that looks like it will be transient to me. [0] https://x.org/releases/X11R7.7/doc/xproto/x11protocol.html https://x.org/releases/X11R7.7/doc/xproto/x11protocol.html
eadmund 3y ago
The cascade of attention-deficit teenagers pinky-promise that it won’t. Meanwhile, I understand that Wayland in 2023 still doesn’t support what X11 supported in 2000. If true, then it’s simply not fit for purpose.
1oooqooq 3y ago
> confidence wayland wont end up in a similar state? wayland have the issues of today. So they are not the same as the issues of yesterday like x11. guaranteed a different state! In ten years you will probably be crying that opening a window on wayland requires you to enter a hostname which is long gone into your etc hosts file, pointing to a local server, so it can download the window theme on the fly, as root, or something. You know, today's problems.
bsder 3y ago
Wayland is already there. However, the fundamental problem is that Linux is the only OS with more than one GUI toolkit. This means that you have to insert extra layers of abstractions that other OSes don't deal with. Every other OS has a native toolkit which is integrated with native drivers. The GUI and compositor and OS go together. And even those have lots of issues. When you try to sidestep that integration, you get lots of jank and problems (see: Flutter, for example). Wayland and Co. are wrangling a bear that other companies struggle with with way less resource and way less control over the interlocking layers.
- gaganyaan 3y ago
  What counts as a GUI toolkit? Microsoft has like a half dozen dead or deprecated attempts at GUI frameworks, unless you're using a different definition.
  - simoncion 3y ago
    > Microsoft has like a half dozen dead or deprecated attempts at GUI frameworks... In addition to the major ones that are supported in X11 / Wayland!
  - bsder 3y ago
    Pick one. And note that all of those GUI toolkits still work on Windows 11, AFAICT. Touch screens work even on old VB6 programs, for example. Try that on Linux and watch the tears flow. This is my point. Everything is locked together and tested together. The OS, the toolkit, the input mechanism, the video driver, etc. all get developed together and don't need 4 layers of ill-defined abstraction between them.

What lessons have been learned and what has changed that give confidence wayland wont end up in a similar state?

dralley 3y ago

To start with, Wayland isn't a server, it's a protocol.

yobert 3y ago
X11 is a protocol too :p
yjftsjthsd-h 3y ago
That just pushes the problem to the compositors
- hsbauauvhabzb 3y ago
  Does the multiple compositor situation result in duplicated effort and/or constraints for the end user such as being unable to run Konsole on Gnome3 etc?
  - yjftsjthsd-h 3y ago
    My understanding is that simple applications like Konsole should be fine because they only use widely-implemented protocols. Where it goes off the rails is when you want to do exotic things like take a screenshot, and GNOME, KDE, and wlroots have each implemented a different protocol to do so.
    - t0b1 3y ago
      > exotic things like take a screenshot I'm not sure but is this meant ironically? Because taking a screenshot is a thing people do very often. Capturing your screen is, too. Even by third-party programs. And yet they never put it in the protocol but just said to go to dbus. > GNOME, KDE, and wlroots have each implemented a different protocol Is that true? My understanding was that GNOME never put forth a protocol but always did their dbus thing. I know that wlroots proposed a bunch of protocol extensions but those never went anywhere since, well, GNOME didn't want to implement them[1]. Nowadays I think every compositor(?) just implements the xdg-portal stuff. [1]: https://gitlab.freedesktop.org/wayland/wayland/-/issues/32#note_367228 https://gitlab.freedesktop.org/wayland/wayland/-/issues/32#n...
      - eadmund 3y ago
        I think to the Wayland folks, anything other than using Windows is an exotic use case. They’re not entirely wrong, but if we wanted to use Windows, we … would be using Windows. The great thing about Linux was that we could do more than Windows or macOS permitted.
        jdiff 3y ago
        Weird take. Windows and macOS both let you do things Wayland doesn't currently have widely adopted protocols for. Only thing Xorg can do that any of the others can't is let a client application manage windows, and it's only macOS that really doesn't like that.
      - yjftsjthsd-h 3y ago
        > I'm not sure but is this meant ironically? Because taking a screenshot is a thing people do very often. Yes, I was intending to mock Wayland for failing, after 15 years of development, to have a single way of taking screenshots that works in all environments. I understand wanting to make things modular and flexible and make as much optional as possible[0], and I understand wanting to ship the core protocol first and then follow up with drafting other things and building consensus, but the fact that this thing was allowed to hit end-users with screenshots this broken - and that it still hasn't been fixed, and AIUI never will be fixed because GNOME seems to think that the situation doesn't need fixing - is a fairly damning incitement of Wayland as a whole. > Is that true? My understanding was that GNOME never put forth a protocol but always did their dbus thing. I know that wlroots proposed a bunch of protocol extensions but those never went anywhere since, well, GNOME didn't want to implement them[1]. Nowadays I think every compositor(?) just implements the xdg-portal stuff. I think it's true, though it's honestly hard to tell. Most of the screenshot tools I could find are using the wlroots protocol, KDE's official tool notes, > Spectacle is a screenshot taking utility for the KDE desktop. Spectacle can also be used in non-KDE X11 desktop environments. which doesn't really explicitly say much, and in fact the only tool I could find that claimed to be able to support everything was ksnip, which seems to work fine with wlroots but beyond that https://github.com/ksnip/ksnip#known-issues https://github.com/ksnip/ksnip#known-issues outlines the situation well enough; KDE is at least only temporarily broken, but GNOME isn't going to improve because GNOME did that on purpose. Now, that readme says you can use xdg-desktop-portal, but I have a GNOME+Wayland machine on hand, and I couldn't get it to actually work. I think what's supposed to happen is that every time I do a screenshot it prompts for permission, which I wanted to verify so I could complain that that was totally unreasonable, but what actually happens is that it just fails, which is... not better. Oh, and while searching for solutions to that I found flameshot, but that just refuses to even run. So... maybe someday the portal solution will work; in the meantime, I feel comfortable describing the situation as Wayland not having a uniform working way of taking screenshots. [0] In particular, so we can avoid the situation from X11 where a load of drawing primitives are baked in that nobody has any use for anymore.
  - csande17 3y ago
    You definitely get discrepancies in hardware support. Historically, different Wayland desktops had wildly differing support for Nvidia cards, for example, from "works perfectly" to "deliberately rejects them because the maintainer is angry about their lack of commitment to Wayland".
zlg_codes 3y ago
What semantics do you think you're conveying? If you implement the protocol, you have a server. A protocol without a server implementation is useless.
bitwize 3y ago
So is X11. Xorg is a server.

MadnessASAP 3y ago

There's been volumes written about the problems with X and what would've been done differently. Of course given enough time I'm sure Wayland will end up in the same place, it does have the advantage that it was designed to be extended upon and for implementations to be built from interoperating components (vs the monolithic Xorg). The big difference really comes down too that X was designed to connect applications, input devices, and displays (including printers!!) across a network in a time when the concept of a untrusted network didn't really exist. Neither was there a concept of a GPU as they exist now. Conversely Wayland was designed to connect those items (sans printers) within a computer and to default to providing the minimum amount of trust to those things, particularly applications.

yjftsjthsd-h 3y ago
I don't think the network thing actually matters; modern Xorg doesn't expose anything to the network by default, and IIRC will actually fight you about trying to do so to the extent that when I wanted to use it that way I ended up using socat to bridge TCP to the local socket. The general comment about trust and security is true, though; ex. the usual complaints about any X11 application being able to keylog any other (which XACE exists to counter, but since nobody seems to have done so I'm assuming it had problems!?)).
- cptskippy 3y ago
  > I don't think the network thing actually matters; modern Xorg doesn't expose anything to the network by default... It matters from the design and architecture perspective. It's foundational underpinnings we're constructed to support remote terminals. That really hasn't been a usecase for a very long time but the core architecture was built with that in mind and the monolithic nature of the code makes it very hard to change that.

roenxi 3y ago

The issues that got us to where we are with X are twofold and unlikely to repeat: 1) The nature of the hardware changed completely. The core X protocol [0] was designed around 2D shapes and is prepared to do things like FillPoly or PutImage. This means it was largely caught unaware by the move to shader-based graphics and the absurd amount of processing power we have todaty in graphics cards. Wayland from what I understand just manages buffers which is better design. Things like OpenGL were tacked on to X as an extension, and now pretty much everything wants to be handled through OpenGal, but the X design wasn't prepared for that. 2) That would have been enough to kill X from what I've seen, but ... the major vendors had horrible binary drivers that only supported X, so every fork or new project died. The big change was AMD buying ATI and taking the drivers open source from 2007, since then there have been the sound of plate tectonics as the Linux graphic stack has reformed because now it is possible to develop deep in the graphics stack independently of AMD/Nvidia support. Note that if Wayland needed to work well on Nvidia it would have likely died a decade ago. So the positive things are Wayland probably won't be hit by the same level of hardware change, and if it is it is much easier to replace. Really what has changed is that the majority of vendors have open source drivers, and Nvidia is eventually going to fold and join the club. Not that it matters, anyone who cares in the Linux ecosystem buys AMD - this deep learning thing has been an unfortunate stumbling block but that looks like it will be transient to me. [0] https://x.org/releases/X11R7.7/doc/xproto/x11protocol.html https://x.org/releases/X11R7.7/doc/xproto/x11protocol.html

eadmund 3y ago

The cascade of attention-deficit teenagers pinky-promise that it won’t. Meanwhile, I understand that Wayland in 2023 still doesn’t support what X11 supported in 2000. If true, then it’s simply not fit for purpose.

1oooqooq 3y ago

> confidence wayland wont end up in a similar state? wayland have the issues of today. So they are not the same as the issues of yesterday like x11. guaranteed a different state! In ten years you will probably be crying that opening a window on wayland requires you to enter a hostname which is long gone into your etc hosts file, pointing to a local server, so it can download the window theme on the fly, as root, or something. You know, today's problems.

bsder 3y ago

Wayland is already there. However, the fundamental problem is that Linux is the only OS with more than one GUI toolkit. This means that you have to insert extra layers of abstractions that other OSes don't deal with. Every other OS has a native toolkit which is integrated with native drivers. The GUI and compositor and OS go together. And even those have lots of issues. When you try to sidestep that integration, you get lots of jank and problems (see: Flutter, for example). Wayland and Co. are wrangling a bear that other companies struggle with with way less resource and way less control over the interlocking layers.

gaganyaan 3y ago
What counts as a GUI toolkit? Microsoft has like a half dozen dead or deprecated attempts at GUI frameworks, unless you're using a different definition.
- simoncion 3y ago
  > Microsoft has like a half dozen dead or deprecated attempts at GUI frameworks... In addition to the major ones that are supported in X11 / Wayland!
- bsder 3y ago
  Pick one. And note that all of those GUI toolkits still work on Windows 11, AFAICT. Touch screens work even on old VB6 programs, for example. Try that on Linux and watch the tears flow. This is my point. Everything is locked together and tested together. The OS, the toolkit, the input mechanism, the video driver, etc. all get developed together and don't need 4 layers of ill-defined abstraction between them.