1. 65
    1. 49

      I am not an X11 apologist. I think that Wayland and systemd both exist because the things that they’re replacing have a lot of flaws and aren’t the right solutions for modern use cases. I just don’t think that they are the right solutions to the (real) problems in the things that they’re trying to displace and I object to the framing of ‘if you don’t like the new flawed thing then you must be an advocate of the old flawed thing’.

      1. 27

        Congrats, as demonstrated already, by taking the reasonable course you have opened yourself up to annoyances from both extremes.

        1. 18
        2. 7

          Well, X does have some problems. But I find most people don’t actually identify them. What’s most interesting when you start getting specific about what problems actually are is that solutions start to emerge at the same time. If you stop at “X sucks” without examining why, your solution is “discard X”, but if you say “X sucks because Y”, then it opens up another solution: fix X by changing Y.

          Last year, I had a similar thing with my little gui library. I spent several years writing it and had grown to kinda hate it. Was tempted to rewrite it, but I knew from experience that I’d probably just waste years and end up in the same mess. So instead, I sat down and asked myself in detail just why I had grown to hate it… and that started leading to ideas to fix it. After a while, not only did I not rewrite it, I fixed most my problems without even any significant breaking changes! (one of them did require a breaking change, but thanks to getting specific, i was able to also provide myself a smooth migration path)

          and btw in the process of writing my gui libs, i’ve gotten quite a bit of experience working with X. Much of it is not terribly well documented at this level but once you get to know it, there is logic behind the design decisions, and some of it is actually really quite nicely designed.

        3. 1

          I don’t represent either extreme; I was merely curious.

          1. 1

            That’s reasonable, it was just a very entertaining set of responses. XD

      2. 7

        On the one hand, we have this decades old software that has flaws that many people have experienced with. On the other, we have this newly invented piece that claim to fix the obvious flaws of the old and introduces new ones that early adopters still struggle to identify. Instead of ditching the old and embracing the new, I surrender to the flaws of the old. At least they are well understood. I would rather wait until enough time has passed, and people have faced most of the flaws of the new. Who knows, decades later, there will be new kids in town throwing out wayland and systemd, while inventing their own shining new toys. And there may still be people running X11 and init(8).

      3. 6

        What do you think is wrong with Wayland?

        1. 8

          As a user, the first thing they sacrificed was something I’ve relied on most weeks for the past 15 years: transparent networked clients. Having remote applications integrate into the desktop as normal windows is a huge usability improvement over remote desktop viewing. Critically though, I rely on running GUI applications without a full set of desktop-related software installed. I want to run these applications without the need to actually maintain a desktop on each of the machines.

          As both a fan of open development models and a software engineering manager, I think Wayland essentially declared tech debt bankruptcy without solving the organizational challenges that led to a lot of the issues with X. The original proponents of Wayland say they can’t just stop supporting problematic X extensions but also don’t explain how Wayland protocols will be sunset. The best I can tell from reading their governance documentation is that protocol support is essentially a popularity contest and stable protocols will be sunset by removal of projects from the membership and thus preventing their objection to pull requests. Their README says:

          A protocol may be deprecated, if it has been replaced by some other protocol, or declared undesirable for some other reason. No more changes will be made to a deprecated protocol.

          Elsewhere in the document it says:

          … and deprecated protocols are placed in the deprecated/ directory.

          Hilariously, that directory does not exist. For a project borne of a frustration with the previous technology’s stagnation and inability and/or unwillingness to evolve, I would expect more attention paid to how users will be expected to navigate an ecosystem of heterogeneous support for deprecated protocols. I’ve concluded that while Wayland does make some technological advances, it exists as a project mainly for the purpose of unseating incumbents who seemed reluctant to evolve X toward the simplified Wayland architecture.

          1. 4

            As a user, the first thing they sacrificed was something I’ve relied on most weeks for the past 15 years: transparent networked clients. Having remote applications integrate into the desktop as normal windows is a huge usability improvement over remote desktop viewing. Critically though, I rely on running GUI applications without a full set of desktop-related software installed. I want to run these applications without the need to actually maintain a desktop on each of the machines.

            Wayland doesn’t make this impossible, it’s just not part of the core protocols. Waypipe can be used for that: https://gitlab.freedesktop.org/mstoeckl/waypipe

            1. 1

              Yeah I’ve tried waypipe. Unfortunately the launching conventions are all jumbled now so while it generally works for executing a program directly any programs that program executes is much less reliable. I suspect it’s mainly due to the session type environment variable not being passed on. The net result is a more frustrating experience than X though. Anecdotally it feels slower too. That might be due a lack of focus on optimization and destined to be fixed but right now it is disappointing.

        2. 5

          It’s been a while since I looked at it in detail, from what I remember (any or all of these may be wrong):

          They originally conflated copy and paste with drag and drop in a way that made low-latency drag almost impossible. I think this is fixed.

          By putting network transparency out of scope, they make it hard for a client to use lossless compression for rendered widgets but stream a video in a rectangle and so on. I think Pipewire just compresses the whole window, so a video is decompressed to a texture, sent via a shared me,pry transport, recompressed, and then sent to the remote display, then decompressed. By moving GL and audio out of the server, they make it hard to remote these and make it very hard to control audio and video latency for synchronisation.

          A huge amount is out of scope of the protocol, so everything ends up depending on compositor-specific extensions (screen shots, on-screen keyboards, and so on).

          My main problem with Wayland is that it doesn’t really seem to solve any of the problems I have with X11, it just says that they’re out of scope and should be built externally.

      4. 6

        What are the problems with X11 for modern use cases?

        1. 10

          The big one is the (lack of) security model. There are some security extensions for X11’s, but enabling them breaks a lot of stuff. Things like on-screen keyboards rely on being able to inject key-press messages into any other X client. It’s been a few years since I did any low level X11 programming, but I seem to recall that it was impossible to attribute a window to a connection (xkill is fun here: it relies on untrusted metadata to choose the thing to kill), which makes it hard to enforce other policies. It would be possible to add a capability model to X11, but it would come with a lot of compatibility problems.

          X11 has a lot of state, split between the client and the server. This makes it hard to restart the server without breaking clients (there are some proxy things that try this, but they don’t work well). It kind-of does network transparency, but not in a great way: MAS tried to add audio but it was never merged, so a typical X11 app doing remote display will show pictures on one computer and play audio on another. It doesn’t have anything in the protocol for streaming compressed video, so if you try watching a movie over remote X11, it’s decompressed on the client and streamed to the X server uncompressed. You might be able to use AIGLX to work around this if you use some non-standard vendor extensions to upload video to the remote GPU and decompress it there, but now you’re way outside of portable use of X11.

          The state and the lack of client identification means that you can’t do the sorts of tricks that Quartz does in the compositor, where the server takes ownership of a window when a client dies and allows the client to reconnect and resume ownership. This is why Macs appear to boot in a few seconds: most of the apps haven’t relaunched and will be launched in the order that you start interacting with the windows.

          Nothing in X11 is unfixable but the thing you’d end up with would probably not gain any benefits from being built on top of X.

          1. 9

            Wayland is worse off in many other ways, the absent security model is just icing on an already moldy cake. I couldn’t come up with a better surreptitious API design for encouraging memory vulnerabilities even if I tried; it is a use after free factory by design and the clients get all the primitives they could wish for to control heap layout and object reuse. It reads like an overcomplicated CTF challenge.

            Actually worse is the poorly conceived wire format that isn’t even capable of handlings its own data model (see the dma-buffer modifier int64 pack/unpack shenanigans for instance) – and the object model (much bigger state explosion than X11, asynch-java-like OO for C producer and consumer is a spectacularly bad idea) led to dispatch designs that are some of the worst around. At one point in the timeline, libinput artificially rate-limited “gaming mice” as the event storms from moving the cursor over a window would cause buffers to fill up, and failing to writev just close() clients that then promptly crash from some NULL deref because there is less meaningful error handling around than even if (!malloc…).

            I spent quite some time investigating this, https://arcan-fe.com/2017/12/24/crash-resilient-wayland-compositing/ and took it much further later on, but https://gitlab.freedesktop.org/wayland/wayland/-/issues/159 remain forever in my heart. There is so much of this around. What did they get right? it’s not X. Instead, it’s what you get if you cheat and skip doing your homework by trying to copy MSCOM and SurfaceFlinger – acting like that still wouldn’t leave the FOSS desktop decades behind.

            Nothing in X11 is unfixable but the thing you’d end up with would probably not gain any benefits from being built on top of X.

            So I eluded to one graceful path a while back, https://www.divergent-desktop.org/blog/2020/10/29/improving-x/ , fairly certain that would never happen. There are a few other options not that far away, one that I sat down and implemented most of a year or two ago; wrote the article and then decided not to publish. It turns out it works – there is a way to let Xorg remain Xorg until display density + display sizes overflow the hardcoded coordinate space (then it gets really hairy), get most of the benefits of the lower layer changes to the stack, and overlay much better security controls – it is not even that hard. The problem is that it still won’t undo the harm already caused by GTK and D-Bus.

            There are more interesting things to focus on. It is not particularly appealing to adopt the hellthread-writers wayland now absorbs (without any meaningful compensation to top it off). Come to think of it, Wayland (the project) has that over X, it is a good abuse filter.

            1. 3

              Thanks, that’s fascinating detail. Everything I’ve read about Arcan suggests that it is actually solving the right problems (any year now, I hope to have enough free time to properly play with the code and especially to see how it would play nicely with Capsicum and how well SHIM-IF works with CHERI). For some reason, the name ‘Arcan’ doesn’t stay stuck in my head - I meant to refer to it earlier but I couldn’t persuade a search engine to help me find the name of the project.

              I can quite easily see, for example, how an Arcan client could display a window containing a video stream where the widgets were rendered on the client and the video is decoded on the display server. I can kind-of see how X11 could evolve to support this, though not in a way that would work with any existing toolkits. I have absolutely no idea how Wayland could ever get there.

              1. 2

                So it can be solved in Wayland by defining another buffer-format, with either SHM or DMA Buf transport (there’s tons of them in there, just rarely implemented or used as everyone just went ARGB888 then realised they didn’t define a colourspace for the buffer to map. One could even, I don’t know.. add SVG in there ;)) and using wl_subsurface with the buffers attached.

                In practice, the (hardware-implementation-defined) zwp-linux-dma-buf-v1 layering violation “protocol” basically does that. GPU buffers are compressed in the weirdest of formats for the strangest of reasons and very often looks eerily similar to video. This is a long standing tradition, MPEG2 accelerators in the Hollywood+ style cards from the early DVD era had similar properties (I reversed drivers/framebuffer formats of that for fun and time wasting), basically MPEG2 I-Frames as a framebuffer format, so if you wanted to use it as part of a HTPC box or something, you needed to render to that.

                It becomes much tougher to have graceful fallbacks when / if that allocation asynchronously fail, the video decoding crashes, has broken frames and so on. The delegation model in Arcan (“frameservers”, homage and evolution of Avery Lee’s virtualDub and MSWIN GraphEdit era) covers that though and that is actually where much of the designs evolved; ways of sandboxing mid 2000-era ffmpeg as it was basically impossible to share a memory space with it without getting punished for it).

                What is much trickier for Wayland in this regard is to spawn of a child video decoder and have that process embed its video output as a subsurface of the parent without tons of things breaking. There are “attempts” ( https://wayland.app/protocols/xdg-foreign-unstable-v2 ) but it is again very fragile and complicated because their building blocks are fundamentally and irreparably flawed. Closely related, this is also why they are not capable of having a window management process synchronously managing synchronisation, display parameters and window stacking.

                Among the things going on in Arcan right now is this effect for the network protocol level (A12) where we do try to have dynamic “local delegate transcodes media” that also deal with passthrough if sink supports along with muxing (don’t want clipboard cut and paste of a 100G file be line-blocking) and safe fallbacks.

                1. 2

                  And now I really want to play with Arcan and Capsicum.

          2. 1

            OK, yeah, those are pretty reasonable. A lot of people annoy me with the security thing saying it isn’t there and is fundamentally impossible, both of which are false… but what’s there doesn’t actually deliver on being easy to use. It is like someone wrote the hooks then said “ok someone else figure it out from here”, but by then most the people who were interested in figuring it out from there had already jumped ship to Wayland or whatever. Additionally, some of the conventions on X would be very difficult to use with stricter restrictions. Drag and drop comes to mind, since the client needs to ask which mouse is under the cursor, which is a thing that might be restricted. With some kind of middle man proxy or just a permission popup I think you could make it work, but again, the U missing from the UX here; nobody has bothered working out those details.

            Though…. this also is something that doesn’t really bother me, since I just don’t run applications that do evil things. (And I consider evil things to include something as simple as raising itself to the top of the window stack. I’ll hack that crap right out of the code, i can’t stand it). And if I do have to run something more iffy, I’ll put it in a Xephyr session to isolate it. Though another thing I would like to see is a nested server be better about resizing. Xephyr does an ok job but again the ux i think could really be improved with a little more polish, by putting a special window manager in there. If I had more time and/or it became a higher priority cuz of a required application or something I might look into it myself.

            The state concern is completely fair too. In my library, I make an effort to keep a copy of the server-side state in order to support display migration. If it disconnects, it can try to reconnect to a different X server and recreate its assets there and carry on. It actually sometimes works! … but not all the time, and it was a bit of a pain to code up (especially cuz xlib assumes a display connection is fatal. i kinda wanted to redo my own xcb based thing but again never got around to it so i hook the error handler and throw an exception to regain control. lol) When it works, I think this is a really cool feature - giving guis one of the big benefits of terminal applications with gnu screen and friends. Yes, yes, I know there’s RDP and VNC and whatever, but I really hate using those (even though I have a lot of respect for RDP’s achievements. Once upon a time, 2010ish, I was running xming on a Windows box on my lan and RDPing to it remotely because the X app performed soooo much better on that network link through Windows than it did directly. and then you get some sound, printers, files, etc too!). I often have a mix of local and remote programs and want them to actually integrate the window stack order etc., so I prefer X’s model to RDP’s. And you know, if the XResource promise worked, the application could even retheme itself when migrating servers to blend in locally! But I never even actually did a proof of concept for that. Pretty sure it is doable though.

            And once more, I agree it would be nice if the image transfer formats had more options. Should be easy as an X extension. Even just png and jpeg would be really nice to have for some cases, and some kind of video support too might eliminate some cases where I run local clients in addition to remote. Though this is something I can live without since my internet speed is 25x faster now than it used to be and I don’t pay by the kilobyte anymore so the economic pressure has passed. But yeah, still would definitely be nice.

            As for what building this on top of X would bring instead of doing your own thing: a lot of it is just compatibility with all the existing programs. There’s a lot to be said about things that have just worked for many years continuing to just work. But also there’s a lot of little corner cases that have been figured out that are good to keep working. I’d try to make a list, but that’s kinda the point: what would I forget to put on that list until someone at some point brings it up as a bug report? As a project matures and has more users, that list of corner cases gets bigger and bigger and if you throw it out, you’ll inevitably just recreate it eventually anyway, and in the mean time, things will be broken and users annoyed.

            1. 2

              As for what building this on top of X would bring instead of doing your own thing: a lot of it is just compatibility with all the existing programs

              This is the place where I kind-of agree with the Wayland folks. Existing software doesn’t just expect something that speaks the X11 protocol, it expects something that speaks the X11 protocol and does specific things with it. If you break some of those things, you’re breaking compatibility, even if you still speak X11. You can run an XServer with a Wayland or Arcan (or Windows, or Quartz) back end and the Windows one in particular demonstrated that you can have things like copy-and-paste and integration with a foreign windowing system work very well. Arcan and Haiku have shown that you can put the X emulation layer much closer to the client (even in process with it in the case of Haiku).

      5. 2

        I have the same pov except with the addition that I think both systemd and wayland are not softwares that you can improve to “fix them” - they have totally wrong assumptions to begin with - so I am against moving the mindshare in that direction which makes me somewhat of an advocate of the old flawed thing.

      6. 1

        I would love to hear your thoughts on systemd, given your work on Casper/CHERI.

    2. 22

      The biggest problem with X11 is the amount of paper my teletype goes through now. It’s really just not economical at this point, and I’m starting to worry about my carbon footprint.

      1. 2

        Huh? Can someone explain? This seems like a joke but I’m not sure what it’s referencing.

        1. 2

          A GUI on a teletype is sub-par. Redrawing windows (or even just moving the mouse) has to print the entire screen again, and that uses a lot of paper.


          Yes, it was a joke. 😉

          I have seen text mode 25x80 (?) “windowing systems” (or some-such) on a teletype, which is the memory that brought this humor to the front of my mind. Fortunately, dumb terminals (aka “glass teletypes”) were inexpensive enough to displace most teletypes pretty quickly. I haven’t even seen one in at least 30 years now.

    3. 20

      So what you do is, you keep stepping this number up 1 millisecond at a time while playing a smooth animation, until you’ve eliminated any stuttering in the animation. And now you have done something X11 cannot do- eliminated screen tearing with the absolute minimum latency cost possible. This fantastic. It feels fantastic.

      Wow. I don’t think I’ve ever seen such a perfect crystallization of the Linux mindset. Just… chef kiss I absolutely hate it.

      1. 5

        MacOS is the best UNIX DE.

      2. 1

        you could pick a good base value for end users and give them an automated setup which does basically the same but just asks you to say when it’s getting bad, automatically calibrating this value

        1. 9

          You don’t even have to say it, because you can measure how many skips you had, and aim for some default value.

          1. 1

            that’s even better, probably something that will make it to the wayland compositor eventually (maybe KDE & co do this already ?)

    4. 8

      If you want to try a wlroots-based compositor, know that you can probably do everything you want to do, but it’ll be some effort.

      I rely pretty heavily on a feature of my xorg WM which converts key combos from Emacs style to “conventional” style; this is an absolute necessity for me since Firefox nerfed their extension system and banned any user customization from binding to key combos like ctrl-n and ctrl-p. (“For security reasons” they say, despite the fact that I’ve never once intentionally invoked either “new window” or “print” on this machine since I got it five years ago.) I’ve tried to get wayland working a couple times (I have a laptop with a GPU that isn’t supported under xorg) but when I ask wayland people how to do this, they all look at me like I’ve lost my mind. So my fancy new laptop mostly just sits on my shelf collecting dust. =\

      Maybe in another five years…

      1. 2

        Didn’t test this since I don’t use emacs, but interception tools with remap sounds like it does what you want.

        https://gitlab.com/interception/linux/tools https://github.com/Rational-Curiosity/remap

      2. 1

        I feel like you’d probably solve this by building in the functionality to the compositor?

        I’d really like to see an equivalent to awesomewm for Wayland to make building this functionality yourself easier.

        1. 7

          That’s what they said when I asked on IRC. Hearing “you have to write some C code” made it feel a lot like https://p.hagelb.org/fault-tolerance.png

        2. 2

          Have you tried Qtile? It looks like the closest wayland alternative to awesomewm built around python instead of lua.

          I too deeply miss awesomewm. I’ve moved over to wayland and Sway 2 years ago. The manual tiling frustrates me every day yet “it works” so I haven’t taken the time to fully figure out Qtile.

    5. 5

      I have often thought of building a “minimal Xorg.” No font server (embedded fixed font only), no remote access (UNIX domain sockets only), the set of common extensions expected today, removal of unused extensions, removal of unused auth mechanisms, etc.

      Note that this is distinct from “configure existing Xorg at compile time to remove those things,” but rather wholesale removal of those features from the code base never to return.

      It’s probably not worth the effort but it would be fun.

      1. 1

        That sounds more or like what I have proposed a few times for X12. Work out all the old legacy stuff that no modern Linux system uses any more and try to codify what are the bare essentials for X in the 21st century, as a baseline for looking at what could be removed forever to try to simplify maintenance in future.

      2. 1

        I find this interesting since, I’m guessing, eventually I expect to be forced to Wayland at some point but will still be using Xwayland for a while for legacy software (motif, fltk, Fox toolkit, etc.).

    6. 8

      ssh -X still not working?

      1. 8

        The wayland equivalent is Waypipe.

      2. 6

        My recent experiences have been that depending on the program I want to run, the network I’m on, my video card, the OpenGL drivers I have installed on each machine, the application settings, and the phase of the moon, it has a 70% chance or so of not working anyway.

        1. 1

          I use it all the time and have never seen a failure for any reason other than “you can’t forward a GPU”

          1. 3

            I guess I tend to need a GPU fairly often, or else use programs that tend to want a GPU for video decoding or such even if they aren’t displaying 3D stuff. (I do spend a fair amount of time looking at 3D stuff for Real Work Things, too.) Either way it makes me sad how poorly it works, especially considering one point of X11 was that rendering hardware could live on machine local to the user.

    7. 4

      Until color management finally gets worked out and merged, Wayland is unsuitable for content creation. ICC profiles matter for proofing documents, matching printers, monitor calibration, etc. Can Wayland even display beyond sRGB gamut? Regardless, an entire sector of professional and hobbyist work is still blocked by Wayland. I recently migrated back to X11 so I could confidently do photography again.

    8. 4

      A few days ago I started using my old laptop for the first time in years and decided to try switching my desktop environment configuration to Sway like the author — it’s been surprisingly smooth.

      Last time I tried it, Sway hadn’t reached 1.0 yet and most applications I used (Firefox, VS Code, dmenu) didn’t directly support Wayland or didn’t have a direct Wayland equivalent yet; in some cases they had some weird rendering bugs that made them unusable. Sway also used a lot more resources than my X11 setup which, on my underpowered laptop, was kind of a deal breaker.

      Now everything just seems to work. I’m really enjoying scrolling in Firefox without screen tearing, and xeyes barely looks at any window I use. Some applications still have issues — I tried Nyxt the other day and the UI was all messed up, both on Wayland and XWayland — but I think the Wayland desktop has reached a point where it can replace X11 for me.

    9. 3

      I am really worried about Wayland: I am worried that it will replace 11/12tha of X11 and just not ever bother with the vital 1/12th. Kinda like GNOME 3 broke its screensaver and never fixed it (at least, not while I was still using GNOME — maybe they did eventually?). And I worry that so many (maybe all?) of the compositors are based on a C library.

      But hey, once there is a native Common Lisp Wayland compositor I’ll be glad to give it a shot. Until then, I’m very happy with StumpWM.

    10. 2

      I can’t count how many times I’ve had to Google “enable TearFree mode amdgpu” because out of the box X11 just doesn’t have a reasonable configuration, for whatever insane reason. I don’t have to worry about that on Wayland. Desktop Linux is still infuriating in hundreds of other ways, of course, but Wayland is a big step to fixing my day to day annoyances. I hope I can free myself from Apple soon.

      1. 1

        Whereas on my system, I’ve actively tried to get tearing on my basic, out of the box, X setup, and it never happens. I have one of those Intel integrated chips which appear to be better supported.

    11. 2

      I cannot use Xorg anymore, it’s just so clunky. And I sometimes try, because Wayland has its own set of problems with Windows-emulated games.

      I think we oughta let it retire. Focus on the future.

      1. 3

        It would help if you could quantify a bit what ‘feels clunky’ means to you here. For example, I use Xorg quite often on Windows, accessing VMs with ssh -X to run tools in my host GUI. Apparently WSL2 can also do something similar with a dedicated Linux VM with GPU passthrough running Weston and PipeWire for exposing this to other VMs but I don’t know how to make a custom VM talk to the PipeWire server - what’s the equivalent to port forward this over ssh?

        1. 1

          It would help if you could quantify a bit what ‘feels clunky’ means to you here.

          Steam client and every Proton game have visible long pauses on every interaction when running on xorg (Gnome or i3, doesn’t matter) and works fine on Wayland (sway). DPI settings between different screens are always not quite right. Tearing. All kinds of arbitrary rendering bugs (mostly in Gnome, i3 tends to work better due to its simplicity I suppose). All kinds of breakings when detaching/attaching screens.

          Wayland just works for me since at least 2021 with everything I throw at it. Sway being so awesome is a big part of it being good – it’s very possible that people using the larger desktops are having worse times than me.

          what’s the equivalent to port forward this over ssh?

          I don’t need this functionality personally, so I don’t have first hand experience, but I hear people are using waypipe[0] for that.

          [0] https://gitlab.freedesktop.org/mstoeckl/waypipe