Earlier quoted context omitted.
Not really no. I’ve been using shells and authoring new ones for around 40 years across a variety of platforms. The term has always been pretty loosely defined because as technology evolved the term “shell” was borrowed. So like I said, a shell can refer to a graphical core just as much as a text-based one. You can get web shells too. The original intent was that a shell is a thin wrapper on top of the OS to expose t…
Appeal to authority.
A native graphical shell for SSH
101–110 of 239 posts
Re: A native graphical shell for SSH
#102i'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 think there are different clusters of people who use servers, SSH, etc. I'm closer to the cluster that uses them for deep learning experiments, GPU kernel optimization, robot development (a robot is just a server that moves!)... use cases where you are explicitly using a remote computer. For this cluster of people, I think this tool feels more intuitive than the flow you suggest. But maybe I'm projecting! And, to m…
Re: A native graphical shell for SSH
#103Earlier quoted context omitted.
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 Acti…
FYI I made the same ActiveX connection here in the closing of the FAQ in the previous blog post about this native platform: https://probablymarcus.com/blocks/2026/05/10/like-a-web-view... I'm particularly proud of that paragraph.
Re: A native graphical shell for SSH
#104Earlier quoted context omitted.
I think there are different clusters of people who use servers, SSH, etc. I'm closer to the cluster that uses them for deep learning experiments, GPU kernel optimization, robot development (a robot is just a server that moves!)... use cases where you are explicitly using a remote computer. For this cluster of people, I think this tool feels more intuitive than the flow you suggest. But maybe I'm projecting! And, to m…
I still don't get it. Isn't this what X11 forwarding is for?
Re: A native graphical shell for SSH
#105Earlier quoted context omitted.
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
#106One 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
#107This 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
I hired a programmer and after giving him his Linux laptop let him set up a few things. A couple hours later he asked me where he could get PuTTY for it, and I recognized a huge gap in my interview coverage.
Re: A native graphical shell for SSH
#108This 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
I hired a programmer and after giving him his Linux laptop let him set up a few things. A couple hours later he asked me where he could get PuTTY for it, and I recognized a huge gap in my interview coverage.
Re: A native graphical shell for SSH
#109This 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
No. It’s just that now more people are using Linux the more the ux decisions that were made 40 years ago will be questioned. Almost all dev facing machines have ssh server installed and accessible. Why ssh terminal has to look like character-only trash from 1960s? Why a TUI is the best thing we pipe through ssh? Why I cannot watch a 4k movie in the terminal or browse the web using pinch to zoom ?
`ssh -XC` (look up SSH X forwarding). You can also easily tunnel remote desktop over ssh.
> Why I cannot watch a 4k movie in the terminal or browse the web using pinch to zoom ?
Kitty, sixel, and iterm2
Re: A native graphical shell for SSH
#110Earlier quoted context omitted.
> 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 Acti…
If you can SSH to a machine, you can use Outer Loop and Outer Shell, without having to do any sudo commands or expose anything new to the network. The browser + SSH client combined into a single app leads to nice user experiences like this. The final section of the post was saying that it's strange such a thing doesn't exist already. FYI I made the same ActiveX connection here in the closing of the FAQ in the previou…
Again I'm not understanding the distinction. I don't need to run sudo commands to install a web server, and depending on your definition of "exposing something new" to the network then either I don't have to do that either or your solution also does that.
Something is getting downloaded and run on the remote machine, correct? Why is it problematic for that something to be a web server (with SSH-forwarding I guess) instead of this custom thing?
And why install anything on the server at all if it'll just serve a binary that downloads and runs on your local computer anyway? For example, if I type `sftp://username@server.domain/file/path` into my file manager's address bar, I get the nice file browsing experience you demonstrate without installing anything on my computer or the server.
EDIT: OK, after reading through your earlier posts, I think the value proposition really is just that you've implemented a slightly better UX for proxying remote web servers via ssh, and that the "run native code" thing is an independent idea you are also pursuing. So the answer to the question "isn't this just proxying an http server over ssh" is basically yes.
I think I incorrectly read this as attempting to propose a radically new idea and not as an incremental improvement to the status quo.