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 -- I think Cockpit will also work great in Outer Loop. And it will be easy to add it as an app in Outer Shell.
> 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.
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.
> without having to do any sudo commands or expose anything new to the network.
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.
> it requires exposing a port to the internet or using some SSH port forwarding tool
I think what they meant is that the SSH server can be behind your webserver and not have to have its own public IP exposed directly... but of course there are an abundance of proxy-related solutions already.
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.
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.
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 first-time setup or MDM, and on both situations setting up SSH to begin with has the same level of friction they're trying to remove.
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.
Do you mean the local session would be locked while you work unlocked from remote? That should be doable with a separate session using a dummy HDMI plug, but your original comment read to me as being able to remote in and lock the session, which is 100% possible with Sunshine
Yes: the RDP experience is even if I just walk away, when I log in from somewhere else the local session is locked and inputs disabled.
Then if I walk back to that console and log in, I can go back to using it directly.
Near as I can tell no one's solved this for Sunshine.
Edit: I will say though there must be good reasons, it's never been clear to me why this is so hard particularly when you have Wayland just compositing to one big buffer in VRAM. Surely we just want to hand the local buffer back to GDM and let the remote stream have whatever we rendered?
This thread has been useful -- I think Cockpit will also work great in Outer Loop. And it will be easy to add it as an app in Outer Shell.