There's no such thing as "network transparency" anymore. Newer desktop apps are now written to assume GPU rendering and that's local only, even on X11. If they implement software rendering at all, it's a separate code path provided as a slow fallback. If you were using X forwarding to run old clients, you can still use XWayland to forward them. It's the same idea as using XQuartz on Mac, you run rootless X11 on top of another window system. VNC should also work on every Wayland implementation I've seen.
Part of the reason Wayland is hard to port to other Unix systems is because most of them are really far behind in kernel APIs compared to Linux. Wayland doesn't really have userspace drivers like X11 did, the current implementations assume that the kernel is just going to handle all of this. The other kernels really need to be implementing evdev, DRM and KMS to get the full range of support for input and graphics hardware. Without those APIs, those other kernels are on their own trying to figure out how to get modern hardware to work and how they're going to plug random drivers into Wayland, when that model is obsolete as far as Linux is concerned.
At one point I had a working glx(opengl using a x11 transport) setup, In short the X client(running on a remote machine) would send it's opengl stream down the network and the X server would render it using it's GPU. It was pretty cool to see accelerated graphics for a program running at the far end of a ssh session.
When sgi ported gl to X11(glx) they were very careful to use only the network transparent communication paths. The idea was you would run your program on the supercomputer down the hall and display it on your badass graphics monster of a sgi workstation. The feature has only worked intermittently since then as future maintainers were not so careful.
edit: I found a guide, no idea if it still works, The feature was always rather niche and fragile.
> Wayland is hard to port to other Unix systems is because most of them are really far behind in kernel APIs compared to Linux. [...] The other kernels really need to be implementing evdev and dri3 to get the full range of support for input and graphics hardware.
Other Unix systems are indeed far behind implementing Linux-specific interfaces. Windows and macOS will likewise have a hard time.
Are we reading the same thing? Those issues show that it materialized years ago:
>FreeBSD and NetBSD have epoll-shim which implements epoll through *BSD-specific kqueue
The shim works fine already, why fix what isn't broken?
And it's not that those other systems lack Linux-specific interfaces, it's that the ones missing those APIs lack any interfaces for these things at all! There's no way to be portable here, there's nothing to port to! If they decide to implement this eventually, why not copy the Linux API that's already open source and we already know it works, instead of reinventing the wheel? Alternately, Wayland implementations could add (limited) support for userspace drivers but why bother with this when we already know it's an inferior solution that should eventually be replaced with a kernel API anyway? And BSDs have already implemented parts of those APIs separately so we know they don't actually have a problem with them!
> The shim works fine already, why fix what isn't broken?
If it works fine, why not import it into the project?
> Alternately, Wayland implementations could add (limited) support for userspace drivers but why bother with this when we already know it's an inferior solution that should eventually be replaced with a kernel API anyway?
FreeBSD and OpenBSD are slowly doing exactly that. But DRM, GEM, etc, aren't just any generic API, they're a constantly evolving blob of Linux-oriented calls and data structures. Though at the end of the day this is probably the most defensible aspect of it. And an important distinction here is that the drivers issue pertains to Weston, whereas the kqueue issue applies to libwayland, the ostensibly environment agnostic library which implements the Wayland protocol (libwayland and the Wayland protocol are basically one and the same as the protocol is basically an old-school RPC mechanism inextricable from the implementation as a practical matter).
But none of this need be debated if we just dropped the pretense that Wayland or the Wayland community cared about anything other than Linux. Wayland is simpler than X less because it's better designed and more because it redefined the problem. Network transparency? Not Wayland's problem. Portable across OS and driver environments? Not Wayland's problem. Input device management? Not Wayland's prob^W^W^W....
>If it works fine, why not import it into the project?
Why? The shim is generic, it's for porting any Linux programs.
>And an important distinction here is that the drivers issue pertains to Weston
It would also affect the other Wayland implementations, which would need to adopt the same driver system. Those drivers would have to duplicate a lot of code from DRM and Mesa, it's just not worth it to put all that code into another library and then make Weston use it.
>But none of this need be debated if we just dropped the pretense that Wayland or the Wayland community cared about anything other than Linux.
Again, what is there to port to? Those other systems are behind in supporting the APIs needed for modern hardware. There's no alternative to DRM, GEM, KMS, etc.
>Wayland is simpler than X less because it's better designed and more because it redefined the problem. Network transparency? Not Wayland's problem. Portable across OS and driver environments? Not Wayland's problem. Input device management? Not Wayland's prob^W^W^W....
I think you know that X11 wasn't exactly good at any of that. I would think BSD users appreciate all of that because they all have different opinions on how all those things should be done.
The common web browsers or web-based apps are all using hardware accelerated Skia. Almost nothing uses the core X11 APIs anymore.
I'm honestly confused when I hear people say they still use X forwarding and it has no slowdown. It's known to be one of the worst possible options for remoting, the core protocol doesn't even support image/video compression. RDP runs circles around it.
I don’t know what to tell you. I use Firefox every day over X forwarding and it seems to work just as well as anything else with no noticeable slowdown.
This is exactly my confusion, why people say there is one. I guess things would be different if I was trying to do it over low bandwidth high latency sat connection or something. At least with connections as slow as 50mbps I have not noticed any issue, I don’t have anything slower to readily test to see what people are talking about. I’ve no doubt it’s theoretically slower due to e.g. compression but that doesn’t seem to be a big practical concern at least for most connections and use cases.
I’ve found it highly concerning because the other solutions will not work for me, but adherents seem to insist what’s working for me doesn’t.
I mean if you have a high bandwidth connection and you want to only transfer raw uncompressed software-rendered images then sure, go nuts. For me that lags horribly and it's pretty much broken if you try to remote a fullscreen window above 1080p. It's not exactly "network transparent" if it only works in a very contrived network situation. What do you think a remoting protocol is supposed to do if not compensating for bandwidth and latency issues? These are really basic things (bandwidth negotiation, latency compensation) but they were just never added to X11. And it's not like people didn't try to add them either!
Edit: I want to say that nearly everything in X11 is like this. It seems to work ok at first glance but it breaks horribly when you get outside the design parameters of a mainframe in 1987. So basically, transferring software-rendered images over a high-bandwidth LAN connection and that's it.
I haven’t had any trouble with 1920x1200, but I haven’t tried to watch full-screen 1080 video or something either. Probably the most intensive thing I’ve done is watch IP camera streams on Firefox over X forwarding.
I understand that not everyone has > 50 mbps connections but I don’t think this is a contrived fringe edge case either. Meanwhile, the present alternative of “just use rdp” or “just install this package” is completely infeasible for me. And I mean, ant some point, bandwidth is a factor no matter what you do, though I agree more efficient is theoretically better. Unfortunately my job is going to get a lot harder down the road when X is retired for good.
If your IT department at work refuses to give you a modern solution I think that's their problem, not yours. They should just know, X11 forwarding was already obsolete decades ago. They're just signing up for trouble and misery with that.
I doubt that X11 is going to disappear for good. It will still always be around for running the odd old X client or for historical curiosity. Just like how you can still emulate the original Macintosh (released the same year as the original version of X!).
We don’t have an IT department per se but hundreds of offline sites consisting of thousands of servers each which cannot be changed in this manner and for which neither I nor any person I have ever met has the option of complaining that they’re using “obsolete” solutions that happen to work fine. The more likely end result is that there will simply be no GUI available on most servers when more recent OS releases are deployed and we will shrug and life will be worse.
So I guess you can say it’s someone else’s problem but it sure feels like my problem.
I can't understand the situation here. Why wouldn't a more recent OS release have a VNC server available? And why is a web server being used to run firefox? Shouldn't that be run on the client? Why are you even installing a GUI on a Unix server? It seems to me like something is very backwards about your setup.
Part of the reason Wayland is hard to port to other Unix systems is because most of them are really far behind in kernel APIs compared to Linux. Wayland doesn't really have userspace drivers like X11 did, the current implementations assume that the kernel is just going to handle all of this. The other kernels really need to be implementing evdev, DRM and KMS to get the full range of support for input and graphics hardware. Without those APIs, those other kernels are on their own trying to figure out how to get modern hardware to work and how they're going to plug random drivers into Wayland, when that model is obsolete as far as Linux is concerned.