5 ms·
"What I like about X, that is missing in Wayland, is that you no longer can run the X server on a machine and connect to clients (application) on another." You
by md8z 5y ago
"What I like about X, that is missing in Wayland, is that you no longer can run the X server on a machine and connect to clients (application) on another."
You actually can do this with Waypipe. Also, I'll mention this again: most Wayland implementations include the X server (as XWayland) and support this as a backwards compatibility option.
"If you compare the X server to a web browser and the X client to a web site, isn't very similar? And this is the model that is winning nowadays. ... Why use a full screen web browser, it's overkill, when you could have simply launched a X server on the particular display, then launched an application on a server and connected to the IP of that particular monitor to display everything you wanted?"
It's really not overkill though, people build web apps because the stack actually works well. Developers seem to really want to use those browser features. X on the other hand is very old and hasn't kept pace. The most obvious example I can think of is OpenGL: indirect GLX doesn't really work any more and hasn't for quite some time. It can't really be updated either without complicating everything, because any performant use is going to require loading code into the server. If you want remote GPU rendering, the best way to achieve that currently is to use WebGL and WASM (and later WebGPU when that's ready).
"we are discarding it for something that tries to imitate Windows/macOS (badly, because these operating systems just works well, Wayland doesn't). Is it worthed?"
Well, worst case scenario, Wayland is just a minimal way to get your browser window on the screen. I think this is another big misconception that people have. Wayland generally sits at a lower level in the stack than network applications, and it really has to be this way if you want to support hardware accelerated clients. Wayland is made for the case where you've already decided you have a GPU buffer and you want to put that on the screen. You could build something else on top of it that runs over the network (and this is what web browsers do, it's how XWayland works, it's how your VNC/RDP client works, etc) but somewhere in the pipeline those will need to have that fast local path where they render to a GPU buffer. And that's where Wayland comes in. It's not that the developers are trying to copy Windows/MacOS, it's that you have to do this if you want to get a good experience out of a modern GPU.
- alerighi 5y ago> people build web apps because the stack actually works well Or because there is not an alternative. Building graphical software is difficult because you have to interact with graphics. But, what if we have a protocol where you simply open a network socket and write some messages on it that says "write this text hear", "draw a line from X to Y"? Well, that is how X clients work. > Wayland generally sits at a lower level in the stack than network applications That to me is not a good thing. One of the main advantages of Linux/UNIX systems in the past was that X was a userspace application, and if X crashed the entire computer didn't crash, like Windows does, you restart the X server and you don't loose your work. Of course modern desktop environment crash with X, and that is a bad thing (but an X client can, and should, if the X server crash, just try to reconnect with the new X instance and redraw its window, like you reconnect to any other socket, or worse case scenario the program continue to run just without the GUI!)
- md8z 5y ago"But, what if we have a protocol where you simply open a network socket and write some messages on it that says 'write this text hear', 'draw a line from X to Y'? Well, that is how X clients work." I mean, that is also how the Web Canvas API works. If you want to control this with some messages on a TCP-ish socket then you can use websockets. The web browser already appears to be a superset of all the networked functionality of X. "One of the main advantages of Linux/UNIX systems in the past was that X was a userspace application" Wayland still is a userspace application too. The protocol itself is what is at a lower level of userspace than X was, of course the compositor can also implement high level features as it sees fit.
- alerighi 5y ago> I mean, that is also how the Web Canvas API works. If you want to control this with some messages on a TCP-ish socket then you can use websockets. The web browser already appears to be a superset of all the networked functionality of X. Yes, in a very inefficient way, you end up using 1Gb of RAM to do something that could have been done with 1Mb. Not important for desktops, but for embedded applications? > Wayland still is a userspace application too. The protocol itself is what is at a lower level of userspace than X was, of course the compositor can also implement high level features as it sees fit. Wayland is based on KMS that indeed is a graphic implementation in the kernel itself.
- md8z 5y agoI'm not sure what you mean 1GB. An empty tab on Chromium seems to take about 30MB. Minimal "Hello world" GTK and Qt programs are around the same size. Modern Xorg is also using the KMS API. If you don't want any fancy features and just want to draw some lines then you probably want to skip Xorg and Wayland altogether and use KMS directly.