In my experience, running X11 over a network worked very poorly.
There is significant overlap between former X11 developers and Wayland developers. They didn't drop it because they are incompetent which seems to be what your are implying. The people that decided to drop it are probably the people that know X11 the best.
>In my experience, running X11 over a network worked very poorly.
Well in my experience, running X11 applications using network transparency works perfectly fine. It can be a life saver when your server is a proprietary UNIX, these are still in many Fortune 500 companies.
I have/still use network transparency as: Linux/BSDs <-> BSDs/Linux and Linux <-> AIX.
I even ran a few (Xlib/Motif) applications as "Linux <-> Linux <-> AIX" where the middle Linux was a pass through server without any issues.
So, No issues with network transparency, that is why I will avoid Wayland as long as I can.
To the article, Wayland on OpenBSD looks like a very extremely project, wish you luck.
I haven't tried it (because i do not really need network transparency and i'm using Xorg anyway) but supposedly this project[0] implements the Wayland protocol on top of Xorg in a way that integrates mostly seamlessly with X11-based desktops (instead of creating a window and running Wayland inside it as if it was a monitor isolated from the rest of the desktop).
It might be useful to be able to run Wayland applications remotely.
Waypipe can run Wayland applications remotely in a more modern fashion that doesn't suck ass on all but the fastest network links.
But this will be a useful stopgap for those who stubbornly cling to X11 (or are forced to, e.g. by NVIDIA hardware) as more and more useful software drops X support and goes Wayland-only.
> more and more useful software drops X support and goes Wayland-only.
I can't think of any such case, any example?
Besides even if X support is dropped by an application, 12to11 - or any other Wayland implementation that runs under X - will keep it working. It isn't like most programs use X directly anyway.
Well I believe there is foot. GTK devs ae planning to drop X11 support in gtk5 and they will start work on that after gnome 45 release so in a couple of years, all gnome apps
Foot was made with Wayland in mind and there are tons of alternative terminals anyway so i don't think its existence is going to inconvenience or even affect at all any Xorg users.
GTK5 might be more of an issue but so far programs barely use GTK4, let alone 5. I'm not sure GNOME applications are used much outside of GNOME. In either case i'd expect something 12to11 to work with those by then (if it doesn't already).
And TBH i'd expect there will be X compatible programs for a very long time to come.
Since GTK4, GTK is a dead framework. I don't even have it on my system. GNOME killed GTK, so I'm waiting for the community to finally fork GTK3 and make a compatibility layer for GTK2, because there are a lot of GTK2 applications.
Waypipe requires software rendering from any server that doesn't happen to have its own headless GPU. As long as Wayland doesn't deliver a remote rendering protocol, the best path forward seems to be shipping Javascript apps to a browser on the end user's machine (where his GPU will be available).
> Waypipe requires software rendering from any server that doesn't happen to have its own headless GPU.
X has to do that with DRI and client side rendering too, doesn't it?
> As long as Wayland doesn't deliver a remote rendering protocol, the best path forward seems to be shipping Javascript apps to a browser on the end user's machine (where his GPU will be available).
Why does that seem like the best path forward? Seems crazy. For incidental things, admin, etc., software rendering would be fine. The right path forward for a high performance application that needs to ship data to a client that can render it would be to transfer that data, not the drawing of it.
It was an architectural mistake to start bypassing GLX and depending on DRI at each app, and Wayland wants to cement that. That’s why we see so many webapps where we would have expected remote windows driven by a backend server; Javascript became the GPU-local end of a lot of opaque rendering protocols to fill the gap.
> It was an architectural mistake to start bypassing GLX and depending on DRI at each app,
1. Well I assert that it was not an architectural mistake. So that doesn't really move the conversation.
2. Whether or not it was a mistake, does not change how things are. So you can't really use that as a point against Wayland for X.
> and Wayland wants to cement that. That’s why we see so many webapps where we would have expected remote windows driven by a backend server; Javascript became the GPU-local end of a lot of opaque rendering protocols to fill the gap.
Client side has been driven overwhelmingly by Windows in the past decades though, so I don't see how that is the reason. The number of javascript apps caused by DRI in X must be approximately zero, and caused by Wayland exactly zero.
I imagine a man surrounded by the X11 books (which is how O'Reilly got it's start) strewn around a messy desk, 2 large monitors and a small desktop system beside them. On the floor, a Sun Enterprise E450 in its deskside enclosure.
> It started working poorly when X clients started rendering everything locally in the client and simply pushing pixels to the display server.
Which means it works poorly for modern apps. Modern apps use the GPU for client-side rendering.
And it absolutely worked poorly even in the 90s. It was virtually impossible to run X apps over anything but a fast local LAN. That's what "Broadway"/LBX was about. It was kind of a failure.
RDP has been a better networked display protocol than X for a couple decades now. Let's not fool ourselves that X isn't obsolete on every axis.
It has worked great for me for decades and I currently stream live video over X11 on my LAN.
And no, I don't think the developers are incompetent, they obviously have different priorities than I do. Being able to shift an entire desktop environment over a network is something I've done since I started using the internet in various ways and I'll echo the sentiment that it seems incredibly useless to remove this feature in today's world.
To be quite honest I'm tired of this holier-than-though attitude. They dropped it because they are lazy or just don't want to support it and they should just be honest about that. They certainly didn't do it because it makes my life easier and I wish they would stop telling me I'm in the wrong.
X11 over a network, even a LAN is a "last resort" kinda thing for me. It's neat an all, but as much as I dislike remote desktop and VNC, it's still better than X11.
The last time I had it working well was in 2005 using a full desktop session across a local network. The bit about only getting the one application across has always been a bit wonky. That's not to say that you can't do it, but it's not really a daily driver sort of thing.
> In my experience, running X11 over a network worked very poorly.
In my experience, when combined with SSH compression (ssh -XC) it works well enough that even running Firefox over Internet is usable (although with noticeable latency). Without compression, it is unusable (for Firefox) even on gigabit LAN.
In my experience running Firefox over X11 remotely is fine as long as you only use X11 and don’t wrap it in SSH, i.e. instead you expose your local X11 server port to the computer running Firefox and use the DISPLAY environment variable to point it at you local X11 server. Secure the connection with Wireguard and it’s fine. With SSH I’d see frame tearing all the time, regardless of compression options.
x2go/freenx it's must better than the old X11 protocol. OFC, if you use legacy systems, no problems using your old Irix machine or similar, but from modern *BSD's/GNU's, you can compile x2go in a breeze and get a much better support on rendering/speed and detaching.
It worked well for me at my university in 1990. We had a large room full of 1024x1024 X terminals. We run our programs on some HP-UX shared server and displayed the pixels on those terminals over a 1 Mb/s LAN. No glitches.
There is significant overlap between former X11 developers and Wayland developers. They didn't drop it because they are incompetent which seems to be what your are implying. The people that decided to drop it are probably the people that know X11 the best.