Live data from Hacker News

A native graphical shell for SSH

probablymarcus.com

21–30 of 239 posts

Re: A native graphical shell for SSH

#22
post #7

Earlier quoted context omitted.

No. A shell is any user interface. Windows shell is explorer.exe and it used to be possible to change that via a config line in a system INI file. SSH protocol also isn’t just for CLI work. It supports file transport (eg SFTP), TCP/IP forwarding and even SOCKS HTTP proxying. You also used to be able to run GUI applications over SSH via X11.

You have a very loose definition of a shell that conflicts with about 40 years of history.

The earliest versions of MacOS, all the way up through 9, had a ROM call at 0xA9F4 which was labeled `_exitToShell`. In the days before pre-emptive multitasking, this instruction's job was to force the current application to close and return the user to the MacOS desktop (the Finder). The "shell" in this context being the desktop user interface.

Just FYI.

Re: A native graphical shell for SSH

#23
post #2

Interesting, kind of like a more fancy web shell. Haven't really ever seen the need for those, mostly because terminals work better than browsers.

Sometimes the browser is the only "computing platform" you have available (e.g. on some mobile devices, hotel kiosks).

Re: A native graphical shell for SSH

#24
I 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 WebSockets and other ports only limited to http.

Re: A native graphical shell for SSH

#26
post #18

That'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

So, uh... X11? VNC? RDP?

No no not something on top of the UI stack. They also need framebuffer support so they are big headache to setup on headless server.

What I mean is that we can bring some web tech to terminal natively. We don't even need a separated shell. Security and bi-directional communication is built by default because of UNIX socket. But we still need to think how to handle stuff like cookie, local storage, external CSS / JS, ...

Re: A native graphical shell for SSH

#27

i'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,…

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"

Re: A native graphical shell for SSH

#29
Just had a quick look but I like the look so far. I’ve been thinking along similar lines for ages but never quite got around to making something. I very much support any effort to make remoting less dependent on the archaic character grid.

Re: A native graphical shell for SSH

#30
post #28

Edit: withdrawing this objection, had no idea that right-clicking allowed the speed to be adjusted.

Sure, I just added YouTube mirror link to the post: https://youtu.be/e40PLLuZ5KI (The one on the website is the standard browser video player, not custom.)

Thanks (and to pelzatessa as well), TIL about the right-click menu on these. That'll come in handy.
Post reply on HN