1. 26
  1. 11

    The Wayland developers obviously had different goals in mind, but I think they dropped network-transparency too quickly, especially when we consider the ever-improving internet-connections that we have. In an ideal world, I could imagine sitting in the park with my laptop and transparently working on a demanding GUI-application that is running on my computer at home.

    Of course there’s waypipe and from what I’ve heard it works, however, transmitting buffer-state changes is very wasteful, given most GUI-applications are just simple deterministic constructs. Remote X is definitely not a shining star in regard to efficiency, either, but I imagine the following:

    Just like vector graphics (like SVG) can be really small compared to raster graphics, while infinite in resolution, one can imagine to have a similar approach to user interfaces (but hopefully not as bloated as SVG). In case you really need a dynamic canvas to draw on, you could do it (compared to ) at the cost of transmission size, but in most cases, you would be fine with the “vector-GUI” format.

    As I often like to criticize, the Wayland protocol is too “thin”. The motivation behind it was understandable, but it comes at huge costs, inconsistencies and bloat (especially in compositors and GUI-toolkit-libraries). Merely comparing to X, which is decades old, is a simple way to avoid discussing this major issue, in my opinion.

    1. 9

      This sounds like NeWS to me.

      1. 7

        I don’t totally disagree with the Wayland folks. We have a pretty good protocol for remote display with a stateful display server: the web. Particularly as so many things are using Electron and so on, proxying to the remote display at the DOM / JavaScript layer may make more sense.

        I’d really like to see a windowing system designed around that model. Take a minimum amount of DOM or standard statefule widgets + WebAssembly + WebGPU and so on that’s required and implement that as both a lightweight bare-metal thing and a thing that runs in a web browser. Provide a display system that runs view objects on the display server with their logic in a Wasm sandbox, a model where the display can be disconnected and reconnected, and any application can run either locally, remotely in a remote instance of the display server, and remotely in a web browser.

        1. 1

          I’m legitimately surprised no one’s tried to cut the Gordian knot with this already. You’d think Google would have gone for this.

        2. 2

          Remote X is just really simple and convenient to use, especially for the type of advanced user that has a terminal/ssh-centric workflow and wants to display individual windows. X was designed with a socket transport in the first place so using a network pipe essentially came for free. For Wayland any remote solution is and will be an afterthought. This has been a big mistake in terms of gaining acceptance because Wayland doesn’t really offer any other great practical rather than theoretical advantages. It’s supposed to be more resource efficient but was far from it when I compared by i3 setup against an equivalent one using sway.

          Remote X has never been great over slow networks. I find VNC to barely be usable when home working and never considered trying X. I mostly rely on ssh and vim/netrc’s ability to open files over ssh.

          1. 2

            I’d be surprised if things like drag and drop actually work there. With X, it is kinda cool when you have two applications open on separate computers yet you can copy/paste, drag+drop, and all that between them without even thinking about it (at least not if the programs are well written).

            Many remote desktop kind of things do at least some clipboard integration too, but in X it actually just works (and stuff like the Windows X server does clipboard integration with Windows programs too, but not drag and drop between them). Wayland saying “ipc belongs elsewhere” means it is unlikely to work well there either.

          2. 2

            especially when we consider the ever-improving internet-connections that we have

            Network latency hasn’t really gotten better in a long time, and I’m pretty sure that’s what’s limiting X remoting. In fact, I’m on a fairly decent DSL connection, with about 24 megabits per second download speed, and I get noticeable typing jitter when I use plain text SSH to interact with EC2 nodes. LTE was even worse, last time I tried it.

            So making it smaller won’t help nearly as much as using a form-application-like model.

            1. 2

              So making it smaller won’t help nearly as much as using a form-application-like model.

              Bring back block terminals!

          3. 6

            I gained an appreciation for remote X when I realized you could use it to run web browsers in virtual machines. I neither like nor trust browsers all that much, and sometimes I’ve found it to be worth the trouble to sandbox them.

            I do like low-power small form factor computers, and I keep meaning to experiment with using a Raspberry Pi as an X terminal for accessing a browser hosted on the dedicated server I have running in a data center.

            1. 1

              Ah, but from what I understand about X11 the “sandboxed” browser can still read everything on the screen / all keyboard input, no?

              1. 2

                There’s various ways to protect yourself from that with X today (and the last decade…) too, including a fully sandboxed X window (e.g. Xephyr) and an “untrusted” client, see https://www.x.org/wiki/Development/Documentation/Security/ which is used if you ssh -X into the vm.

                1. 1

                  It may depend on your threat model. I tend to only have one browser tab open at a time, and I only run X11 for the web. As a rule I don’t keep browsers open unless I’m actively using them.

                  The thing that got me interested in running browsers in VMs was this CVE from 2015. My main concern was keeping the browser away from the filesystem.

              2. 5

                You can run individual applications under x2go, and I’ve been using that for years as it’s quicker then plain X-over-ssh and allows disconnect/reconnect just fine. Doesn’t support apps or desktop sessions (e.g. GNOME) which need new extensions though, as the versions of the X libraries it uses are incredibly old, but that hasn’t bothered my usage thankfully :)

                1. 4

                  Good post, but the conditions mentioned are pretty obscure for me personally. I’ve not had a “desktop” machine at work since 2003 or 2004, always laptops so the “main machine” is at home, anyway.

                  The other thing is (again personal story) of being able to spin up some VMs or containers at a beefy machine at work - nope. My private desktop PC is miles faster than anything a developer usually gets to work on. On one particularly annoying project I just rebooted my home PC from a live linux usb stick and did my compilation on 16 cores instead of 2, sad as that is.

                  Not saying it’s not useful, but I personally would have never gained anything from X forwarding, while working on Linux for the last 14? years.

                  1. 1

                    Interesting how different people’s workplaces and experiences are, as I’ve had basically the opposite experience to you, and more like the OPs – I have a desktop PC at work which is far more powerful than any hardware I have at home, and I do all my heavy lifting on that, including a bunch of VMs.

                    Also, my workplace really doesn’t want people having data unnecessarily held “outside”, so this way around avoids that happening.

                  2. 3

                    On the other side, I usually just use VNC for the applications I’d ever need on the remote. In terms of development, I usually just wrap emacs with the matchbox window manager and can use TigerVNC’s viewer to resize it like a normal window; I’ve looked into tramp, but I’m not that comfortable with it yet. If I need another application, I can just add another session type for it.

                    Last time I used X forwarding it seemed slower to me than VNC and a few people at work use Linux VMs and VcXsrv on Windows host, but for some reason transitioning off the work VPN causes their X connection to break and close the application. At least with VNC, if the connection drops the application is still running.

                    1. 4

                      Yeah Xvnc is a much easier thing to make fast than remote x11. All the chatty multiple-round-trips interactions between x11 clients and x11 server happen over loopback or a unix socket. The high latency connection is just carrying pixels and input devices.

                      Having the network transparency be a framebuffer oriented protocol like VNC or RDP strikes me as a much better layering. Keeps the very-latency-sensitive bits away from the bits that necessarily involve making network round trips over potentially quite long distances.

                      1. 1

                        All the chatty multiple-round-trips interactions between x11 clients and x11 server happen over loopback or a unix socket.

                        This heavily depends on what applications you use. There’s not actually that many round trips actually required by X outside of operations like drag and drop, which is probably worth it - being able to communicate between any two visible windows regardless of which machine is hosting them is pretty cool.

                        1. 1

                          Historically lots of round trips have appeared in toolkit code even though I’m theory they might not be strictly necessary.