While common X use evolved way from network (modern apps passing bitmaps around instead of primitives), the network architecture still have one huge advantage over Wayland: it is a client server architecture, so one can restart things without losing state. That is, under X I can crash/restart the DE without losing any application state, open apps continue to run and simply connect to the new instance. But under Wayland any crash anywhere on the stack means all apps are killed and all work lost.

This is not mandated by the protocol — one is free to create a separate server and window manager program under wayland just as well. But I really don’t find it meaningful — such core functionality should just not crash (just as Xserver itself is not prone to crash, because than your work is also lost).

Not really; there is not a lot of support in the Wayland protocol for multiple clients sharing objects. See for example how difficult it is to emulate XEmbed, systray, wine, etc.

How is that relevant? A client and the server is different processes already. Sharing it between 2 process or 3 is at that point meaningless. (Also, not everything has to be shared to a dumb window manager module)

No, is not really meaningless. Basically, you assume from the server that each relevant object is owned and accessible by 1 client only. If 2 clients want to "own" the same object, they have to coordinate between themselves using an entirely different protocol so that only one client owns the object from the PoV of the compositor (you also can't do it through Wayland since it lacks generic IPC support, which X11 has even if poor). See https://www.winehq.org/pipermail/wine-devel/2021-December/20...

If you want to make a separate window manager, it is likely that the result is going to be incompatible with most existing clients. But this seems par for the course for almost every Wayland extension so far (see Gnome...).

Having more than one mutable reference to the same thing already begets advanced synchronization if that’s what you mean, but I don’t see how is that relevant.

And beside gnome and kde there is a third big group of wayland compositors based on wlroots which does support some form of common set of extensions not in core, effectively making you write only the wm part.

> but I don’t see how is that relevant.

Because this prevents creation of a separate window manager program. You can do all of this with the core protocol in X11. You can't do any of it in Wayland almost by design. The entire idea of a client getting simultaneous access to the objects of another client is not in the protocol. You cannot render in another process surface. You cannot even iterate over its windows! The role of the compositor is hardcoded in the protocol design.

The closest thing you can do is to write some type of modular compositor which speaks _yet another_ protocol with the window manager module (or even exists within the same process). But this is not like in X11, where you plug new things (e.g. a new WM, a new pager) without having to restart the X server, much less having to change it.

that's bullshit. I use Qt apps and they are still in 2022 able to use X11 paint commands to render over the network in a way that is much, much, much more fluid than e.g. rdp, vnc or whatever other bullshit like that. Many GTK apps also seem to work fine (though not all, Geany is snappy while Gimp isn't for instance)

see how it looks: https://streamable.com/t9foij

> much more fluid than e.g. rdp, vnc or whatever

RDP also sends draw calls, and as such cannot be compared to VNC or similar. It's not even a remotely close comparison in terms of fluidity. I haven't compared it to Qt over X11, but I wouldn't be surprised if RDP wins over an internet link.

The lack of a proper RDP alternative is the primary reason I don't use Linux as my main driver. I keep checking every 12 months or so, but alas.

> RDP also sends draw calls

on linux with native linux apps ?

I haven't checked in a few years, but I imagine they haven't implemented that yet given how tightly RDP draw calls maps to the GDI.

Point was that RDP in its natural environment can forward draw calls, and as such is more like X than VNC.

Don't forget NX protocol. It's far more faster and lightweight that VNC/RDP.

As far as I know NX is just a layer of compression on top of the X11 protocols though, e.g. it uses zlib for compressing paths, jpeg for compressing pixmaps, etc.. Not sure it'd actually help that much on gigabit ethernet.

One part of it (the NXagent) is centered on reducing round-trips rather than compressing the protocol. May not be worth on low-latency links but it is a deal-killer in high-latency ones.

RDP is far, far more advanced than X11. In addition to doing "GDI over the wire" much like X11's draw calls, RDP supports compressed bitmaps and streaming video, remote audio, remote file system, remote USB, clipboard sharing, and more recently remote GPU. (Yes, I know about GLX, it's incredibly old and hasn't been updated.)

RDP is to X as PowerShell is to bash: better than the Unix standard thing because it isn't weighed down by Unix community baggage.

Eh, no. PowerShell is trash. And instead of Bash I prefer ksh and for anything more complex, perl, which curb-stomps PowerShell by large.

Also, you were right on RDP, but something less is more.

If any, I prefer plan9/9front's drawterm/cpu which runs circles over Unix/Linux VNC and RDP. By a huge mile.

And 9p>>>>>>>> NFS/SMB. For anything else, use FS' permissions FFS, and choose wisely what you share.

> If any, I prefer plan9/9front's drawterm/cpu which runs circles over Unix/Linux VNC and RDP. By a huge mile.

How can this [1] code possibly be faster than modern hardware accelerated blitting? I don't see a line of SIMD in there.

[1]: https://github.com/9fans/drawterm/blob/master/libmemdraw/dra...

Call me odd, but 9front on native machines looks smoother than most composited desktops here.

composited WMs are so frustrating to use when you're used to non-composited

Powershell is not at all trash. Being object oriented makes it very easy to do on the fly inspection of your data and allows extremely powerful pipelining. If you want even more functionality, you can load in .NET libraries at runtime. Working with Powershell really feels like working with Python but using a different syntax.

You have PERL REPLs like that with Task::Kensho leaving out PSH and .Net libraries on the dust.

What you could do today with PSH and iPython Perl folks did that before with far more modules thanks to CPAN and C bindings.

GLX is not much older than RDP and has also been updated several times.

I assume you use it through a local network where it will be reasonably fast. But then please compare it with any sort of “modern” video streaming approach on the same network as well.

here's the exact same case with VNC, on the same network: even with the smaller resolution and lossy image compression, VNC manages to be quite slower than X11

https://streamable.com/50fdss

I tried steamlink on the same network to put games on my TV, and it is barely useable with absolutely horrendous image compression (got a GTX1080 GPU so that's likely not the culprit)

Note that Qt5 does not send paint commands by default, it sends bitmaps. You need a special env var to revert to drawing commands.

VNC outperforms it, which is saying a lot since VNC is terrible. Remote x apps were always this selling point in linux culture and I always thought I was doing something wrong because they were so incredibly slow until I realized its the protocol that's just slow.

It was fine until apps ended up doing everything on their end and push pixmaps to the X server. Back in the xaw and motif days, it was fine.

Well yeah, but then you could just as well use an ncurses app through ssh for the same “experience”