Hacker News Reader

> Network operation. X will always be better here because it was designed to be

Excuse me, but BS. At least for anything of actual relevance.

X11 networking works okay for stuff that looks like a classic X11 app. That's things like xcalc. Any modern text editor, web browser, or anything else is going to be dog slow.

X11 has a bad networking protocol that's way too latency sensitive, and as a result is nigh unusuable without something like NX, which puts a local cache in front to get rid of that latency.

No, I'd say X11 wasn't designed to be run on the network, in that no particular care seems to have been taken to deal with latency and bandwidth issues. It's more of a feature that could be had for free, because if you can use an UNIX socket, you can also use a TCP one with minimal work, so might as well allow it.

> No, I'd say X11 wasn't designed to be run on the network [...]

That's just wrong. X11 was designed from the ground up to be used on the network. It just happens that nowadays requirements are different from when it was originally designed.

Running X11 on the network was quite a thing in Unis all over the world, where you could have dedicated dozens of X11 graphic terminal servers (tektronix used to make good ones) connected (100Mbits) to a single mainframe, and everyone running an Xemacs session without slowdown.

Wayland design is all about framebuffers, which clearly shows how focus has shifted. X11 was not designed for pixmap heavy, shader heavy scenarios.

Also, X networking was mostly used within local university and company networks, and not over the internet backbone. Well-designed local networks can be very low latency, often noticeably lower latency than disk I/O.

To be fair, X doesn't work that well over even local networks with modern apps.

Serving X applications (eg: Chromium) from the Raspberry Pi I'm targeting to the Mac I'm developing on is an exercise in futility, even if it does make 'download this to the target' easier. It's a lot faster to run Safari on the Mac and scp the download to the Pi, just because of interface latency issues.

Well, I don't think that network at the time was faster than SCSI, but that's a fair point that X11 isn't quite "internet ready" (though these days with a dedicated VPN you'd probably get very good performance on the core protocol).

I remember running Hummingbird Exceed on Windows to access the “proper” applications on Solaris in a stock trading environment (like 25 years ago)

Actually, though, toolkits that still have XRender backends will run relatively efficiently over the network. To be fair, this is becoming a thing of the past slowly, but it's not gone yet: Qt 6 re-added the XRender backend due to complaints of how much slower X11 networking was!

Granted though, it does nothing for apps using Electron. However, try e.g. the Dolphin file browser on a 4K display over the network, and you'll find it is clearly faster than should be possible.

Probably I should've made it clearer, but imo the bigger problem is that tweaking Waypipe to replace old uses of ssh -Y shouldn't be needed; it should be possible for it to determine what possible options can be used and switch things around to deal with CPU or network bottlenecks most effectively. Easier said than done. There's also still some bugs under Waypipe; it's an understandably challenging problem.

In the 2010-2013 era, i did most of my computing over X over ssh on a fast LAN. At the time, YouTube and other video stuff worked fine, and my environment felt as responsive as local computing.

Your experience doesn't match with other people's.

Remote X over fast low latency networks is fine, a near local experience-- even running things like firefox or gimp. (And for classic apps it's indistinguishable from local). The wayland world alternatives like using RDP are painful to the point of usability even over a 10gigbit network, peg the cpu... and are really only good for rescuing something that's stuck or providing a bit of tech support.

Yes, over a high latency network remote X is sucky but seldom much worse than RDP.

> No, I'd say X11 wasn't designed to be run on the network

That's very wrong, the whole point was to run over the network.

It worked exceedingly well even in the earliest 90s (modulo bandwidth expectations of the time) and continues to work wonderfully 30+ years later.

No, it doesn't, it works like shit because that's not how modern apps work anymore.

Modern apps draw all their UI client-side onto a surface which is then sent to X for display. IF ONLY we had a windowing system that was based around simply compositing together the various surfaces that the apps draw into a complete image of the desktop. Since this is a step away from the complexity of X, we could give it a name starting with W...

> No, it doesn't, it works like shit because that's not how modern apps work anymore.

Don't know what to tell you, your experience is different.

Many of my computers are on a rack and I run everything on them over X displaying to my desktop. Works just fine.

Try running Firefox over your networked X connection.

Go ahead, I'll wait. Literally, I'll wait.

> Network operation. X will always be better here because it was designed to be (at least with toolkits that can still take advantage of XRender.)

That is by no means clear cut - X is competing against specialist applications like VNC and there is a real question mark over whether a critical application uses OpenGL. X can easily win on toy benchmarks that play to its strengths, but it is rare in the extreme for that to matter.

Why do we need a remote server to provide a GUI that doesn't involve OpenGL? It happens, but not often enough to be an advantage. SSH + VNC is a more reliable and general combination, the X protocol is a maintenance and security liability. Personally if I'm logging in to strange servers I'd rather be learning cross-platform skills that carry between Windows, Mac and Linux.

> X is competing against specialist applications like VNC

I stay with X because it lets me have multiple independent logins with their own desktops. The last time I checked, Wayland doesn't support this, and this is well outside of what VNC does. This is a very important facility to me.

Can you elaborate on this one? You can of course have multiple Wayland displays at once, and/or multiple VNC servers. But, presumably, you're talking about something entirely different here.

X lets me log into a machine multiple times simultaneously, with each login having its own, independently operating desktop. Wayland doesn't support this (or didn't the last time I checked). VNC does something entirely different from this -- it just shares an existing desktop remotely rather than providing a unique independent desktop (complete with different resolutions and such, if you like).

So the effect is a bit like VNC in that you can remotely access a desktop, but the desktop you see is not a copy of the one being actually displayed on the machine's monitor. It's entirely its own thing, only visible to that particular login.

> VNC does something entirely different from this -- it just shares an existing desktop remotely rather than providing a unique independent desktop.

Actually, not necessarily; you can use Xvnc to achieve this with X+VNC. It's an X server that serves over VNC.

Can Wayland do this? Yes! But, the problem is that there is no singular Wayland "display server". This is both a big strength and big weakness of Wayland. In this case, it means that I can't point to a single correct way you can do this. However, with the compositor I currently use, SwayWM, it's very trivial: I can start Sway inside of an existing compositor or X server to get a nested desktop. You could use this with Waypipe or X11 forwarding for example. It can also be started with wayvnc inside, to expose a VNC server from Sway, though this is not really any different from starting an Xvfb and running a VNC server inside of it.

> Can Wayland do this? Yes!

Interesting. I remember asking some Wayland devs a few years back about this and they said this use case would never be supported. I'm glad that's changed! It means that if the day comes that I have to use Wayland, I won't necessarily lose functionality.

(Just for clarity, I'm not opposed to Wayland if it can do what I want. But I'm not excited by it, either, because the benefits it does provide are ones that don't really matter to me)

Yeah, as you may gather from my first post, I am not advocating anyone to switch if there's nothing in Wayland for them. But at least with wlroots-based compositors (a decent number of them, but notably not GNOME and KDE which use Mutter and Kwin respectively,) you can definitely do this sort of thing relatively easily. It'd probably be a good idea if every compositor got on the same page here so that the experience is consistent. I'm not sure how to do this kind of thing with every compositor.

Does xv runs in wailand ? xpdf ? fvwm2 ? xterm ? xsnow ?

Does wailand supports window managers ?

X11 apps run under XWayland, an X server that runs under Wayland compositors, almost always by default. It's possible to run WMs under XWayland too, but most Wayland compositors are WMs and handle the WM for XWayland too.

Wayland doesn't have a single display server. Most of what was the X11 display server is moved to the kernel and libraries. So, the WMs ARE the display server.

xv, xpdf, xterm should work fine. xsnow should work, but will only see X windows. fvwm2, it can run on some Wayland compositors, but the better option here would be a compatible replacement: as far as I know, we still don't have an fvwm2 equivalent, but SwayWM exists as a replacement for i3, for example.

I just had to look it up; Wayland has been around for 14 years already. How much software takes 14 years and still isn't stable? How big and / or complicated is this problem and the codebase anyway?

Ever heard of GNU Hurd ?

For one thing, Wayland is a protocol, not a specific piece of software. But mostly, that progress has been non-linear. A ton of it is not about writing code, or even about Wayland itself; much of it tied into the modernization of the Linux and general open source graphics ecosystem, moving it away from being oriented around X.org specifically and implementing modern features like generic buffer management and kernel modesetting. A lot of setbacks have been simply waiting on NVIDIA to support these modern facilities well in their still-very-popular proprietary drivers.

HDR support has been in the works for years. Why? Well, nothing terribly specific to do with Wayland: there has been a ridiculously deep dive into the entire space of color management, wide-gamut colorspaces, etc. to try to build HDR protocols that don't merely just get things out the door, but ideally support current and future use cases for the foreseeable future, have good backwards compatibility and handling of unaware apps, etc. These things are non-trivial and can't be solved by writing code or staring at GDB. (Not to mention there are few drivers that can currently support this, so it's also a bit of a chicken and egg problem.)

That is to say, Wayland is a lot less of a software problem than it is a design and social problem. And as you can probably see, ultimately, Wayland will be nobody's favorite, but hopefully with time, it can at least be everybody's favorite.

PulseAudio is still not there after 19 years.

On the other hand, PipeWire is?

Thank $deity, it is. PipeWire actually works well.

It has already surpassed it.

Regarding your post scriptum,

It is clear to me as a FreeBSD user that Wayland is primarily developed first hand for Linux.

To me, Wayland looks like a threat rather than something I should embrace.

I remember when it was a given that free software was developed to support a wide eco system. What happened?

“There is even one for macos” XD

I disagree, though. Wayland itself is definitely not meant to be a threat to BSD.

There are some anti-patterns in the Wayland ecosystem that lead to arguably unnecessary dependency on things like DBus, but Wayland itself doesn't actually need much and you should find that SwayWM works fine on FreeBSD. However, the graphics stack and drivers for BSDs are a little bit behind, which is arguably a bigger threat.

X hasn't been good at network in the past 2 decades.

From my experience, Windows RDP has always worked way better, and when we were confronted with the need of having to do RDP access on Linux, we always found the more primitive VNC far superior.

But even that is the past. Today you can stream your entire desktop over the network with highly efficient modern video codecs, courtesy of the hardware encoders built into your GPU.

In 1999 or 2000 I read a paper which compared remote desktop protocols and RDP was the clear winner, even then.

I can’t get to launch obsidian on arch-sway without the ozone flags :/