This 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
A native graphical shell for SSH
51–60 of 239 posts
Re: A native graphical shell for SSH
#52It'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).
Re: A native graphical shell for SSH
#53So a bit like X-forwarding used to do? Cool.
Re: A native graphical shell for SSH
#54Do 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.
Re: A native graphical shell for SSH
#55I like the idea of separating the frontend and backend of a graphical app. But I feel like this is hardly a novel idea, maybe I'm missing something. I take it you don't know about "X11Forwarding yes" or "html5 web app" For browsers, capabilities like connecting to Unix sockets have been dismissed as extremely niche That is a security concern, that's why it isn't implemented. At least raw unix socks. You can have WebS…
[deleted]
Re: A native graphical shell for SSH
#56i'm trying to understand how outer shell works here. on the website you give the following as your motivation: > Apps like Jupyter and Tensorboard are not typically visible to standard web browsers if they’re running on remote servers, because it would be terribly unsafe to let the whole internet touch this app. Instead, they run on a local port on the server, which your computer can’t access directly. > Classically,…
Btw, if you find yourself sending a lot of ports over ssh, you can also consider the option of having ssh start a socks5 proxy
ssh -D 4711 -q -C -N user@host
sets localhost:4711 up as a socks5 proxy you can tell your browser to use
...
A wireguard VPN is better of course; among other things because ssh is multiplexing over a single TCP connection and will encounter head of line blocking (where one dropped packet blocks all forwarded traffic until resent)
Re: A native graphical shell for SSH
#57Earlier quoted context omitted.
I guess it saves you the hassle of dealing with reverse proxies and TLS certs if your use case is "userbase is 1 person and it is me, and i only access services from a desktop os"
Ever since I started using Caddy, doing that has been soooo easy. Download the binary, make a Caddyfile myservice.example.com { basic_auth { admin some_password_hash_here } reverse_proxy :3000 } And then just "./caddy start"
Caddy can also proxy to unix sockets !
Re: A native graphical shell for SSH
#58Author 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.
Re: A native graphical shell for SSH
#59Cool, I hate it.
Re: A native graphical shell for SSH
#60That's interesting idea. If we put into CLI with some ANSI escape code, that may become something real. Imagine a normal terminal app just render part of the UI in web and communicating in UNIX socket. While doing the fancy UI, everything is still controllable with keyboard, and optionally with mouse. The UI will fallback to text UI for older terminal
If your UI is not fully controllable with a keyboard, the same forces that made that happen will eventually make a mouse mandatory for this hypothetical tech stack too.
The terminal has no Platonic quality of being keyboard only. It is an accident of history and the limitations it has had. Remove the limitations and remove the accident of history and you will just end up drawn into the strange attractor of GUIs, warts and all.
There could be a brief honeymoon where the tech stack looks like some of you are imagining in your heads, but it would only last as long as it wasn't used by very many people. Google "gemini protocol" for a similar situation. That protocol has basically a cap on how popular it could possibly get before it just turned into HTTP B as the rest of the world forcibly upgraded it regardless of what the core project thinks. They exist in the shadow of HTTP, as the terminal exists in the shadow of GUIs. This is not a bad thing. It is what lets them be what they are. The shadows of GUIs or HTTP is large and there is plenty of space to be. Trying to give the terminal more GUI capabilities is like trying to give Gemini more web capabilities; you'll just end up in the same place, only with less refinement.