Live data from Hacker News

A native graphical shell for SSH

probablymarcus.com

201–210 of 239 posts

Re: A native graphical shell for SSH

#201

It is pretty annoying to see all of the dismissive comments on this idea, in that it seems that the majority of HN audience are still stuck on the TUI-superiority mindset and they do not care about GUIs at all. Two arguments: - TUIs are not inherently superior to GUIs - SSH, as a transport layer, should support not just forwarding a pty (as a TUI display layer), but a GUI display layer as well In fact, these two argu…

You can use Wayland over ssh just like X forwarding, it's called waypipe, so that future is not dead.

Re: A native graphical shell for SSH

#202
post #85
post #69

Earlier quoted context omitted.

If I'm not mistaken cockpit is web UI and doesn't run native code, important differences.

Thanks for pointing this out. I'm not hating on Cockpit, but Outer Loop (with Outer Shell) has solved a lot more of the stack. Cockpit accepts the constraints of living in existing browsers, so it requires exposing a port to the internet or using some SSH port forwarding tool. Whereas I built a dedicated browser to push capabilities so that users can get a "Just point me to a server" flow. This thread has been useful…

Your project is really cool.

And, when a project announcement upsets this many people, it's a sign you're on the right path, or at least an interesting one.

; - )

Re: A native graphical shell for SSH

#203
post #85
post #69

Earlier quoted context omitted.

If I'm not mistaken cockpit is web UI and doesn't run native code, important differences.

Thanks for pointing this out. I'm not hating on Cockpit, but Outer Loop (with Outer Shell) has solved a lot more of the stack. Cockpit accepts the constraints of living in existing browsers, so it requires exposing a port to the internet or using some SSH port forwarding tool. Whereas I built a dedicated browser to push capabilities so that users can get a "Just point me to a server" flow. This thread has been useful…

Alan Kay once strongly critiqued web browsers. He argued for a much simpler architecture.

Your experiment somehow reminds me of the better approach that he was hinting at. I.e. I think he would appreciate your experiment as well as the neuroscience in your background.

https://x.com/i/status/1957798084181901333

Re: A native graphical shell for SSH

#204
I think this is broadly similar to a thing I built as a Proof of Concept a while ( eek youtube video is 11 years old, time does fly) ago. It had a server that only listened on localhost and required a reverse proxy to make it available via https. Numerous one line commands could do that job.

https://www.youtube.com/watch?v=7namj7iy16Y&t=60s

Going to a native, but still browser-ish, client might simplify it somewhat as a ssh rather than https program, electron didn't exist when I started on this thing though.

If you go to the simple tick demo around 7 minutes in https://youtu.be/7namj7iy16Y?t=433 It shows a minimal node app running and connecting to the socket indicated by process.env.WEBSESSION to open a window on the client and sends it the webpage to handle it's own output.

I have been recently revisiting some of the ideas here using web technologies that have been created since (using promises, web-components for the window). At the moment I'm doing the whole thing client side, which actually makes it a completely different beast. I think both browser hosted backend, or real machine hosted backend have merit, but somewhat incompatible. I'm still pondering how to reconcile this.

The entirely browser side means you can host a command line environment on neocities https://lerc.neocities.org/ (has a bug where you need to reload the page once to get it working, but then it's good) It is also very much just proof-of-concept.

If you try the client thing out on neocities. Some command suggestions that reveal some of the subtleties.

    foo
    bar
    ls -al /bin
    view /res/image/slice8.webp
    cat terminal.html |hd

Re: A native graphical shell for SSH

#205

It is pretty annoying to see all of the dismissive comments on this idea, in that it seems that the majority of HN audience are still stuck on the TUI-superiority mindset and they do not care about GUIs at all. Two arguments: - TUIs are not inherently superior to GUIs - SSH, as a transport layer, should support not just forwarding a pty (as a TUI display layer), but a GUI display layer as well In fact, these two argu…

ssh -X works fine depending on the toolkit you use (i.e. not Gtk, because of its rendering pipeline) and the distance/latency you travel. For distance/latency, at some point (i.e. at sufficient latency) you're going to need to think about you present this to users (this is true independent of the medium, there are hard physical limits that cannot be waved away), and so for any tool that promises remote graphical acce…

wonder if anyone tried X over infiniband, latency would be so great

Re: A native graphical shell for SSH

#206

Earlier quoted context omitted.

Ever hired someone who, when you ask them to send you an ssh key for access to something, sends you their private key? Yeah, that's happened more than once.

Who's sending ssh keys around anymore? Just get theirs off gitHub.com/username.keys and shove it in their user account. http://gitHub.com/fragmede.keys , for example. Stick that in authorized_keys to let me into your server.

this touches two pieces of my knowledge:

    - microsoft is evil, I cannot delete my github account, will never use anything by this company
    - if the attacker knows your *public* key they can enumerate the list of the servers you have access to https://github.com/benjojo/ssh-key-confirmer

Re: A native graphical shell for SSH

#208

Earlier quoted context omitted.

When I went to college (early 2010s) professors were still encouraging students to use SVN, so I probably have a fair number of peers who didn't learn git until they got out into the real world

Was the encouragement to use SVN to the detriment of git, or was it to the detriment of renaming the file multiple times, from final to final (1).zip to final-no-really-this-is-it.zip?

It was more that IT considered the college-hosted git instance "experimental" still, in multiple project courses we were required to use college hosted version control as part of the class, but those who wanted to use git were on their own to figure it out.

Re: A native graphical shell for SSH

#209

Earlier quoted context omitted.

This resembles Plan9 more than UNIX. I wouldn't put UNIX up on a pedestal.

Plan9 is funny because it's what UNIX might look like if the people working on UNIX understood UNIX, i.e. everything is a file and simple primitives are composed into complex systems.

i mean they did understand unix, both in that they created it, and created plan9 to be closer to their original vision.

but unix got widely adopted and you go with what sells not blue-sky woulda-coulda

Re: A native graphical shell for SSH

#210

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

> "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 benefi…

as someone with a fancy IoT thermostat... yeah.

I want to set the temp. Maybe set a schedule and a timer. Once I have to start navigating multiple, deep menues with a thermostat I stop giving a shit.

I miss old VCRs that had 8 buttons and only those 8 functions

Post reply on HN