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…
A native graphical shell for SSH
201–210 of 239 posts
Re: A native graphical shell for SSH
#202Earlier 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…
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
#203Earlier 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 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.
Re: A native graphical shell for SSH
#204https://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 |hdRe: A native graphical shell for SSH
#205It 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…
Re: A native graphical shell for SSH
#206Earlier 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.
- 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-confirmerRe: A native graphical shell for SSH
#207Re: A native graphical shell for SSH
#208Earlier 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?
Re: A native graphical shell for SSH
#209Earlier 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.
but unix got widely adopted and you go with what sells not blue-sky woulda-coulda
Re: A native graphical shell for SSH
#210This 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…
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