4 ms·

I really wish people gave a damn about the “gui over the network” problem x11 solves. Wayland drops this use case entirely so we’re pretty much universally stuc

by le-mark 4mo ago

I really wish people gave a damn about the “gui over the network” problem x11 solves. Wayland drops this use case entirely so we’re pretty much universally stuck with vnc. Microsoft rdp is a great solution for this in windows land.

wmf 4mo ago
Waypipe exists. Somebody needs to do the integration so you can run ssh -W though.
- LeFantome 4mo ago
  Why? Isn’t “waypipe ssh” more “the UNIX” way. There is also wors.
nananana9 4mo ago
They drop this use-case, but still use sockets for IPC, so I still have to pretend I'm doing network programming, serialize my messages over the "network" and "flush the stream" (insanity) but don't actually get any of the benefits of this model. I genuinely wonder if they stopped to think why X11 has sockets or just blindly copied it over. Or are they unaware other forms of IPC exist, that don't require you to go through the kernel 13 times to send a byte to the other process?
- mort96 4mo ago
  What would you rather they use to communicate with the server? Message passing via shared memory? UNIX sockets are perfectly fine for IPC with small amounts of data, and is how everything in UNIX has always done it, network transparency or not. They provide a simple, efficient and reliable communication channel between two processes.
  - p-o 4mo ago
    Wayland uses UNIX socket for message passing, but then offload most of the work to shared memory when the real work begins (GPU rendering). I just wanted to add some nuances that it's not as black and white as this comment made it seem.
    - mort96 4mo ago
      Yeah, that’s correct; I implied it by only talking about sending small messages but it’s worth stating explicitly.
  - Findecanor 4mo ago
    How about making the standard client library's API the interface, and have it hide whatever the system is actually using? A long time ago when I looked at designing a X11 replacement, that was my approach. AFAIK, only special X utilities used anything but Xlib anyway. And later I think this is what early revisions of Canonical's Mir did.
    - mort96 4mo ago
      So .. still using sockets, but not documenting how the messages on the socket look? Why?
      - to11mtm 4mo ago
        If I had to guess, because then at least -hypothetically- easier to optimize for the 'local' case (depending on implementation, at least from my understanding of the POSIX/*nix paradigm, bending and breaking a bunch of rules possibly) by dropping in a different implementation.
        mort96 4mo ago
        Optimise how? There already is only the local case in Wayland, pixel data is shared using shared memory which only works locally. Only small communication messages are sent via the socket. And the Wayland protocol also uses native endianness because, again, it only cares about the local case. It even sends file descriptors over the socket. So what would you do differently in an alternative client library?
        to11mtm 4mo ago
        > So what would you do differently in an alternative client library? I should have better disclaimed my comment.... to be clear I don't know much about the graphics subject, I probably should have prefaced it with, "I don't know anything about Wayland but as someone totally naieve on the subject but assuming someone else's assumption". At least to me, even if it breaks the X11 model (Which is a shame, that was fun to play with back in the day) if they're doing it the way they are I'm guessing Chesterton's fence will come into play at one point or another.
  - nananana9 4mo ago
    Yes, command buffers over shared memory are the correct way to do this. 1. You don't need to convert your discrete messages into a stream with size metadata, only for them to immediately be converted to a message on the other side. 2. You don't need to jump into the kernel to copy over 20 bytes, only for the other side to jump into the kernel to copy it back. 3. You don't need to deal with the "oh but what if my read returns half a message because this is a stream" 4. You don't need to pretend you're doing network programming. Regardless, it's not that big of a deal - this is like my 73th biggest gripe with Wayland, I only mentioned it since GP was talking about network transparency. It's pretty representative of the project though - "We're doing things the way we've always done them, but slightly different. Now rewrite all your software to work with our thing. No, you cannot do global keyboard shortcuts or set window position. You don't like it? We're doing this for free, you cannot critique it."
    - mort96 4mo ago
      You don’t have to hit the kernel for 20 bytes. Buffer up all your commands and send them to the kernel with a single write(). The other side can then read them all (or however many fit in its receive buffer) with a single read(). The only real difference is that the memcpy happens in the kernel instead of the receiver and that the kernel provides a useful blocking mechanism by default so you don’t have to manage that in userspace code. You need some kind of serialisation either way. It can be as simple as “this message has the shape of this C struct”, but that’s the case whether you’re talking shared memory command buffers or sending data over a socket (and there are good arguments for and against in both cases). You’re right that you don’t need to deal with “oh I received half a message” when using shared memory command buffers, but that’s more a code complexity thing someone solves once in wayland-client and then nobody has to really think about it again. It’s not really a performance concern (because hopefully the rx buffer is large enough for it to happen rarely) or application code complexity concern.
      - nananana9 4mo ago
        Sure. But imagine some piece of exotic hardware, e.g. computer mouse, that reports its movement at 1000Hz. If the compositor wants to notify the client as soon as possible, it has to send 1000 messages per second. If you buffer them, you're wasting the hardware's potential, if you don't buffer, them you're doing 1000 write()s per second, which is... ugh. If you're literally going to design the protocol from scratch and require all existing software to deal with it, why not pick the IPC model that doesn't have this issue.
- mike_hock 4mo ago
  A fundamental part of the Wayland protocol is passing file descriptors through the sockets so this doesn't generalize to network sockets. It also can't be done with shared memory.
ndiddy 4mo ago
If you're fine with RDP, both KDE and GNOME have built-in RDP support on Wayland. If you want something closer to ssh -X, look up waypipe.
- sthuck 4mo ago
  I might be mistaken, but both need a physical monitor turned on. If your monitor goes to sleep you can't connect/see a black screen. The kde one doesn't support remote user login, and while the gnome one does on paper, I never got it to work. The remote connection situation in Wayland is a major regression.
  - ndiddy 4mo ago
    Yeah that's fair, the KDE people have remote login as a goal but it's not there yet. Waypipe is definitely the more mature option at the moment if you need a headless workflow.
dannymi 4mo ago
waypipe works very fine. waypipe ssh XXX
to11mtm 4mo ago
> Microsoft rdp is a great solution for this in windows land. The people who put together TS/RDP are geniuses IMO, it's insane as to how usable it has been for at least 15-ish years...
ethanpailes 4mo ago
https://github.com/wayland-transpositor/wprs https://github.com/wayland-transpositor/wprs
TiredOfLife 4mo ago
Sunshine/Moonlight.
Induane 4mo ago
Arcan has a decent model for this.
TacticalCoder 4mo ago
> I really wish people gave a damn about the “gui over the network” problem x11 solves. Security-wise there are concerns but... Early dial-up Internet days (early for me), 28.8k modem, I was already running Linux, probably on a 486. I also had a very old PC laptop (I think a friend of my parents gifted it to me after he got a new one from work), a 386 I think (with the horrible slow display/refresh rate: a TFT IIRC). I used a parallel cable and PLIP (Parallel Line IP) and X11 networking to send a window manager+browser from the desktop (the 486) to the laptop. So my brother and I could both go on the Internet at the same time. It felt like the future and, honestly, we've kinda seriously regressed when it comes to "GUI over the network".
- simonask 4mo ago
  Your story here also illustrates why GUI over the network used to be a much more important use case than it currently is. These days it’s unbelievably niche, as opposed to more controlled screen sharing scenarios. I think it’s understandable that it doesn’t get a high priority.
LeFantome 4mo ago
You can do GUI over the network in multiple ways with Wayland.

by le-mark 4mo ago

wmf 4mo ago

Waypipe exists. Somebody needs to do the integration so you can run ssh -W though.

LeFantome 4mo ago
Why? Isn’t “waypipe ssh” more “the UNIX” way. There is also wors.

nananana9 4mo ago

They drop this use-case, but still use sockets for IPC, so I still have to pretend I'm doing network programming, serialize my messages over the "network" and "flush the stream" (insanity) but don't actually get any of the benefits of this model. I genuinely wonder if they stopped to think why X11 has sockets or just blindly copied it over. Or are they unaware other forms of IPC exist, that don't require you to go through the kernel 13 times to send a byte to the other process?

mort96 4mo ago
What would you rather they use to communicate with the server? Message passing via shared memory? UNIX sockets are perfectly fine for IPC with small amounts of data, and is how everything in UNIX has always done it, network transparency or not. They provide a simple, efficient and reliable communication channel between two processes.
- p-o 4mo ago
  Wayland uses UNIX socket for message passing, but then offload most of the work to shared memory when the real work begins (GPU rendering). I just wanted to add some nuances that it's not as black and white as this comment made it seem.
  - mort96 4mo ago
    Yeah, that’s correct; I implied it by only talking about sending small messages but it’s worth stating explicitly.
- Findecanor 4mo ago
  How about making the standard client library's API the interface, and have it hide whatever the system is actually using? A long time ago when I looked at designing a X11 replacement, that was my approach. AFAIK, only special X utilities used anything but Xlib anyway. And later I think this is what early revisions of Canonical's Mir did.
  - mort96 4mo ago
    So .. still using sockets, but not documenting how the messages on the socket look? Why?
    - to11mtm 4mo ago
      If I had to guess, because then at least -hypothetically- easier to optimize for the 'local' case (depending on implementation, at least from my understanding of the POSIX/*nix paradigm, bending and breaking a bunch of rules possibly) by dropping in a different implementation.
      - mort96 4mo ago
        Optimise how? There already is only the local case in Wayland, pixel data is shared using shared memory which only works locally. Only small communication messages are sent via the socket. And the Wayland protocol also uses native endianness because, again, it only cares about the local case. It even sends file descriptors over the socket. So what would you do differently in an alternative client library?
        to11mtm 4mo ago
        > So what would you do differently in an alternative client library? I should have better disclaimed my comment.... to be clear I don't know much about the graphics subject, I probably should have prefaced it with, "I don't know anything about Wayland but as someone totally naieve on the subject but assuming someone else's assumption". At least to me, even if it breaks the X11 model (Which is a shame, that was fun to play with back in the day) if they're doing it the way they are I'm guessing Chesterton's fence will come into play at one point or another.
- nananana9 4mo ago
  Yes, command buffers over shared memory are the correct way to do this. 1. You don't need to convert your discrete messages into a stream with size metadata, only for them to immediately be converted to a message on the other side. 2. You don't need to jump into the kernel to copy over 20 bytes, only for the other side to jump into the kernel to copy it back. 3. You don't need to deal with the "oh but what if my read returns half a message because this is a stream" 4. You don't need to pretend you're doing network programming. Regardless, it's not that big of a deal - this is like my 73th biggest gripe with Wayland, I only mentioned it since GP was talking about network transparency. It's pretty representative of the project though - "We're doing things the way we've always done them, but slightly different. Now rewrite all your software to work with our thing. No, you cannot do global keyboard shortcuts or set window position. You don't like it? We're doing this for free, you cannot critique it."
  - mort96 4mo ago
    You don’t have to hit the kernel for 20 bytes. Buffer up all your commands and send them to the kernel with a single write(). The other side can then read them all (or however many fit in its receive buffer) with a single read(). The only real difference is that the memcpy happens in the kernel instead of the receiver and that the kernel provides a useful blocking mechanism by default so you don’t have to manage that in userspace code. You need some kind of serialisation either way. It can be as simple as “this message has the shape of this C struct”, but that’s the case whether you’re talking shared memory command buffers or sending data over a socket (and there are good arguments for and against in both cases). You’re right that you don’t need to deal with “oh I received half a message” when using shared memory command buffers, but that’s more a code complexity thing someone solves once in wayland-client and then nobody has to really think about it again. It’s not really a performance concern (because hopefully the rx buffer is large enough for it to happen rarely) or application code complexity concern.
    - nananana9 4mo ago
      Sure. But imagine some piece of exotic hardware, e.g. computer mouse, that reports its movement at 1000Hz. If the compositor wants to notify the client as soon as possible, it has to send 1000 messages per second. If you buffer them, you're wasting the hardware's potential, if you don't buffer, them you're doing 1000 write()s per second, which is... ugh. If you're literally going to design the protocol from scratch and require all existing software to deal with it, why not pick the IPC model that doesn't have this issue.
mike_hock 4mo ago
A fundamental part of the Wayland protocol is passing file descriptors through the sockets so this doesn't generalize to network sockets. It also can't be done with shared memory.

ndiddy 4mo ago

If you're fine with RDP, both KDE and GNOME have built-in RDP support on Wayland. If you want something closer to ssh -X, look up waypipe.

sthuck 4mo ago
I might be mistaken, but both need a physical monitor turned on. If your monitor goes to sleep you can't connect/see a black screen. The kde one doesn't support remote user login, and while the gnome one does on paper, I never got it to work. The remote connection situation in Wayland is a major regression.
- ndiddy 4mo ago
  Yeah that's fair, the KDE people have remote login as a goal but it's not there yet. Waypipe is definitely the more mature option at the moment if you need a headless workflow.

dannymi 4mo ago

waypipe works very fine. waypipe ssh XXX

to11mtm 4mo ago

> Microsoft rdp is a great solution for this in windows land. The people who put together TS/RDP are geniuses IMO, it's insane as to how usable it has been for at least 15-ish years...

ethanpailes 4mo ago

https://github.com/wayland-transpositor/wprs https://github.com/wayland-transpositor/wprs

TiredOfLife 4mo ago

Sunshine/Moonlight.

Induane 4mo ago

Arcan has a decent model for this.

TacticalCoder 4mo ago

> I really wish people gave a damn about the “gui over the network” problem x11 solves. Security-wise there are concerns but... Early dial-up Internet days (early for me), 28.8k modem, I was already running Linux, probably on a 486. I also had a very old PC laptop (I think a friend of my parents gifted it to me after he got a new one from work), a 386 I think (with the horrible slow display/refresh rate: a TFT IIRC). I used a parallel cable and PLIP (Parallel Line IP) and X11 networking to send a window manager+browser from the desktop (the 486) to the laptop. So my brother and I could both go on the Internet at the same time. It felt like the future and, honestly, we've kinda seriously regressed when it comes to "GUI over the network".

simonask 4mo ago
Your story here also illustrates why GUI over the network used to be a much more important use case than it currently is. These days it’s unbelievably niche, as opposed to more controlled screen sharing scenarios. I think it’s understandable that it doesn’t get a high priority.

LeFantome 4mo ago

You can do GUI over the network in multiple ways with Wayland.