Hacker News: mrcslws

New comment by mrcslws in "A native graphical shell for SSH"

mrcslws — Tue, 30 Jun 2026 03:20:07 +0000

Ha, I’ve thought the same thing.

New comment by mrcslws in "A native graphical shell for SSH"

mrcslws — Mon, 29 Jun 2026 23:18:54 +0000

It's too slow. I mention this in the video at 1:20 - 1:50.

New comment by mrcslws in "A native graphical shell for SSH"

mrcslws — Mon, 29 Jun 2026 23:11:05 +0000

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.

New comment by mrcslws in "A native graphical shell for SSH"

mrcslws — Mon, 29 Jun 2026 21:40:10 +0000

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.

New comment by mrcslws in "A native graphical shell for SSH"

mrcslws — Mon, 29 Jun 2026 19:48:22 +0000

Thanks :)

I wrote a previous blog post that discussed WASM in the FAQ: https://probablymarcus.com/blocks/2026/05/10/like-a-web-view...

New comment by mrcslws in "A native graphical shell for SSH"

mrcslws — Mon, 29 Jun 2026 19:38:42 +0000

I think it's okay as long as:

  - sockets are blocked by default, until they are added to an allow-list explicitly on the server side
  - True sudo awareness ensures root sockets aren't reachable without the sudo password. (This capability is important, because otherwise you create an incentive for people to run root backends with user-accessible sockets.)

More here: https://outerloop.sh/security/

New comment by mrcslws in "A native graphical shell for SSH"

mrcslws — Mon, 29 Jun 2026 18:12:11 +0000

Also a blog post about it, with its own video: https://probablymarcus.com/blocks/2026/05/10/like-a-web-view...

It's a fun heretical idea, moving away from a "cross-platform" web to a "multi-platform" web. It's a cross-platform protocol that hands off to platform-specific frontend code. I think it's a natural direction for the web, in a world where LLMs can translate to other platforms.

New comment by mrcslws in "A native graphical shell for SSH"

mrcslws — Mon, 29 Jun 2026 18:07:30 +0000

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 me, this just feels like one of the fundamental things that could exist; it's like a graphical operating system, but remote-first.

New comment by mrcslws in "A native graphical shell for SSH"

mrcslws — Mon, 29 Jun 2026 17:56:06 +0000

In all cases, the code is pre-compiled. A user never waits for anything to compile. When Outer Loop installs Outer Shell, it downloads pre-compiled binaries to the server. For Linux these are compiled against a manylinux ABI. Ditto for when Outer Shell installs one of the bundled apps. When a backend serves a native "web" app over HTTP it sends already-compiled ARM (or x86) code to the client.

Dependencies are less of a concern for the frontend binaries. For backends, I use a dependency-light approach, static-linking anything that's needed. Of course, people are welcome to do backends however they want, and just tell Outer Shell about the systemd/launchd units via the API. I used this no-dependency approach to keep everything lightweight and to keep install steps trivial, but admittedly it pushes me in certain directions (for example, using custom binary formats rather than sqlite).

New comment by mrcslws in "A native graphical shell for SSH"

mrcslws — Mon, 29 Jun 2026 17:30:18 +0000

Quick response regarding security:

On various Mozilla forums that I saw, the discussion was basically: 1. We can't just allow the browser to connect to any socket, since many either explicitly don't want browsers connecting to them, or are oblivious to browsers. 2. ...so we need to also add some sort of allow list 3. ...this is getting too complicated for such a niche feature.

So I think the nicheness was the high-order bit here.

(FYI, Outer Loop does add an allow-list: https://outerloop.sh/unix-domain-sockets/)

New comment by mrcslws in "A native graphical shell for SSH"

mrcslws — Mon, 29 Jun 2026 17:23:10 +0000

Sure, I just added YouTube mirror link to the post: https://youtu.be/e40PLLuZ5KI

(The one on the website is the standard browser video player, not custom.)

New comment by mrcslws in "A native graphical shell for SSH"

mrcslws — Mon, 29 Jun 2026 16:56:48 +0000

I wondered if this would be controversial. It all depends where you grew up.

> Cairo, like Chicago, had a new shell (Microsoft’s favorite word for the user interface for launching programs and managing files) and a new file system

https://hardcoresoftware.learningbyshipping.com/p/020-innova...

When I worked at Microsoft 2010 - 2014, the word "shell" was still used in this way. I decided to say "graphical shell", to make it clearer.