SSH into a machine and open a GUI tool. I'd love to watch you do that and enjoy 2 FPS via X11-via-ssh.

I've specifically designed juggler to do exactly that.

You run it on some headless machine, and point your browser at the HTTP server it creates to see the full GUI. It uses Yjs to make that connection as efficent as possible, and it works great.

The desktop app is literally doing the same thing internally - it runs a headless server process and serves the GUI to its own window. But you can stretch that over a network and it's the same experience.

I can even connect to it via a TURN server, from my phone on a cell signal, and although it's not as snappy as running locally, it works pretty well.

But a TUI does the same thing except the client side doesn't need to have anything installed.

I'm currently using an R-studio server session running on a server half way around the world, via a gui web interface. It's fast and smooth. How on earth could that be?

if only there were a way to tunnel web servers over that very SSH connection and use a proper web UI, something HN has always been obsessed with.... oh well i guess we're stuck with a VT100! :( there's nothing we can do!

You mean like ssh -R? (And some magic to make host header correct, likely local hosts file)

Why would I want to use a web browser when 90% of my work is in the terminal?

My $0.02; I use pi every day, it's always running somewhere for various kinds of tasks (no vibe coding). I run it in `sbh`, a slop cannon wrapper around `bubblewrap` that ensures that the agent only has access to things it could possibly need. The code is short and you can audit it yourself.

I run it like `sbh --net pi` or `sbh --net --docker pi` depending if I want the agent to have docker access. The result is that ~/src/my-project gets mounted as `/w/home/lion/src/my-project` and any LLM I've tried understands that this is a sandbox implicitly.

I strongly suggest everyone who uses a harness, of any kind, to copy it and edit it to better suit one's setup.

sbh: https://github.com/lionkor/sbh

For a second I was hoping that Pi users would be the kind of people to not enjoy nags about improvements.

Apart from a different terminal app, try `/settings`, find the "TUI mode" or whatever, and set it to fullscreen. It fixed all my flickering and other issues.

I love how consistent pi has been, especially in regards to not breaking ux

Hi, this might not be obvious to you so I wanted to explain it:

Testing on a single device, or two devices, is not enough. I'm on a laptop with 96 GB ram and a Ryzen AI 9 HX PRO 370, and it's running at 3 FPS.

The crucial part is browser performance and network latency. You need to test across multiple browsers, but also evaluate frame times, CPU load, GPU load, etc. so you can make a reasonable estimate whether it's fast or not.

Then, when you realize that its not good enough, e.g. on firefox, you use firefox's profiler to see which parts are slow. LLMs would guess, probably, but you have to measure.

Welcome to software engineering.

Until someone steps into the sun, or smokes, or does literally anything that causes cell mutations (which is, well, almost anything).

If you want this type of language, go to OpenAI. If you compare announcements from these two, you'll see this consistently apply.

Can someone explain to me why nuclear HAS to be profitable?

If a power source is profitable on its own, it can be financed by private investors. If it is unprofitable, it needs to be financed at least in part by the state, so it would come at the cost of the taxpayer.

Well yes but as soon as you log this on the backend, you have telemetry, no?

There is a meaningful difference between a generic "load all flag values" call that is identical for all users and some actual telemetry which sends application context to the back-end.