[guhcampos]

Author apparently has never heard about Cockpit.

Everything they mention as "missing", or "novel" has been part of Cockpit for over a decade, from socket-based web server connection, backend-frontend separation for server apps and the whole idea of a server console with shell access itself.

To answer them: "Isn’t it weird that this doesn’t already exist?" - No, it's not, because it has existed for ages.

[gurjeet]

> Be kind. Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes.

Sincerely, HN Guidelines Police :-)

https://news.ycombinator.com/newsguidelines.html

[guhcampos]

I get it, but if the author of the article uses a biased and loaded language, I think it's fair game to do the same in the comments.

[gurjeet]

I don't believe in that kind of response. Anything that one can say in rage or anger can be communicated in a calm and measured response.

[youarenaive343]

...which perfectly describes OP.

Only problem is, Hacker News is full of thin-skinned, perpetually offended whiners who have never seen a comment they weren't somehow triggered by.

[zamadatix]

I don't think I've met many pairs of people I could ask "on a scale of 1 to 10, how biased/loaded do you think ${example} is" and get told the same exact number by both for the majority of the examples given.

Now apply that to the n people reading a given post or comment! If those commenters try to communicate on what they think is "fair game" for the given conversation, then two comments deep in and you might already be at a 7 when the author thought they were at a 3. In more extreme cases, two people could misunderstand each other through text and simply go from a 1 to a 7 in a single comment, spending the rest of the time shooting back loaded replies at each other instead of thinking about the topic together.

It's a very human reaction we all tend towards, even when we set out our intents to do the "always reply with..." mindset instead of a tit-for-tat one. That's why I always start with the ideal approach - I can count on myself to help foul it up :D.

[CrimsonCape]

This article felt like a classic example of "I just discovered this cool technology that seems to have massive potential! While massively blind and naive to the implications of what I think!" As others point out, the OP will learn in 5 years why people do what they do and not what OP thinks should be.

So I find myself being more sympathetic and SMH than antagonistic..

[jng]

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

[mrcslws]

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.

[wasmperson]

> 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.

[mrcslws]

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 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.

[wasmperson]

> 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://[e-mail]/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.

[ranger_danger]

> 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.

[makiniq0z]

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.

[dharmatech]

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

[dharmatech]

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.

; - )

[guhcampos]

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 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.

[XorNot]

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.

[rrvsh]

Yeah, RDP is great. Sunshine has basically solved this problem for me on Linux, even with {way,hypr}land (haven't tried on macos yet)

[XorNot]

Had a look and the "locked local session" problem is still not solved. The gui would be unlocked and visible on the host the whole time.

[rrvsh]

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

[NooneAtAll3]

I never heard of cockpit either

what is it?

[skydhash]

https://cockpit-project.org/