1. 6

  2. 4

    Obviously, if we intend to make Wayland a replacement for X, we need to duplicate this functionality.

    Perhaps a less than popular opinion, but: No, you don’t. If you want to replace A with B, you don’t need to replicate every mistake A made. Then B wouldn’t be much else than A’, with old bugs and new.

    Don’t get me wrong, X’s network transparency might have been useful at some point - it isn’t now.

    1. 8

      Practice speaks otherwise, many people use it daily.

      1. 1

        That a lot of people use something daily doesn’t mean it is good, or needs to be replicated exactly. Running GUI programs remotely, and displaying them locally IS useful. It does not require network transparency, though.

        1. 1

          Require? Perhaps not. Makes things easier on some ways though.

      2. 6

        X’s network transparency might have been useful at some point - it isn’t now.

        I use it 5+ days a week - it is still highly useful to me.

        You’re right that fewer and fewer people know about it and use it - e.g. GTK has had a bug for many years that makes it necessary to stop Emacs after having opened a window remotely over X, and it’s not getting fixed, probably because X over network is not fashionable any more, so it isn’t prioritized.

        1. 2

          What is the advantage of X remoting over VNC / Remote Desktop?

          I remember using it in the past and being confused that File -> Open wasn’t finding my local files, because it looks exactly like a local application.

          I also remember that there were some bandwidth performance reasons. I don’t know if that is still applicable if applications use more of OpenGL and behave more like frame-buffers.

          1. 7

            Functional window management? If I resize a window to half screen, I don’t want to see only half of some remote window.

            1. 2

              Over a fast enough network, there’s no visible or functional difference between a local and remote X client. They get managed by the same wm, share the same copy/paste buffers, inherit the same X settings, and so on. Network transparency means just that: there’s no difference between local and remote X servers.

              1. 1

                It is faster, and you get just the window(s) of the application you start, integrated seamlessly in your desktop. You don’t have to worry about the other machine having a reasonable window manager setup, a similar resolution etc. etc.

                In the old days people making browsers, e.g. Netscape, took care to make the application X networking friendly. That has changed, and using a browser over a VDSL connection is only useful in a pinch - but running something remote like (graphical) Emacs, I prefer to do over X.

            2. 1

              I’d like to see something in-between X and RDP. Window-awareness built-in, rather than assuming a single physical monitor, and window-size (and DPI) coming from the viewer would by themselves be a big start.

              Edit: Ideally, pairing this with a standard format for streaming compressed textures, transforms, and compositor commands could solve a lot of problems, including the recent issue where we’re running up against physical bandwidth limitations trying to push pixels to multiple hi-def displays.

              1. 2

                FWIW I agree with you. It also so happens that something is coming soon enough .. https://github.com/letoram/arcan/wiki/Networking

            3. 1

              often if i read about something invented in linuxland, i have to think about plan9, and how good some concepts would fit todays distributed computing.

              1. 3

                How does that apply here? How did Plan9 do it differently?

                (FWIW, X is not a Linux invention.)

                1. 1

                  well, you can compose your environment: take the filesystem from one system, the processing power of another and something else to use as terminal handling input/output, all by using a rather simple network protocol.