Live data from Hacker News

A native graphical shell for SSH

probablymarcus.com

91–100 of 239 posts

Re: A native graphical shell for SSH

#91

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…

I mean that's true but the number of UIs which simply don't add access to necessary features in the name of "simplicity" is enormous.

The poster child of this is the Microsoft Office ribbon.

Re: A native graphical shell for SSH

#93
post #69

Earlier quoted context omitted.

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

It's a very, very thin web layer on top of native code: https://cockpit-project.org/guide/latest/features.html To the author's defense: Cockpit is Linux only, and they seem to intend on making this also available on Windows and Mac. Still, I don't see the appeal they seem to do, especially since it relies so much on SSH. The biggest use case I can think for something like this in the real world is something like firs…

Windows has quite a lot of remote admin tools that work pretty transparently over the network though.

The issue is that they're historically never turned on or heavily restricted.

Where the user is involved though RDP is a world class remote desktop never exceeded by Linux anywhere.

If someone wants to impress me, point Claude at Wayland and get it so I can seamlessly open remote RDP from somewhere else, lock the local user session and resume it on the remote desktop, then walk back to the original terminal and continue working in that same user session. This worked perfectly over 20 years ago.

Re: A native graphical shell for SSH

#94

One of the more interesting pieces of Microsoft software is the Windows Admin Center where it's a web app to configure a Windows Server. Ideally, it was made for core installs where there's no GUI but it's there as a viable web management panel. The tool from OP and WAC are pretty similar in terms of functionality and usecase. Why would you want this? Well, imagine your team needing to be able to do server functions…

At the risk of being considered a snob I don’t want someone who can’t deal with SSH or RDP configuring servers within my company. If you can’t work out how to SSH into the server you sure as hell aren’t going to work out how to safely expose network services on it.

Re: A native graphical shell for SSH

#95

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.

yea, as sibling said. p9 was not possible on pdp11. what was possible there was .. v7 and 2bsd. see https://github.com/felipenlunkes/run-ancient-unix

p9 was done when "current state of unix" was already fixed in form of aix, sysv and bsds, it suffered the same fate as say beos.

Re: A native graphical shell for SSH

#96
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…

Cockpit has a "remote" host connection feature solving this exact pain-point - "Just point me to a server": You install the Cockpit web service on one host (along with its backend and extensions), and on other hosts you may have - install only the backend of the stack (4-7 packages available via deb backports & other dist repos). The web front host is then able to access any other machine via ssh (if keys and policies permit that) and display info or manage that host. All ports aside from the web front and ssh between your hosts remain as is. It is a decentralized design.

Re: A native graphical shell for SSH

#97
post #34
post #27

Earlier 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"

I just use https://tuns.sh which has a handy bash script to make the ssh tunnel simple

Re: A native graphical shell for SSH

#98
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…

> it requires exposing a port to the internet or using some SSH port forwarding tool

This sentence is bizarre to me. Your SSH-based solution also requires exposing a port to the internet and installing a special tool (on both server and client!). What's so special about SSH that using HTTPS is a problem but using SSH isn't?

The industry also tried the whole "use the web browser to run native binaries" thing with ActiveX (and the unity web player I guess). The idea was thrown out along with flash and java applets for what I presume were security and portability reasons.

Re: A native graphical shell for SSH

#100
Love it!

I also did some experiments some time ago. The thing this is missing for me is the ability to also run arbitrary commands other that just using a few premade apps. In fact I think this stuff becomes really interesting when you put a real "shell" on top of this.

And I don't mean a classical posix shell, something that can be used to leverage the full power of the custom ui and frontend. Also a must have is "nestable connections".

The experiment I was doing was with a web interface and a statically compiled Go backend (for easy deployment via ssh). Maybe some day I will finish it xD

Post reply on HN