5 ms·

In X11 we kept things simple by offering: * Core protocol drawing (lines, rectangles, arcs, the classics) * XRender for compositing and alpha * XShm for shar

In X11 we kept things simple by offering: * Core protocol drawing (lines, rectangles, arcs, the classics) * XRender for compositing and alpha * XShm for shared-memory blits * GLX if you felt like bringing a GPU to a 2D fight * XVideo for overlay video paths * Pixmaps vs Windows, because why have one drawable when you can have two subtly different ones * And of course, indirect rendering over the network if you enjoy latency as a design constraint

smackeyacky 6mo ago
And it worked very well for a remarkably long time. Even over dialup if you were patient. It still seems bizarre that the security flaws couldn’t be addressed, I never understood the Wayland push and I still don’t.
- UltraSane 6mo ago
  Once applications moved local and GPUs became the rendering path X11's network transparency became pure overhead for 99% of users. Wayland fixes this by making shared-memory buffers the core primitive and remote access a separate concern.
  - cindyllm 6mo ago
    [dead]
  - Underphil 6mo ago
    ...and then you have long time Linux users (like me) who cannot feel any of the benefit of removing that overhead. The only difference I can tell between X and Wayland on my machines is that Wayland doesn't work with some stuff.
    - UltraSane 6mo ago
      I'm pretty sure it simplifies the code a lot.
      - flohofwoe 6mo ago
        That doesn't help when the code talking to Wayland becomes much more complicated.
        gf000 6mo ago
        Why would it be more complicated? Most apps are just using GTK and qt and doesn't even care about their x or Wayland backends.
        rbanffy 6mo ago
        This is what I was thinking when I read this. Wouldn't it just be easier to use GTK (or Qt) everywhere? They are already well supported on every other platform and can look very native the last time I checked.
        flohofwoe 6mo ago
        > Wouldn't it just be easier to use GTK (or Qt) everywhere? Which of those? GTK apps look alien on KDE desktops, and Qt apps look alien on GNOME desktops. Also, if you only need to create a window with a GL or Vulkan canvas, pulling in an entire UI framework dependency is overkill. There's SDL, GLFW, winit etc etc - but those also don't fix the 'native window chrome' problem in all situations and they all have to work around missing Wayland features. The bare window system functionality (managing windows - including window chrome and positioning(!), clipboard, drag'n'drop, ...) should really be part of the OS APIs (like it is on *every other* desktop operating system). Why does desktop Linux have to do its own thing, and worse (in the sense of: more developer hostile) than other desktop operating systems?
        gf000 6mo ago
        Frankly I don't get your problem or how is it different on any other OS. So your solution to GTK or qt looking alien is to look alien to everyone? Like there is no universe where "GTK doesn't look good, I will go with a custom written vulkan canvas" is a realistic scenario. Especially when all this has been blown way out of proportion when companies happily wrap their web apps into a browser and ship it as their software. So again, how is it different elsewhere? What about windows, where even their own frameworks look alien because they have 3-4 of them? How is that the fault of Wayland somehow?!
    - redeeman 6mo ago
      and then there are probably as many if not more that notice zero difference at all. and a sizable amount of people who notice things that are BETTER, such as for example actual support for HDR and 10bit, per-screen refresh rates etc
  - whizzter 6mo ago
    Not to mention that the complexity of X11 shots through the roof once shared buffers comes into play. X11 was ok for it's time, but fundamentally it's an really outdated design to solve 80s/90s issues over the network in the way you solved it back then.
    - UltraSane 6mo ago
      It is INCREDIBLY outdated and forces all graphics to flow through a crappy 80s era network protocol even when there is no network. It is the recurrent laryngeal nerve of graphics technology.
  - aragilar 6mo ago
    Is it 99% of users? Of the linux (desktop/laptop) users I know, the majority use X-forwarding over ssh at least occasionally, while non-linux (desktop/laptop) also use X-forwarding (this is in an academic context), so while this may be an improvement for a subset of linux (desktop/laptop) users, across the whole linux user base (excluding both Android, which does not use wayland, and embedded, which I understand does use wayland), it's not.
    - UltraSane 6mo ago
      X-forwarding isn't used nearly enough to justify it having to be used all the time.
    - rbanffy 6mo ago
      I don't think I have used X-forwarding in the last 10 years unless for checking whether it's still there. Most of the time, it was, and running a browser even on a nearby machine was not a pleasant experience. Running Emacs was less bad, but the only things that actually worked well were probably xlogo and xload.
  - flohofwoe 6mo ago
    If Wayland doesn't need network transparency why do Wayland clients and "server" still communicate through a socket though? Why not use a much simpler command buffer model like on 3D APIs, and only for actually asynchronous commands (but not simple synchronous getters)? PS: is io_uring using sockets for its "shared memory ringbuffers"? If not why? Too much overhead? And if there's notable socket overhead, why is Wayland using sockets (since it has to solve a simar problem as io_uring or 3D APIs).
    - gf000 6mo ago
      It's only using sockets to pass a handle to a buffer though. Sockets are plenty fast, but not moving stuff in the first place can't be beaten.
- sho_hn 6mo ago
  > I never understood the Wayland push and I still don’t. What happened is basically this: - X11 was fairly complex, had a lot of dead-weight code, and a whole bunch of fundamental issues that were building up to warrant an "X12" and breaking the core protocols to get fixed. - Alongside this, at some point in the relatively distant past, the XFree86 implementation (the most used one at the time, which later begat Xorg) was massively fat and did a huge amount of stuff, including driver-level work - think "PCI in userspace". - Over the years, more and more of the work moved out of the X server and into e.g. the Linux kernel. Drivers, mode setting, input event handling, higher-level input event handling (libinput). Xorg also got a bit cleaner and modularized, making some of the remaining hard bits available in library form (e.g. xkb). - With almost everything you need for a windowing system now cleanly factored out and no longer in X, trying out a wholly new windowing system suddenly became a tractable problem. This enabled the original Wayland author to attempt it and submit it for others to appraise. - A lot of the active X and GUI developer liked what they saw and it managed to catch on. - A lot of the people involved were in fact not naive, and did not ignore the classic "should you iterate or start over" conundrum. Wayland had a fairly strong backward compat story very early on in the form of Xwayland, which was created almost immediately, and convinced a lot of people. In the end this is a very classic software engineering story. Would it have been possible to iterate X11 toward what Wayland is now in-place? Maybe. Not sure. Would the end result look a lot like Wayland today? Probably, the Wayland design is still quite good and modern. It's a lot like Python 2.x vs. 3.x in the end.
- gf000 6mo ago
  It never worked very well - in the age of bitmaps (and that's not a recent invention) that ultra-dumb pixel pushing simply no longer scales. We have eons better ways to transport graphical buffers around (also, what about sound? That seems reasonable - but now should the display server also be a sound server?), so building it into such a core protocol just doesn't make sense.
anthk 6mo ago
Not very different from Windows: - Modern DX and old Direct Draw games often was a clusterfuck in order to keep them running fast in Windows 8 and up. - XVideo and overlay video for Windows were 100% the same; green glitches on drawing, blue screens on screnshots et all. - Same issue in Windows with pixmaps. - RDP was fine there, even Gnome adopted it. But I prefer 9front's transparency, you don't need to get everything from the host to use it, with 9front you can just get the device you want, you can decouple auth from the GUI and a lot more, even the network and audio devices. Much fetter than X11's remote setups, VNC, RDP and whatnot.
- rbanffy 6mo ago
  9front is nice, but I'm not sure how much you'd get out of it without implementing the rest of Plan 9 in the target OS.

smackeyacky 6mo ago

And it worked very well for a remarkably long time. Even over dialup if you were patient. It still seems bizarre that the security flaws couldn’t be addressed, I never understood the Wayland push and I still don’t.

UltraSane 6mo ago
Once applications moved local and GPUs became the rendering path X11's network transparency became pure overhead for 99% of users. Wayland fixes this by making shared-memory buffers the core primitive and remote access a separate concern.
- cindyllm 6mo ago
  [dead]
- Underphil 6mo ago
  ...and then you have long time Linux users (like me) who cannot feel any of the benefit of removing that overhead. The only difference I can tell between X and Wayland on my machines is that Wayland doesn't work with some stuff.
  - UltraSane 6mo ago
    I'm pretty sure it simplifies the code a lot.
    - flohofwoe 6mo ago
      That doesn't help when the code talking to Wayland becomes much more complicated.
      - gf000 6mo ago
        Why would it be more complicated? Most apps are just using GTK and qt and doesn't even care about their x or Wayland backends.
        rbanffy 6mo ago
        This is what I was thinking when I read this. Wouldn't it just be easier to use GTK (or Qt) everywhere? They are already well supported on every other platform and can look very native the last time I checked.
        flohofwoe 6mo ago
        > Wouldn't it just be easier to use GTK (or Qt) everywhere? Which of those? GTK apps look alien on KDE desktops, and Qt apps look alien on GNOME desktops. Also, if you only need to create a window with a GL or Vulkan canvas, pulling in an entire UI framework dependency is overkill. There's SDL, GLFW, winit etc etc - but those also don't fix the 'native window chrome' problem in all situations and they all have to work around missing Wayland features. The bare window system functionality (managing windows - including window chrome and positioning(!), clipboard, drag'n'drop, ...) should really be part of the OS APIs (like it is on *every other* desktop operating system). Why does desktop Linux have to do its own thing, and worse (in the sense of: more developer hostile) than other desktop operating systems?
        gf000 6mo ago
        Frankly I don't get your problem or how is it different on any other OS. So your solution to GTK or qt looking alien is to look alien to everyone? Like there is no universe where "GTK doesn't look good, I will go with a custom written vulkan canvas" is a realistic scenario. Especially when all this has been blown way out of proportion when companies happily wrap their web apps into a browser and ship it as their software. So again, how is it different elsewhere? What about windows, where even their own frameworks look alien because they have 3-4 of them? How is that the fault of Wayland somehow?!
  - redeeman 6mo ago
    and then there are probably as many if not more that notice zero difference at all. and a sizable amount of people who notice things that are BETTER, such as for example actual support for HDR and 10bit, per-screen refresh rates etc
- whizzter 6mo ago
  Not to mention that the complexity of X11 shots through the roof once shared buffers comes into play. X11 was ok for it's time, but fundamentally it's an really outdated design to solve 80s/90s issues over the network in the way you solved it back then.
  - UltraSane 6mo ago
    It is INCREDIBLY outdated and forces all graphics to flow through a crappy 80s era network protocol even when there is no network. It is the recurrent laryngeal nerve of graphics technology.
- aragilar 6mo ago
  Is it 99% of users? Of the linux (desktop/laptop) users I know, the majority use X-forwarding over ssh at least occasionally, while non-linux (desktop/laptop) also use X-forwarding (this is in an academic context), so while this may be an improvement for a subset of linux (desktop/laptop) users, across the whole linux user base (excluding both Android, which does not use wayland, and embedded, which I understand does use wayland), it's not.
  - UltraSane 6mo ago
    X-forwarding isn't used nearly enough to justify it having to be used all the time.
  - rbanffy 6mo ago
    I don't think I have used X-forwarding in the last 10 years unless for checking whether it's still there. Most of the time, it was, and running a browser even on a nearby machine was not a pleasant experience. Running Emacs was less bad, but the only things that actually worked well were probably xlogo and xload.
- flohofwoe 6mo ago
  If Wayland doesn't need network transparency why do Wayland clients and "server" still communicate through a socket though? Why not use a much simpler command buffer model like on 3D APIs, and only for actually asynchronous commands (but not simple synchronous getters)? PS: is io_uring using sockets for its "shared memory ringbuffers"? If not why? Too much overhead? And if there's notable socket overhead, why is Wayland using sockets (since it has to solve a simar problem as io_uring or 3D APIs).
  - gf000 6mo ago
    It's only using sockets to pass a handle to a buffer though. Sockets are plenty fast, but not moving stuff in the first place can't be beaten.
sho_hn 6mo ago
> I never understood the Wayland push and I still don’t. What happened is basically this: - X11 was fairly complex, had a lot of dead-weight code, and a whole bunch of fundamental issues that were building up to warrant an "X12" and breaking the core protocols to get fixed. - Alongside this, at some point in the relatively distant past, the XFree86 implementation (the most used one at the time, which later begat Xorg) was massively fat and did a huge amount of stuff, including driver-level work - think "PCI in userspace". - Over the years, more and more of the work moved out of the X server and into e.g. the Linux kernel. Drivers, mode setting, input event handling, higher-level input event handling (libinput). Xorg also got a bit cleaner and modularized, making some of the remaining hard bits available in library form (e.g. xkb). - With almost everything you need for a windowing system now cleanly factored out and no longer in X, trying out a wholly new windowing system suddenly became a tractable problem. This enabled the original Wayland author to attempt it and submit it for others to appraise. - A lot of the active X and GUI developer liked what they saw and it managed to catch on. - A lot of the people involved were in fact not naive, and did not ignore the classic "should you iterate or start over" conundrum. Wayland had a fairly strong backward compat story very early on in the form of Xwayland, which was created almost immediately, and convinced a lot of people. In the end this is a very classic software engineering story. Would it have been possible to iterate X11 toward what Wayland is now in-place? Maybe. Not sure. Would the end result look a lot like Wayland today? Probably, the Wayland design is still quite good and modern. It's a lot like Python 2.x vs. 3.x in the end.
gf000 6mo ago
It never worked very well - in the age of bitmaps (and that's not a recent invention) that ultra-dumb pixel pushing simply no longer scales. We have eons better ways to transport graphical buffers around (also, what about sound? That seems reasonable - but now should the display server also be a sound server?), so building it into such a core protocol just doesn't make sense.

anthk 6mo ago

Not very different from Windows: - Modern DX and old Direct Draw games often was a clusterfuck in order to keep them running fast in Windows 8 and up. - XVideo and overlay video for Windows were 100% the same; green glitches on drawing, blue screens on screnshots et all. - Same issue in Windows with pixmaps. - RDP was fine there, even Gnome adopted it. But I prefer 9front's transparency, you don't need to get everything from the host to use it, with 9front you can just get the device you want, you can decouple auth from the GUI and a lot more, even the network and audio devices. Much fetter than X11's remote setups, VNC, RDP and whatnot.

rbanffy 6mo ago
9front is nice, but I'm not sure how much you'd get out of it without implementing the rest of Plan 9 in the target OS.