A lot of us do the vast majority of our non-browser work on remote systems. GUIs are objectively bad for this

No. When the communication side is actually done thoughtfully, GUIs deliver superior experiences even in remote environments.

VSCode SSH extension is one of the most widely developer-used proof against this. Windows' RDP is the other one where many engineers and POS personnel have experince using them. Many electrical and mechanical engineers still use Windows RDP at my work to run simulations. The connection is responsive enough to survive their home-to-office VPN connection. I set up complex chemical simulation software that is accessed by clients of a HPC cluster over 1000s of kms away.

VScode has a really efficient protocol that communicates only that's required, Windows RDP can declaratively send UI component changes as long as one uses Win32 or WPF. It can also reasonably compress the data to even survive dial-up levels of bad data.

We use multi-attendant video conferencing day to day with whiteboarding extensions. If there is will, efficient and amazing remote-GUIs are easy.

Well in plan 9 they work fine remotely so I wouldn't say they're objectively bad.

X Windows was invented on the 1980's and isn't the only way to graphically access remote systems.

Modern cloud systems shouldn't even have shell access, immutable containers with telemetry data.

> Modern cloud systems shouldn't even have shell access, immutable containers with telemetry data.

Genuine question, what is your alternative suggestion to accessing lower level features then? A hard time I have with GUIs is that their input/output can't be piped. It's much more cumbersome to try to automate a GUI than to automate something in the terminal.

Whilst I get that this is about TUIs, I do believe there is a reason for shell access due to automation. Good abstractions can be put into the GUI, but I'd argue that you should first build the abstraction, then put a GUI on top of it. AWS is a prime example, any of their APIs can be used w/out AWS Console.

Look at Plan 9's devdraw. https://man.9front.org/3/draw

devdraw can be thought of as a 2D rendering engine. You load assets like text, bitmaps and so on then issue draw commands to render them. There is no SSH. Instead you connect to a remote machine and export resources served by your local machine including your keyboard, mouse and display, each of which is a network transparent microservice. The window manager, Rio (and others), multiplexes access to these microservices. You can run a graphical program without a window manager, e.g. you can boot right into Doom or the Acme editor. It's seamless and can run over any pipe that can push 9P including ssh. If you look at the Sam and Acme text editors you will find they are true modern TUI programs.

Shame we had a cloud ready OS for 35+ years and no one noticed. Instead were living in the 60's with GPU accelerated typewriter emulators.

That one was going to be commercial, hence why.

However I would rather prefer its successor, with Limbo for userspace, although probably not Tk as the main UI toolkit.

The terminal thing emulating typewriter are a UNIX thing, as other graphical OSes, presented a plain REPL, or graphical shell, e.g. Amiga DOS did not emulate any tty.

Otherwise I agree with the spirit of the comment.

Use a REPL.

Since when is pipelining a low level feature?

How do you think OSes like Mac OS (the original one), exposed their low level features, whatever that may be?

Terminal programs are GUIs. So you are using a GUI to access those remote systems. Thus, there's no reason why another GUI couldn't do the same.

Everyone always acts like GUIs couldn't possibly make HTTP requests, interact over TCP or WebSockets, or do other remote communication. But they're actually, more often than not, more well suited for that than browsers for specific use cases, which are the use cases where you'd desire a devoted GUI.

I'll stick with plain old TTY Consoles, thank you.

Okay?

The article anticipates and responds to this: https://sockpuppet.org/blog/2026/08/20/stop-making-tuis/#:~:...

I use an xrdp quite a lot. It works fine.

You can run Wayland that renders into a terminal. https://github.com/cyber-wojtek/waytermirror

That's an indictment of ssh workflows not GUIs.

RDP works fine but it's based on a full desktop experience. Despite having the technology, we don't have the ability to remote in and run a single graphical program in a single window with the same ease.

We need something as seamless as Parallels for remote remote apps. But I guess we just settled on web apps.

Of course there is, waypipe, ssh -X, wayVNC on a headless cage (or sway with appropriate config) session.

Again, we have the technology but it's not how things are done, usually.

What do you run like that day to day?

I use waypipe casually if I have a project on my desktop that I want to work on from my laptop. I even use if I just want to get a Bookmark or Tab from the Desktop PC, since I never bothered to set up any syncing service. Only for nvim I use it's own client/server implementation, it's a bit less latency-affected by the 1%s.

Waypipe is production ready & easy to use. If there doesn't exist a program making use of it for the average user, then it's because nobody saw a it as a solution for any occurring problem yet.

RDP can do a single app.

Depends on whether the devs included keyboard accelerator mappings. With the rise of "touch focused apps", it's becoming rare.

Sure but in this case we're the devs. We're in charge of that and would include them if we're making a gui instead of a tui and want keyboard accelerator mappings.