5 ms·

This link comes up in literally every Wayland thread and it is even more bullshit now than it was in 2013 when it was first posted (and it was bullshit then too

This link comes up in literally every Wayland thread and it is even more bullshit now than it was in 2013 when it was first posted (and it was bullshit then too). It is titled "the real story" but it is quite the opposite. A few key points: 1) he laughs at how X has a bunch of extensions. https://wayland.app/protocols/ https://wayland.app/protocols/ hypocrites much. In 2013, since it was completely unusable, it probably didn't have many. But turns out real world use leads to "useless" features being reimplemented. 2) he complains about how X.org has broad hardware compatibility. As if that's a bad thing. Meanwhile wayland, even now it still doesn't work reliably on half the graphics chips on the market. 3) It complains that certain X features are not fully network transparent. True, but most are and you can detect at runtime and gracefully degrade. Wayland "fixes" this by just dropping the whole feature. 4) it flat-out lies saying the X server does nothing yet it is so much hard to maintain code. The core X protocol provides backward compatibility and is rock solid (and really easy to impelment from scratch btw, someone did it in Javascript for a tutorial for crying out loud). Meanwhile the Wayland compositor keeps accumulating everything because of point 1. Need a screenshot? Add it it the compositor. Need a hotkey? Add it to the compositor. Need drag and drop? Add it to the compositor. Need a notification icon? Add it to the compositor. In X, all those are peer to peer. Graphics are actually a relatively small part of a graphical user interface, something Wayland is still slow to learn. 5) He complains that certain applications are written inefficiently with blocking calls which is inefficient over a network connection. Wayland's calls are ALL blocking and just has no network connection. 6) Complains that X may draw things unnecessarily. Indeed... but there's an extension to disable that. Easy fix. Wayland even uses the same drivers!

vetinari 4y ago
1) no, he complains that X11 has a big core and then extensions. Extensions are fine, but they were unable to kick out parts of the core, because it is the core and something somewhere assumes it is there. So they had to maintain it, despite not being used in practice, except by that little something that nobody can point their fingers at. 2) he talks about obsolete hardware. There's no really a point to support s3 trio, at the expense of support for modern hardware, which works ink wastly different way. 3) That graceful degradation is in practice the same, as just using Wayland. Ever tried to use modern X11 app over network? RDP is vastly better experience, (and RDP support is wip in wayland). 4) This is so wrong so I won't even react to it. 5) Wayland calls do not wait for reply. You rapid fire requests and then collect responses as they come. Heck, you can even get a response you didn't ask for ;)
- kelnos 4y ago
  > he complains that X11 has a big core and then extensions. Extensions are fine, but they were unable to kick out parts of the core, because it is the core and something somewhere assumes it is there. The thing that I find ridiculous about this attitude is that you have two choices: 1) Remove parts of the core that some (mostly old, unmaintained) applications rely on, which will break them. You'd probably have to call it "X12" now, but that's fine: most X11 applications would continue to work with no (or very few) modifications. 2) Throw out the entire system and build a new one from scratch, that literally no applications will work on until new toolkit backends are written and some applications themselves are rewritten or at least fixed up. Those same old, possibly unmaintained apps that would stop working in #1 are still not working, but now it's along with literally everything else too. > RDP support is wip in wayland If I had a dollar for every time I heard "$IMPORTANT_FEATURE is WIP in Wayland", I'd be able to get several pizzas delivered.
  - throwawaylinux 4y ago
    3) Build a new system that supports the old system reasonably well and doesn't prevent people using and improving the old system until the new one meets their needs. > If I had a dollar for every time I heard "$IMPORTANT_FEATURE is WIP in Wayland", I'd be able to get several pizzas delivered. It's true though there have been features missing. It's good thing that they are being worked on though, no? The X protocol and the Xorg implementation are both abandonware, so your comment comes across as positive, because missing $IMPORTANT_FEATURE in X/Xorg is not WIP.
- destructionator 4y ago
  > That graceful degradation is in practice the same, as just using Wayland. Ever tried to use modern X11 app over network? RDP is vastly better experience, (and RDP support is wip in wayland). I do, in fact, use modern X11 apps over the network literally every day. Some are better than others - if the programmer made the effort to actually gracefully degrade it can be a considerably better experience than the ones who just shoot a constant stream of bitmaps down the wire (which do work better on rdp, i remember once upon a time, I'd ssh to my linux box and set up port forwarding to a windows box on my lan so i can remote desktop to it, then run Xming from there... which is absurd that that actually worked better), but if you do it well, remote X is very nice to use. The seamless integration of windows from multiple computers is a thing to behold. Remote Desktop is great and I like a lot about it, but even the "Seamless" rdp doesn't work as nice as X.
kelnos 4y ago
> Graphics are actually a relatively small part of a graphical user interface, something Wayland is still slow to learn. This I think is a key insight. I talk about this in another post, but I've been working on "porting" parts of Xfce to Wayland, and there are so many things missing in Wayland that have nothing to do with "graphics" that means that Xfce+Wayland will be missing a lot of useful features until/unless Wayland protocols are invented or extended to make them work.
- happymellon 4y ago
  This sounds suspiciously like the conversations around "just use OpenGL/Vulkan instead of DirectX". Because DirectX is more than just Direct3D?
  - vetinari 4y ago
    Used to be; meanwhile, DirectDraw/DirectInput/DirectSound/DirectPlay/etc have been dead for quite a while.
    - happymellon 4y ago
      I don't do Windows development, but I remember that used to be the rebuttal from game devs that Linux missed the point about all the ease of use features that Microsoft provided. Although all the other Direct services are dead, have they not been replaced with new versions?
      - vetinari 4y ago
        And it was true at the time, thought the rebuttal would be "use SDL then" -- it did provide equivalent functionality, packaged into a single library. They were replaced not by new versions, but by new or even existing libraries/subsystems, that are not marketed as Direct anything anymore. Just like alsa or pulse are not marketed as SDL or Open anything either.
        4y ago
chlorion 4y ago
None of Waylands internal functions between a client and compositor are blocking or synchronous to my knowledge. Generally you fire off a message and will later receive an event back from the compositor, which is happening in an event loop. There is an exception, which is the explicitly blockling "roundtrip" function(s), but that is meant for special cases only. Being asynchronous was an design goal for Wayland from the very beginning.
- destructionator 4y ago
  This isn't that different than X though which also has the fire off a message and receive event back. Very few of the functions actually make you want (even in xlib, which wraps the protocol itself to be a bit easier to use from C, the majority of functions still are async - much to the chagrin of newbies trying to decipher error messages)
  - throwawaylinux 4y ago
    What do you mean by all Wayland's calls being blocking though?
    - destructionator 4y ago
      It isn't really Wayland's calls itself, I prolly stretched too much there, but the main thing is the async discussion usually comes up in the context of running applications remotely, which Wayland simply doesn't support. If you do a loop of XInternAtom (which btw you shouldn't do, even in xlib - notice that there's also XInternAtoms, plural, for that kind of thing which batches them to reduce wait time...) locally, it is unlikely to matter. The time spent there is near zero anyway. But remotely, now you might be looking at several ms per iteration and that adds up fast. Now the blocking aspect can become problematic. Since Wayland doesn't support this kind of network remote use anyway, the distinction doesn't matter. Local X vs Wayland are both fast.
      - throwawaylinux 4y ago
the_only_law 4y ago
> The core X protocol provides backward compatibility I had a bit of fun a while back trying to get an old X/11 terminal to work with a modern Linux machine and was somewhat surprised I was able to make it work. Sort of at least. Many display managers didn’t implement the proper protocols, but XDM did and I was able to get it to work at least a few times.

vetinari 4y ago

1) no, he complains that X11 has a big core and then extensions. Extensions are fine, but they were unable to kick out parts of the core, because it is the core and something somewhere assumes it is there. So they had to maintain it, despite not being used in practice, except by that little something that nobody can point their fingers at. 2) he talks about obsolete hardware. There's no really a point to support s3 trio, at the expense of support for modern hardware, which works ink wastly different way. 3) That graceful degradation is in practice the same, as just using Wayland. Ever tried to use modern X11 app over network? RDP is vastly better experience, (and RDP support is wip in wayland). 4) This is so wrong so I won't even react to it. 5) Wayland calls do not wait for reply. You rapid fire requests and then collect responses as they come. Heck, you can even get a response you didn't ask for ;)

kelnos 4y ago
> he complains that X11 has a big core and then extensions. Extensions are fine, but they were unable to kick out parts of the core, because it is the core and something somewhere assumes it is there. The thing that I find ridiculous about this attitude is that you have two choices: 1) Remove parts of the core that some (mostly old, unmaintained) applications rely on, which will break them. You'd probably have to call it "X12" now, but that's fine: most X11 applications would continue to work with no (or very few) modifications. 2) Throw out the entire system and build a new one from scratch, that literally no applications will work on until new toolkit backends are written and some applications themselves are rewritten or at least fixed up. Those same old, possibly unmaintained apps that would stop working in #1 are still not working, but now it's along with literally everything else too. > RDP support is wip in wayland If I had a dollar for every time I heard "$IMPORTANT_FEATURE is WIP in Wayland", I'd be able to get several pizzas delivered.
- throwawaylinux 4y ago
  3) Build a new system that supports the old system reasonably well and doesn't prevent people using and improving the old system until the new one meets their needs. > If I had a dollar for every time I heard "$IMPORTANT_FEATURE is WIP in Wayland", I'd be able to get several pizzas delivered. It's true though there have been features missing. It's good thing that they are being worked on though, no? The X protocol and the Xorg implementation are both abandonware, so your comment comes across as positive, because missing $IMPORTANT_FEATURE in X/Xorg is not WIP.
destructionator 4y ago
> That graceful degradation is in practice the same, as just using Wayland. Ever tried to use modern X11 app over network? RDP is vastly better experience, (and RDP support is wip in wayland). I do, in fact, use modern X11 apps over the network literally every day. Some are better than others - if the programmer made the effort to actually gracefully degrade it can be a considerably better experience than the ones who just shoot a constant stream of bitmaps down the wire (which do work better on rdp, i remember once upon a time, I'd ssh to my linux box and set up port forwarding to a windows box on my lan so i can remote desktop to it, then run Xming from there... which is absurd that that actually worked better), but if you do it well, remote X is very nice to use. The seamless integration of windows from multiple computers is a thing to behold. Remote Desktop is great and I like a lot about it, but even the "Seamless" rdp doesn't work as nice as X.

kelnos 4y ago

> Graphics are actually a relatively small part of a graphical user interface, something Wayland is still slow to learn. This I think is a key insight. I talk about this in another post, but I've been working on "porting" parts of Xfce to Wayland, and there are so many things missing in Wayland that have nothing to do with "graphics" that means that Xfce+Wayland will be missing a lot of useful features until/unless Wayland protocols are invented or extended to make them work.

happymellon 4y ago
This sounds suspiciously like the conversations around "just use OpenGL/Vulkan instead of DirectX". Because DirectX is more than just Direct3D?
- vetinari 4y ago
  Used to be; meanwhile, DirectDraw/DirectInput/DirectSound/DirectPlay/etc have been dead for quite a while.
  - happymellon 4y ago
    I don't do Windows development, but I remember that used to be the rebuttal from game devs that Linux missed the point about all the ease of use features that Microsoft provided. Although all the other Direct services are dead, have they not been replaced with new versions?
    - vetinari 4y ago
      And it was true at the time, thought the rebuttal would be "use SDL then" -- it did provide equivalent functionality, packaged into a single library. They were replaced not by new versions, but by new or even existing libraries/subsystems, that are not marketed as Direct anything anymore. Just like alsa or pulse are not marketed as SDL or Open anything either.
      - 4y ago

chlorion 4y ago

None of Waylands internal functions between a client and compositor are blocking or synchronous to my knowledge. Generally you fire off a message and will later receive an event back from the compositor, which is happening in an event loop. There is an exception, which is the explicitly blockling "roundtrip" function(s), but that is meant for special cases only. Being asynchronous was an design goal for Wayland from the very beginning.

destructionator 4y ago
This isn't that different than X though which also has the fire off a message and receive event back. Very few of the functions actually make you want (even in xlib, which wraps the protocol itself to be a bit easier to use from C, the majority of functions still are async - much to the chagrin of newbies trying to decipher error messages)
- throwawaylinux 4y ago
  What do you mean by all Wayland's calls being blocking though?
  - destructionator 4y ago
    It isn't really Wayland's calls itself, I prolly stretched too much there, but the main thing is the async discussion usually comes up in the context of running applications remotely, which Wayland simply doesn't support. If you do a loop of XInternAtom (which btw you shouldn't do, even in xlib - notice that there's also XInternAtoms, plural, for that kind of thing which batches them to reduce wait time...) locally, it is unlikely to matter. The time spent there is near zero anyway. But remotely, now you might be looking at several ms per iteration and that adds up fast. Now the blocking aspect can become problematic. Since Wayland doesn't support this kind of network remote use anyway, the distinction doesn't matter. Local X vs Wayland are both fast.
    - throwawaylinux 4y ago

the_only_law 4y ago

> The core X protocol provides backward compatibility I had a bit of fun a while back trying to get an old X/11 terminal to work with a modern Linux machine and was somewhat surprised I was able to make it work. Sort of at least. Many display managers didn’t implement the proper protocols, but XDM did and I was able to get it to work at least a few times.