| ▲ | ulrikrasmussen 2 hours ago | |
For me, TUIs compensate for the fact that I can't get good remote GUI rendering on Linux. Yes, X11 tunneling exists, but the experience has always been abysmal for me for anything not hosted on a machine that sits on the same LAN as the client. For Wayland I don't even know if such a thing is possible since I don't think the architecture supports it. But the terminal is just fundamentally the wrong basic abstraction on which to build a structured GUI, it just happens to require few enough bits to be sent over the wire that it actually works reasonably well over SSH as opposed to pushing graphics. | ||
| ▲ | seba_dos1 32 minutes ago | parent | next [-] | |
> For Wayland I don't even know if such a thing is possible since I don't think the architecture supports it. Not only forwarding is trivial with Wayland, it also tends to provide better experience than X11 does. | ||
| ▲ | bitwize an hour ago | parent | prev [-] | |
> Yes, X11 tunneling exists, but the experience has always been abysmal for me for anything not hosted on a machine that sits on the same LAN as the client. Good performance with X11 is possible if you avail yourself of the X11 primitives. This is where Lilith Nyan-Nyan (she/they/it, mastodon lilith@catbox.gay), core Wayland developer, pipes up and says "OwO nobody develops like that anymore :3 everything is rendered client-side on the GPU, and then zero-copy transferred to the compositor for display... really that's the only function the X server has anymore, and wayland is a better architecture for this uwu" But what Mx. Nyan-Nyan, and a lot of developers of her/their/its generation don't realize, is that in the past Unix developers strove to write programs with UIs that were usable across network lines, and availed themselves of the X11 protocol's graphical primitives to do just this. Emacs, for example—particularly emacs-lucid—is incredibly snappy even when an Emacs in the cloud is rendering to your local X server. If you write things the modern way, which developers largely do assuming a 100% local display, then in the remote case the X client will have no choice but to ship uncompressed pixmaps of each frame over the network to the X server, which greatly slows things down. What we are seeing is that "the modern way" is beginning to be applied to terminal apps as well! Claude Code, for instance, has a React-based layout and rendering flow (does it use Ink?), and (until recently?) redrew the entire chat history on each update, leading to the slowdown and flicker problems it had. It would be absolutely unusable over, say, the kind of 9600-baud link that was commonplace back when people used actual terminals to connect to large systems (and ran full-screen apps in those terminals!). It's only a bloat cycle or two more before these programs start to struggle over a typical ssh link, too! We've utterly lost the plot when it comes to software. | ||