This reminds me of an idea that I build a PoC of many years ago (maybe 2013 if I recall) that I always felt was the nugget of a useful idea. You would SSH into a server and processes on the other end would emit data which was then displayed in a webapp that was served from a localhost port, with a local backend that consumed the data. So for example a short-lived web-based remote 'top'. I did it as part of a company-internal hackathon and thought it was really cool, but nobody else was impressed with it. It was a very half-baked idea, and this looks like a fully-baked version of it. I'll check it out.
A native graphical shell for SSH
61–70 of 239 posts
Re: A native graphical shell for SSH
#62Do not do this. There are many, many excellent long-standing security and "web control plane isolation" reasons browsers are not permitted generic socket permissions. The closest mechanical analog that comes to mind is why 3-wheeled ATVs are a bad idea.
I think it's okay as long as:
- sockets are blocked by default, until they are added to an allow-list explicitly on the server side
- True sudo awareness ensures root sockets aren't reachable without the sudo password. (This capability is important, because otherwise you create an incentive for people to run root backends with user-accessible sockets.)
Re: A native graphical shell for SSH
#63In general I would like to see a web browser escape sequence for console applications. Just send a command to the terminal to connect a web browser to your stdin/out and present any UI you want over html. The terminal can then open a regular socket listening on localhost and act as a CGI server. For security the terminal should pick a random IP in the localhost range and a random URL. Technically that is security by obscurity, but guessing a cryptographically secure URL should be hard enough for attackers. The reasons to do it as an escape sequence and not just have the application open a socket and start the browser are: To enable remote GUI; To avoid the complexity of each application implementing networking; To enable better desktop integration, since the terminal itself is part of the Desktop Environment, so it can start a DE-specific browser, preferably in single-application mode. Also, it should be possible to automatically put the application in the background so you basically just run GUI applications like normal.
Re: A native graphical shell for SSH
#64It's a cool video and I like the idea in general. The author mentions that the code runs in a sandbox. I'm surprised that WASM hasn't come up. You want the code to be platform agnostic anyway (it should run whether you start Outshell on Linux, macOS or whatever on different CPU architectures).
Thanks :)
I wrote a previous blog post that discussed WASM in the FAQ: https://probablymarcus.com/blocks/2026/05/10/like-a-web-view...
Re: A native graphical shell for SSH
#65This appears to me like a solution in search of a problem, like many others before it...the quote below seems relevant to this effort. "Those who do not understand Unix are condemned to reinvent it, poorly." ~Henry Spencer
that seems a little harsh. I think there is a real usability gap which this takes a crack at.
Some ideas like using viewing a linux dir over _ssh_ using native UI components.. seem cool.
I do agree, some of these do seem like they have already been solved in other ways (like an sshfs mount).
Re: A native graphical shell for SSH
#66This appears to me like a solution in search of a problem, like many others before it...the quote below seems relevant to this effort. "Those who do not understand Unix are condemned to reinvent it, poorly." ~Henry Spencer
> "Those who do not understand Unix
Funny enough, that right there is the actual fundamental problem here.
I am reminded of a post or blog long ago that talked about programmable thermostats and how awful they are for most people to use despite how powerfully in the weeds one can get with them. Basically summarizing the issue as something like “People do not want to learn your arcane system, they just want the benefit it’s advertising”. A good UI knows how to minimize that gap.
Re: A native graphical shell for SSH
#67Author apparently has never heard about Cockpit. Everything they mention as "missing", or "novel" has been part of Cockpit for over a decade, from socket-based web server connection, backend-frontend separation for server apps and the whole idea of a server console with shell access itself. To answer them: "Isn’t it weird that this doesn’t already exist?" - No, it's not, because it has existed for ages.
I never heard of cockpit either
what is it?
Re: A native graphical shell for SSH
#68Author apparently has never heard about Cockpit. Everything they mention as "missing", or "novel" has been part of Cockpit for over a decade, from socket-based web server connection, backend-frontend separation for server apps and the whole idea of a server console with shell access itself. To answer them: "Isn’t it weird that this doesn’t already exist?" - No, it's not, because it has existed for ages.
I never heard of cockpit either what is it?
Re: A native graphical shell for SSH
#69Author apparently has never heard about Cockpit. Everything they mention as "missing", or "novel" has been part of Cockpit for over a decade, from socket-based web server connection, backend-frontend separation for server apps and the whole idea of a server console with shell access itself. To answer them: "Isn’t it weird that this doesn’t already exist?" - No, it's not, because it has existed for ages.
If I'm not mistaken cockpit is web UI and doesn't run native code, important differences.
Re: A native graphical shell for SSH
#70This appears to me like a solution in search of a problem, like many others before it...the quote below seems relevant to this effort. "Those who do not understand Unix are condemned to reinvent it, poorly." ~Henry Spencer
This resembles Plan9 more than UNIX. I wouldn't put UNIX up on a pedestal.