It is pretty annoying to see all of the dismissive comments on this idea, in that it seems that the majority of HN audience are still stuck on the TUI-superiority mindset and they do not care about GUIs at all.
Two arguments:
- TUIs are not inherently superior to GUIs
- SSH, as a transport layer, should support not just forwarding a pty (as a TUI display layer), but a GUI display layer as well
In fact, these two arguments were already realized by UNIX 30 years ago, and we already have one solution: the X protocol and ssh -X.
Unfortunately, X did not win out. We did not get the promised future where one can ssh -X into a remote machine, run gnome-control-center, and a settings window pops up and I can configure my remote computer. (If you believe that this works, try it out yourself. It is an abysmal experience.)
However the above needs still needed to be satisfied by so much people, and apps that needed it started to be developed as web servers, stuff like jupyter notebooks. It turns out that the web’s document format coupled with a styling solution and a client-side scripting language, with all of its warts and drawbacks, became a viable solution as a display layer for interactive apps. In fact, since it started from remote documents, network transparency is built-in.
It would be dumb to not realize that the HTML/CSS/JS stack did win a dominant position for desktop apps, with all of the Electron apps, and utilize the web as a display layer for the above. I see the project in a similar vein, i.e. utilizing HTML/CSS/JS to provide a display layer for remote apps via SSH.
Also note that Electron apps has the same split with X, where the display server and the client are separated: it's called the "renderer process" and the "main process", and the two processes talk via IPC (where the display server would be the renderer process running embedded Chromium, the display client would be the Electron main process, and the stuff that the client sends to the server would be the contents of the renderer JS bundle). I think, theoretically, it would be possible to run the main process separated from the renderer process on a different machine, with an appropriate IPC transport. I think this would be not far from the above idea?
ssh -X works fine depending on the toolkit you use (i.e. not Gtk, because of its rendering pipeline) and the distance/latency you travel. For distance/latency, at some point (i.e. at sufficient latency) you're going to need to think about you present this to users (this is true independent of the medium, there are hard physical limits that cannot be waved away), and so for any tool that promises remote graphical access will need to design with distance/latency in mind (e.g. vim works great over latencies as you basically queue up instructions).
> theoretically, it would be possible to run the main process separated from the renderer process on a different machine, with an appropriate IPC transport.
Is this really possible? If Electron apps could do this, and we could run them on a Linux SBC like RPI with the renderer on the user's laptop, that would be interesting ...
Isn't this is basically every webpage with a backend component, just displaced one more layer? I suspect the main reason this doesn't make sense is that it would take an order of magnitude more bandwidth as opposed to just sending data like we do right now. Data has repetitive patterns which means it's often well compressibile as well.
> Unfortunately, X did not win out. We did not get the promised future where one can ssh -X into a remote machine, run gnome-control-center, and a settings window pops up and I can configure my remote computer.
Personally I'm glad that's the case. Configuring servers via gui is an abomination, and I hope it stays in the windows world.
I for one am glad that 'webmin' is effectively dead, and the 'Cockpit' thing that ships with a default Fedora install is much less offensive in terms of how it mangles system configuration files you might want to otherwise edit by hand.
people still want to believe that Electron apps won because "web developers are cheaper than real native developers"
they still dont understand Electron is vastly superior technology, and the fact that it might be cheaper is a side-bonus, not the main reason for its usage
BTW, what even is the "native GUI" of Windows that you are supposed to use if "you care about your users"? It seems not even Microsoft knows the answer to this question.
In the sense that typesetting and text is the rabbit hole that is 90% of UI effort. Native UI frameworks don't bother fixing the real hard problems, they focus on "widgets" instead.
(Not that the web stack is a good solution to this, but at least they're making an effort and they understand the difficult issues.)
> Native UI frameworks don't bother fixing the real hard problems
I'm genuinely curious what do you mean by that.
My beef with web stack was exactly this - typesetting engine from 80s has been never designed for modern UI/UX needs, and it cannot adequately provide those. Whenever I interact with web apps, I experience so many glitches, weird interaction issues (especially if there is a zoom/selection/scrool involved), that I don't even pay attention to them anymore - it's a norm. It's a norm on web to 'just refresh page' (which is equivalent to 'restart native app') - we do it all the time, because absolute majority of web apps is just crap that requires extremely advanced team of web developers to make it a 'baseline' native-like experience level of quality.
I mean if we wanted a good UI/UX framework we'd have to start from typesetting, not add it later as an afterthought to our button and text area widgets.
> if we wanted a good UI/UX framework we'd have to start from typesetting
I think UI framework begins with a model of how composition, layout, rendering, input/focus and state works. Typesetting subsystem should be built on top of that.
And that's exactly the problem with this kind of post-rationalization of HTML legacy - it's a wonderful mechanism for what it was created for, but decades of attempts to add and repurpose all those missing foundational blocks for app development leads to the twenty layers of hacks on top of hacks.
One is that it solves all problems once instead of various times in various levels of quality on various types of systems. Windows, GTK, Qt, FLTK, [100 others].. not to mention most "native UI framework" delegate to the underlying OS so they don't "solve" anything.
Electron is not a novel approach or "technology" of achieving cross-platform UI. It's literally a Chromium browser plus a Node.js runtime, using web-stack to impersonate desktop application. None of these tools have been designed to solve UI pain points.
Closest thing to what you're describing is Flutter, which is a UI framework designed from ground up for modern UI app needs, without delegating much to OS level.
electron is better for the developer only. It is worse for everyone else, especially the users.
it is an insult when an application is delivered to me as an Electron application. "your time is less important than ours, ha ha."
sure, the developers might save some development time, but EVERY SINGLE USER loses time over a native application. Now multiply that loss by the number of users that you have. That magnification or amplification is called "an ecological disaster in terms of time wasted and electricity consumed."
> they still don't understand Electron is vastly superior technology
For the record, I'm one who loves the idea of Mac-assed Mac apps, I believe that the macOS ecosystem would have been much better if all macOS apps were written in AppKit instead of keep being rewritten into Electron. (See: 1Password, Raycast)
I hate Electron as much as the next person, and I hated Electron before hating Electron became a trendy thing to do. I loathe that Electron apps ship an entire Chromium instance for each app, and that it doesn't deduplicate. I am annoyed as hell that out of my 24GB of RAM that my MBA has, Slack, Linear, and Notion decided to each have a "Helper (Renderer)" process that uses 700MB of RAM each.
I do NOT think that Electron or the HTML/CSS/JS stack has an inherent advantage over other display technologies. I can list of at least 15 reasons on the spot on why it's inappropriate to use the web stack for desktop apps.
Yet, despite all of its flaws, people decided to commonly use it (with good reasons, the big one being cross-platform support!) as a display technology for desktop apps. And turns out that it works out okay-ish, they iterated on it and it improved a lot over the last 10 years, and at this point it's a pretty nice solution for the problem. And we already have a bunch of apps that run on it. Sometimes not the best tech wins, and that's okay.
My point was that despite all of the flaws, we developers as a whole decided to use web stuff for desktop apps, and it has properties that make it a good fit for some use cases that we have not solved yet, and we can use that to our advantage.
And if a lot of applications started to be written in the web stack, an OS could integrate an evergreen web browser as a first-class app runtime, and at least we might get less of the Chromium duplication that we currently have with Electron… at least I can dream. (Seems like Windows is going down this route.)
> I do NOT think that Electron or the HTML/CSS/JS stack has an inherent advantage over other display technologies
If you want the real answer, it was all driven by responsive design and CSS. Qt tried to bring that to native apps and failed miserably. Modern devices need apps that work the same across any screen/window size, any aspect ratio, any resolution, support accessibility features, etc. The list of things you get out of the box with a webview is massive and only growing. Any attempt to clone this while ignoring W3C specs and browser quirks will fail.
I can't think of a more heroic and crazy uphill battle than managing to decouple CSS from HTML and JS, and get app devs to like it, and get users to like it.
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.
> Puttygen software is not created, nor supported by Puttygen.com. The program has been tested and is believed to be safe. [...] The use of Puttygen through Puttygen.com is done at your own discretion and risk
PuTTY is (or was, in the years before WSL) the go-to SSH client for Windows. If you're a Windows user getting onboarded at a job / uni class which uses Linux machines, installing it is the first thing you'd be told. The laptop in question would obviously have a terminal emulator and SSH client pre-installed, but a Windows user wouldn't think to look for them, and they might not even know that SSH exists outside of PuTTY or that it's a separate concept to the terminal.
Sure, I'm well-aware, and am also aware that someone familiar with a GUI-based way of doing something on one OS may seek the same, or similar, GUI on another (new) OS. It's a familiar anchor in a sea of unknown, a natural thing to do for most users.
I still don't follow the evil grin. Is the apt package some kind of malware or trojan?
It's nothing evil, it's just Putty for Linux, and they say why you might want it. Mostly for people coming from Windows, but supposedly it can also deal with raw sockets that OpenSSH can't.
Ever hired someone who, when you ask them to send you an ssh key for access to something, sends you their private key? Yeah, that's happened more than once.
Not everyone works in a field where the developers or engineers have public github accounts or publish their profile of things like ssh keys for the world to read.
- microsoft is evil, I cannot delete my github account, will never use anything by this company
- if the attacker knows your *public* key they can enumerate the list of the servers you have access to https://github.com/benjojo/ssh-key-confirmer
That's more ageism than anything else. I mean surely real "programmers" know the new hotness "ghsfgusdfu", right? How could you live without?
I know companies running on SVN and they're fine. In fact, it's a better fit for them. Yes, Git is not always superior.
I'll give you a helpful concept to navigate these issues: "Cargo culting refers to the practice of imitating the superficial aspects of a process or practice without understanding the underlying logic or reasons behind it. This phenomenon is often seen in software development, where developers may adopt certain coding styles or methodologies without grasping their true purpose."
Git is over 20 years old at this point. If somebody is in their 60s now, they were in their 40s when it came out. This is not about age. They must have slept on it for a long time.
Nobody expects an engineer to be a git expert, but if a senior software engineer has heard of git only yesterday or don't have a vague concept of how DVCSs like hg or git work (DAG of commits), then something has gone very wrong.
Maybe there are use cases where SVN is superior (I can't come up with any but they may exist), and maybe engineers in that industry really are so specialized that they never get around to working on anything else!
But maybe it's because nobody else is willing to hire them.
If you are not in an environment where it is being actively used it is not something you'll pick up. Not every programmer is on HN or being cool with blogs etc. I agree not knowing about source control at all is a .. different matter. Also, 20 years is less impressive once you subtract the time it wasn't popular. Even if it was 20 years, it is still not impressive. Perhaps if you are 15-30, but to older folks it's like a drop in the bucket.
Many people are not familiar with "git" and don't have to be. Picking up "git" is a one afternoon type of thing but the parent did not mention timelines. It was just about "knowing" git and I pushed back on that.
There are so, so many tools you guys on here find indispensable that don't actually get used by vast swaths of people in the field. I sometimes wonder where all you guys work.
If you're actively looking for a job, you should have some familiarity with the common dev stack when you're looking. Today you should be comfortable working on a Mac, know Bash / Zsh, a little bit of Vim for SSHing, git, docker, react, postgres, etc.
If you don't, spend a few weeks before you start your search. You're almost definitely going to need them. Unless you're in a niche where the common stack is different.
This isn't me gatekeeping or something, it's just common sense. When 80% of the jobs are Python + Javascript / Typescript, running in Docker, using Postgres, using React on the frontend, FastAPI on the backend, and git plus github for deploying and reviewing, you're going to stumble without cursory knowledge. You don't need to be an expert in it all…
> This isn't me gatekeeping or something, it's just common sense. When 80% of the jobs are Python + Javascript / Typescript, running in Docker, using Postgres, using React on the frontend, FastAPI on the backend, and git plus github for deploying and reviewing,
Then I don't apply. I'm not interested in working with garbage tech.
Interesting! I'd love to hear what type of work you do where you can get away without any of those because frankly I think most of those are pretty garbage too.
Postgres is decent for a free ($$$) database, although it's lack of clustered indexes and in-place updates (its MVCC approach) sucks for many use cases. I find it a sensible default but not the best at any one use case.
Python, frankly, sucks nowawadays. Maybe it had its time, but there are so many better lingos now. It's got type hints that are ignored, really bad patterns ("dependency injection" that's really just the singleton pattern, FastAPI encourages you to open a db connection and a transaction at the front of every request and commit at the end while you're making other requests, writing to disk, etc), and it's slow in both user experience and runtime (no real parallelism).
But generally I have to make some trades to get a great job. I love Go, personally, and the incredible simplicity it encourages.
Seriously, if you'd be willing to share, I'd love to hear what you do!
Fair enough that I did not mention any timeline. And could’ve been general with “VCS”. And you are absolutely correct, that basics of some of these tools can be learnt in an afternoon.
In fact the industry i work in we don’t have git, but something similar to SVN (and proprietary, expensive and pathetic UI/UX)
Since, I am not in software industry, I won’t comment on whether such people might survive for more than 5 years without knowing about ‘VCS’.
However, I have slightly died inside when some Computer science students (graduate school, mind you) were using google drive with manually created timestamps as a backup strategy. The submission for this entire semester long actual project was on Github. as a final single commit uploaded a day before. (And no this wasn’t a squashed commit from a different repo.)
There might be a blurry line between people not sharpening their auxiliary tools vs never using or being slightly curious about them.
I am more of a glamour and bling on my tools person, and I don’t expect every engineer to derive the same pleasure that I derive just from tinkering with them; however, does make me wonder if there is a point when such an approach to not fully caring about simplifying your workflow (aka being lazy), might spill over into making poor engineering decision?
It's possible to always work for big tech companies and never use some popular tools like git. Not a good thing either, but it doesn't mean they're wannabe programmers, cause I've seen those too.
When I went to college (early 2010s) professors were still encouraging students to use SVN, so I probably have a fair number of peers who didn't learn git until they got out into the real world
Was the encouragement to use SVN to the detriment of git, or was it to the detriment of renaming the file multiple times, from final to final (1).zip to final-no-really-this-is-it.zip?
It was more that IT considered the college-hosted git instance "experimental" still, in multiple project courses we were required to use college hosted version control as part of the class, but those who wanted to use git were on their own to figure it out.
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 ?
A terminal UI is the best thing we pipe through SSH because it's the tool we built specifically for piping a terminal UI. Abandoning Xorg has admittedly made streaming a GUI over SSH less simple, but still not impossible, and you can forward whatever data you want (a VLC stream of a 4k movie) with tunneling.
I do agree that new Linux users who have different needs from their computers might cause some incentive to change some of these 40 year old UX decisions. We don't really have a modern, capable remote desktop solution at least on par with RDP.
Because content is orthogonal to form. Development at its core is virtually pure content. The form, the fonts, the graphics, the "pixels". It's noise with regards to the task at hand. It's not useless, because surely we have eyes and need to witness text on the screen (for now), but it is orthogonal to the main axis of resistance we are trying to overcome (for which we get paid).
People that don't understand the separation between content and form cannot separate between data and rendering, between models and views. They stuff JS in CSS and CSS in databases.
In short, they make shitty architects and are to be shunned from programming important software in general. No offense.
The problem with VNC is the same as the problem with IRC. The new user experience is trash. They're both on the level of protocols, like SMTP is, so you get variable support for user quality of life features and users bounce because those features aren't built into the protocol. For VNC, it's per window support and image compression format/acceleration. For IRC it's pre-join-history scrollback, and anything you need a moderation bot for. SMTP's problem is spam. (Doesn't matter if that's a problem with the protocol or the wider situation and should be managed at the application level, it sucks for users.
I mean, I do this all the time via sshfs. I don't think these tools or ideas are bad, they just mostly aren't new, the innovation is maybe a particular ux or a particular bundle of toys?
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 benefit it’s advertising”. A good UI knows how to minimize that gap.
I want to set the temp. Maybe set a schedule and a timer. Once I have to start navigating multiple, deep menues with a thermostat I stop giving a shit.
I miss old VCRs that had 8 buttons and only those 8 functions
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.
They had the benefit of hindsight and bigger hardware, but UNIX got too popular and now we're struggling to move past it. It would have been interesting to see what the fourth try would be like (though looking at Go I would probably not completely like it).
BeOS was marketed, there was an attempt. But it was a harder sell. Plan 9 on the other hand was was kept as a research project only and was restrictively licensed in the 90s when it was actively developed.
this kind of dismissive comments is why many apps have an awful usability. If someone thinks a web interface would be easier than a text terminal, there's at least one customer in need for a product (which either doesn't exist or they could not "googlify") - it's also why I welcome AI generating apps on the fly, "replacing" engineers who "know better" ;)
> there's at least one customer in need for a product
just because whales exist does not mean feeding them is a goal to aim for as a society. 99.9% of technology could disappear tomorrow and life would become better.
hyperbole: a lot of tech we give for granted today, started as niche products for "whales" like government agencies, so I suppose computers and Internet shouldn't exist and life would be better
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.
JavaScript and wasm should not be able to open generalized networks sockets because no one wants an asshole to be able to buy an ad on a shitty ad network and send malicious code to people’s browsers which attacks all the internal devices on the user’s network simply because the user wanted to read a movie review.
i'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, to get access to these, you had to open a new terminal and run:
is this true? isn't the normal thing just to do this ssh forwarding for prototyping, then for deployment, you set up a website like myjupyternotebook.com, and then set up auth so that others can't access it. HTTP basic auth is not too much work.
if you want SSH, not HTTP, to be what's publicly exposed, there's other options too, like putting it behind a VPN or tunnel.
all this to say, outer loop is super cool, but I don't get it. I must be missing something about why you built it, so could you help me understand?
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.
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"
Btw, if you find yourself sending a lot of ports over ssh, you can also consider the option of having ssh start a socks5 proxy
ssh -D 4711 -q -C -N user@host
sets localhost:4711 up as a socks5 proxy you can tell your browser to use
...
A wireguard VPN is better of course; among other things because ssh is multiplexing over a single TCP connection and will encounter head of line blocking (where one dropped packet blocks all forwarded traffic until resent)
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.
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.
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..
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?
Lovely writeup! I'll bookmark this for my own research.
My terminal's "clickity clackity" features [0] are local to the machine so I lose graphical-ness as soon as we remote in somewhere.
That's starting to change a bit with offline replay [1] where the native GUI and TUI work in tandem to unlock some rewind. But there's quite a road ahead and I love seeing others experiment properly. (Terminals are massively underserved.)
Do not do this. There are many, many excellent long-standing security and "web control plane isolation" reasons browsers are not permitted generic socket permissions.
The closest mechanical analog that comes to mind is why 3-wheeled ATVs are a bad idea.
- 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.)
This is amazing! Most definitely headed in the right direction.
The separation layer between front and back must be cut at the smallest possible 'slice'.
Lots of people here snarking would understand if they 'felt' the latency and additional overhead. Not enough thought has been put in carfully slicing the data for individual use cases.
I'd go even further, in his demo of 'generating load by moving the config often' -- I think that 'top' app should have 'jit-ed' more of the rendering on the client such that the only information traversing pi<>client is compresed delta's of the ps hose.
Zellij is nice, it's as close to a window manager in a terminal as I ever got. Right now I'm trying to get used to it in Termius, with a Logitech Pebble for some light remote devving.
That's interesting idea. If we put into CLI with some ANSI escape code, that may become something real. Imagine a normal terminal app just render part of the UI in web and communicating in UNIX socket. While doing the fancy UI, everything is still controllable with keyboard, and optionally with mouse. The UI will fallback to text UI for older terminal
If your UI is not fully controllable with a keyboard, the same forces that made that happen will eventually make a mouse mandatory for this hypothetical tech stack too.
The terminal has no Platonic quality of being keyboard only. It is an accident of history and the limitations it has had. Remove the limitations and remove the accident of history and you will just end up drawn into the strange attractor of GUIs, warts and all.
There could be a brief honeymoon where the tech stack looks like some of you are imagining in your heads, but it would only last as long as it wasn't used by very many people. Google "gemini protocol" for a similar situation. That protocol has basically a cap on how popular it could possibly get before it just turned into HTTP B as the rest of the world forcibly upgraded it regardless of what the core project thinks. They exist in the shadow of HTTP, as the terminal exists in the shadow of GUIs. This is not a bad thing. It is what lets them be what they are. The shadows of GUIs or HTTP is large and there is plenty of space to be. Trying to give the terminal more GUI capabilities is like trying to give Gemini more web capabilities; you'll just end up in the same place, only with less refinement.
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, ...
Web technologies are significantly larger and more complex than framebuffers, and they don't even let you start arbitrary programs like Chrome under them.
I think the approach here where interfacing with a device is considered from first principles is one that is rarely taken on, and this is a thought provoking implementation. Kudos.
Ok few resources people interested in the topic might like on the "Web can do so much more front" :
- WebDAV to serve files, very quick to setup using e.g. CopyParty. It's important this way your Web applications can then pass content to each other.
- WebSSH to get a terminal via the Web and thus potentially backend maintenance, e.g. start/stop CopyParty (also useful to bypass corporate firewalls and connect to your machine)
- WebTop container based on Selkies to get a full containerized environment, including a graphical interface. You can run pretty much any of your native application in there, even video games. Can be local or remote at 60fps.
- WebContainers to run containers directly from the browser
- QEMU-wasm to run a different architecture on yours, again from the browser
Terminal people forget how hostile SSH is to anyone who didn't learn it in college.
If this lowers the floor for small teams managing a VPS without hiring a platform person, that's a win. I'm just curious how it handles keys and jump hosts.
I am surprised at the lack of technical criticism. In the past, even an ignorance of history could be useful, since one would have to solve again the problems in detail, and so be forced to acquire a deep understanding of the issues. Now one can sell this paper clock with chaotic internal workings that thwarts human fabrication or maintenance.
This reminds me of an idea that I build a PoC of many years ago (maybe 2013 if I recall) that I always felt was the nugget of a useful idea. You would SSH into a server and processes on the other end would emit data which was then displayed in a webapp that was served from a localhost port, with a local backend that consumed the data. So for example a short-lived web-based remote 'top'. I did it as part of a company-internal hackathon and thought it was really cool, but nobody else was impressed with it. It was a very half-baked idea, and this looks like a fully-baked version of it. I'll check it out.
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
That's similar to the direction I went with my PC. It's a server that sits in a datacenter. It is wireguard protected and has SSH access for general stuff, copyparty for file access, webtop in a container for graphical tasks like audio editing, software like Navidrome for music and Immich for photos.
I could just call it a "home" lab server. But I actually use it as a general purpose computer, not just a server.
I think this is broadly similar to a thing I built as a Proof of Concept a while
( eek youtube video is 11 years old, time does fly) ago. It had a server that only listened on localhost and required a reverse proxy to make it available via https. Numerous one line commands could do that job.
Going to a native, but still browser-ish, client might simplify it somewhat as a ssh rather than https program, electron didn't exist when I started on this thing though.
If you go to the simple tick demo around 7 minutes in
https://youtu.be/7namj7iy16Y?t=433
It shows a minimal node app running and connecting to the socket indicated by process.env.WEBSESSION to open a window on the client and sends it the webpage to handle it's own output.
I have been recently revisiting some of the ideas here using web technologies that have been created since (using promises, web-components for the window). At the moment I'm doing the whole thing client side, which actually makes it a completely different beast. I think both browser hosted backend, or real machine hosted backend have merit, but somewhat incompatible. I'm still pondering how to reconcile this.
The entirely browser side means you can host a command line environment on neocities https://lerc.neocities.org/ (has a bug where you need to reload the page once to get it working, but then it's good) It is also very much just proof-of-concept.
If you try the client thing out on neocities. Some command suggestions that reveal some of the subtleties.
foo
bar
ls -al /bin
view /res/image/slice8.webp
cat terminal.html |hd
> These HTTP servers will typically be private, inaccessible to other devices on the network. Instead, you’ll use them over SSH, or locally.
So, if I read it correctly, SSH is there to provide connectivity and security, and the core app idea is based on HTTP and web?
On the HTTP side, there are already some "app managers" such as Dokku and Coolify, and you can already `ssh ...-L...` map their ports to your local. But I guess the browser you build will do that (or something similar) automatically to make it more convenient for the user, so that's nice.
Not sure about the Outerframe idea tho. Right now you can already build things with webasm and have it send commands to draw stuff on to a canvas to create very rich custom UI elements, that is in addition to the standard HTML UI elements provided by the browser. Why another standard?
In general I would like to see a web browser escape sequence for console applications. Just send a command to the terminal to connect a web browser to your stdin/out and present any UI you want over html. The terminal can then open a regular socket listening on localhost and act as a CGI server. For security the terminal should pick a random IP in the localhost range and a random URL. Technically that is security by obscurity, but guessing a cryptographically secure URL should be hard enough for attackers. The reasons to do it as an escape sequence and not just have the application open a socket and start the browser are: To enable remote GUI; To avoid the complexity of each application implementing networking; To enable better desktop integration, since the terminal itself is part of the Desktop Environment, so it can start a DE-specific browser, preferably in single-application mode. Also, it should be possible to automatically put the application in the background so you basically just run GUI applications like normal.
There was also a standalone Java based SSH client that worked from browsers. (Of course now with WebSockets and modern JavaScript capabilities, no need to have the a “real” SSH client on the user’s actual system…)
Unfortunately, not sure there is enough drive for mainstream applications to be developed in for this proposed “web native” interface. Practically speaking, there would probably have to be a way to run them as native GUI apps without the browser or for a text terminal.
Unfortunately, the three environments have relatively little in common aside from the trivial parts… Operating efficiently in all quickly becomes nontrivial…
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 but you have less technical team members to do it for you, which is very often the case in big places, most people are familiar with the web browser and having a website to do these sorts of actions makes it easier to have things done in one place without a lot of tools like Remote Desktop, SSH, WinRM, etc. configured.
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.
Within your company, sure. But there's some engineers (think medical) who know standards like DICOM and PACS imaging but aren't familiar at all with OS internals or systems administration.
If you’re not a sysadmin, there’s no reason to wrestle around with OS internals and system tools. We have moved away from mainframes and now everyone is root on one’s computer, but honestly anything in /etc, /sbin and /usr/sbin should be irrelevant for daily workflows.
As someone managing various servers, both at home and at work, I see how this can be really useful. I see it not in the production space yet but rather in the experimenting, using a Linux machine as a second compute device!
So regarding your last point, I'm convinced. I think it is useful!
The one fact that is bugging me is that now it requires a client specific app, with GUI, on my PC and I wonder if using ssh port forwarding could reduce the surface. I mean I wonder if either having a rich client that executes commands via ssh or a rich server (including Web Server) with ssh port wouldn't suffice, so that I can avoid installing stuff on the server AND on my computer.
Just had a quick look but I like the look so far. I’ve been thinking along similar lines for ages but never quite got around to making something. I very much support any effort to make remoting less dependent on the archaic character grid.
I'm actually way more interested in option 2 - the VNC-like experience.
TUI apps are convenient over SSH because they're right there in your terminal. But they suck because they're restricted to shitty monospaced character grids. Why can't we have something more like VNC over SSH? Like, `top` and `micro` but with good graphics?
I did try doing something like that with the Kitty graphics protocol and you can get kind of close..ish, but it's really restricted by having to send everything as PNGs.
Anyway upvote for not being blinkered and thinking terminals are just for CLI stuff and must be forever.
I’m good with just tailscale and self-hosted web-apps. Seems the main selling point is either native UX or reduced barriers to entry security-wise. I like barriers to entry.
I can’t make up my mind if I love it or hate it. On one hand this is like SSHapi on the other there’s no structure, no contract… i had similar doubts with Cockpit.
I thought this looks interesting, but was a little confused with what appears to be MacOS-only support at https://outerloop.sh/? I'm running Ubuntu 24.04, I kind of assumed from context that it'd be something I could spin up in a few minutes just to give it a go?
Also worth noting, my decision to give it a go relied mostly on the fact that I couldn't quite work out what the product is. Having "Outer Shell" and "Outer Loop" described as distinct-but-connected entities is a little confusing, IMO, which do I need to install, on what, and in what order?
I have also been having trouble grasping the difference between Outer Loop and Outer Shell. I thought maybe one was the desktop browser app for macOS and the other was something running locally on the Pi to create the socket. However, after bouncing between the links for the two, I don't think that assumption was correct.
Being able to initiate a shell app from a regular remote ssh CLI prompt (like "ApacheConfig myhost.com" or "Editor ~/myrepo") might improve integration with people's existing CLI workflows.
It does need an agent that starts with every X or Wayland session and waits for requests from remote SSH sessions to start an app.
I don't really know what outerframe frame is. I tried to understand from the video and the blog but I'm still not sure what it is. Is it like a web browser but instead of DOM, HTML and JS you have Swift and SwiftUI running in a sandbox?
If so how would that work on non Apple devices? Also how much will that sandbox protect you?
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.
It's a cool video and I like the idea in general. The author mentions that the code runs in a sandbox. I'm surprised that WASM hasn't come up. You want the code to be platform agnostic anyway (it should run whether you start Outshell on Linux, macOS or whatever on different CPU architectures).
Since the half of the app that is running on my local X or Wayland can only display a GUI and doesn't need QtNetwork, QtWebkit, Gtk Webview etc, what lightweight UI toolkit other than html+js do you recommend ?
Feedback: Home pages of each of Outer Loop, Outer Frame and Outer Shell contain basic intro of each instead of a link redirecting to them. By the time I click the link and on the new Outer X I have already what Outer X I came from and what it meant.
I am not sure I'd use this over exposing websites with wireguard as those will automatically work across platforms. But it looks like you could create some really cool experiences with it, and I'm happy people are exploring this space.
wow i really dig this concept, worked on something similar recently, a ssh browser as transport layer on top of ladybird with id profiles based on ssh pubkeys https://github.com/ricardo-reboot/sshttpd. also i think the web should head in this direction and give browsers an alternate transport layer other than http for browsing.
I'm confused -- does this compile it live when the server ships code?
How do we resolve dependencies, toolset etc..
Is the idea to just pick an old enough platform toolchain you expect to be present?
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).
I wrote an early version of the Cylance AV desktop client. The UI side was a web app that talked to its windows service backend using HTTP over windows pipes. This was surprisingly easy to do using WCF.
again, this is something that Plan 9 made very easy and that other operating systems ignored.
I'm honestly getting tired of typing that. Bell Labs thought ahead when they made Plan 9. It's definitely not perfect, but it's got a lot of nice features that we are still reinventing 30 years later.
The earliest versions of MacOS, all the way up through 9, had a ROM call at 0xA9F4 which was labeled `_exitToShell`. In the days before pre-emptive multitasking, this instruction's job was to force the current application to close and return the user to the MacOS desktop (the Finder). The "shell" in this context being the desktop user interface.
I don't have a dog in this fight, and anyway dogfighting is bad, but the intro to the Wikipedia article[0] reads:
> An operating system shell is a computer program that provides relatively broad and direct access to the system on which it runs. The term shell refers to how it is a relatively thin layer around an operating system.
> Most shells are command-line interface (CLI) programs. Some graphical user interfaces (GUI) also include shells.
The last line I think supports the notion that the term "shell" at least implies a CLI, but I can understand both positions.
Both usages (graphical and CLI) of the term are correct. Saying "shell" doesn't by itself imply one or the other, even if the technology that is more commonly discussed when we say "shell" is those CLI things in UNIX-like OSs.
A bit like how cars are typically small vehicles with internal combustion engines, but that doesn't mean EVs are not a classification of cars too.
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
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 the hosts capabilities. But that hasn’t been an apt description for most of those 40 years.
command line shell vs graphical shell. My first experience with a graphical shell was dosshell[1]. For a while we called the Windows 3.1 interface "the shell". I guess the terminology has changed since that time.
It is pretty annoying to see all of the dismissive comments on this idea, in that it seems that the majority of HN audience are still stuck on the TUI-superiority mindset and they do not care about GUIs at all.
Two arguments:
- TUIs are not inherently superior to GUIs
- SSH, as a transport layer, should support not just forwarding a pty (as a TUI display layer), but a GUI display layer as well
In fact, these two arguments were already realized by UNIX 30 years ago, and we already have one solution: the X protocol and ssh -X.
Unfortunately, X did not win out. We did not get the promised future where one can ssh -X into a remote machine, run gnome-control-center, and a settings window pops up and I can configure my remote computer. (If you believe that this works, try it out yourself. It is an abysmal experience.)
However the above needs still needed to be satisfied by so much people, and apps that needed it started to be developed as web servers, stuff like jupyter notebooks. It turns out that the web’s document format coupled with a styling solution and a client-side scripting language, with all of its warts and drawbacks, became a viable solution as a display layer for interactive apps. In fact, since it started from remote documents, network transparency is built-in.
It would be dumb to not realize that the HTML/CSS/JS stack did win a dominant position for desktop apps, with all of the Electron apps, and utilize the web as a display layer for the above. I see the project in a similar vein, i.e. utilizing HTML/CSS/JS to provide a display layer for remote apps via SSH.
Also note that Electron apps has the same split with X, where the display server and the client are separated: it's called the "renderer process" and the "main process", and the two processes talk via IPC (where the display server would be the renderer process running embedded Chromium, the display client would be the Electron main process, and the stuff that the client sends to the server would be the contents of the renderer JS bundle). I think, theoretically, it would be possible to run the main process separated from the renderer process on a different machine, with an appropriate IPC transport. I think this would be not far from the above idea?
There's also stuff like Thinlinc, NoMachine, X2Go and a bunch of others, all of which use SSH as the primary backend. This is a pretty common idea.
ssh -X works fine depending on the toolkit you use (i.e. not Gtk, because of its rendering pipeline) and the distance/latency you travel. For distance/latency, at some point (i.e. at sufficient latency) you're going to need to think about you present this to users (this is true independent of the medium, there are hard physical limits that cannot be waved away), and so for any tool that promises remote graphical access will need to design with distance/latency in mind (e.g. vim works great over latencies as you basically queue up instructions).
especially with features that xpra brings. But everyone's attention is elsewhere.
wonder if anyone tried X over infiniband, latency would be so great
Up to Gtk2 is still good
> (If you believe that this works, try it out yourself. It is an abysmal experience.)
That seems like a "patches welcome" for someone properly motivated.
It's gnome. You will have a developer explain to you how your usecase is invalid.
> theoretically, it would be possible to run the main process separated from the renderer process on a different machine, with an appropriate IPC transport.
Is this really possible? If Electron apps could do this, and we could run them on a Linux SBC like RPI with the renderer on the user's laptop, that would be interesting ...
Isn't this is basically every webpage with a backend component, just displaced one more layer? I suspect the main reason this doesn't make sense is that it would take an order of magnitude more bandwidth as opposed to just sending data like we do right now. Data has repetitive patterns which means it's often well compressibile as well.
You can use Wayland over ssh just like X forwarding, it's called waypipe, so that future is not dead.
Pretty annoying that the first comment is always someone complaining about the other commenters and dismissing their opinions
> Unfortunately, X did not win out. We did not get the promised future where one can ssh -X into a remote machine, run gnome-control-center, and a settings window pops up and I can configure my remote computer.
Personally I'm glad that's the case. Configuring servers via gui is an abomination, and I hope it stays in the windows world.
I for one am glad that 'webmin' is effectively dead, and the 'Cockpit' thing that ships with a default Fedora install is much less offensive in terms of how it mangles system configuration files you might want to otherwise edit by hand.
people still want to believe that Electron apps won because "web developers are cheaper than real native developers"
they still dont understand Electron is vastly superior technology, and the fact that it might be cheaper is a side-bonus, not the main reason for its usage
BTW, what even is the "native GUI" of Windows that you are supposed to use if "you care about your users"? It seems not even Microsoft knows the answer to this question.
> still dont understand Electron is vastly superior technology
in what sense crossplatoform desktop-wrapper around typesetting engine is a 'vastly superior technology' to native UI frameworks?
In the sense that typesetting and text is the rabbit hole that is 90% of UI effort. Native UI frameworks don't bother fixing the real hard problems, they focus on "widgets" instead.
(Not that the web stack is a good solution to this, but at least they're making an effort and they understand the difficult issues.)
> Native UI frameworks don't bother fixing the real hard problems
I'm genuinely curious what do you mean by that.
My beef with web stack was exactly this - typesetting engine from 80s has been never designed for modern UI/UX needs, and it cannot adequately provide those. Whenever I interact with web apps, I experience so many glitches, weird interaction issues (especially if there is a zoom/selection/scrool involved), that I don't even pay attention to them anymore - it's a norm. It's a norm on web to 'just refresh page' (which is equivalent to 'restart native app') - we do it all the time, because absolute majority of web apps is just crap that requires extremely advanced team of web developers to make it a 'baseline' native-like experience level of quality.
I mean if we wanted a good UI/UX framework we'd have to start from typesetting, not add it later as an afterthought to our button and text area widgets.
> if we wanted a good UI/UX framework we'd have to start from typesetting
I think UI framework begins with a model of how composition, layout, rendering, input/focus and state works. Typesetting subsystem should be built on top of that.
And that's exactly the problem with this kind of post-rationalization of HTML legacy - it's a wonderful mechanism for what it was created for, but decades of attempts to add and repurpose all those missing foundational blocks for app development leads to the twenty layers of hacks on top of hacks.
Well now I want an interactive LaTex UI framework in the style of NeWS
One is that it solves all problems once instead of various times in various levels of quality on various types of systems. Windows, GTK, Qt, FLTK, [100 others].. not to mention most "native UI framework" delegate to the underlying OS so they don't "solve" anything.
Electron is not a novel approach or "technology" of achieving cross-platform UI. It's literally a Chromium browser plus a Node.js runtime, using web-stack to impersonate desktop application. None of these tools have been designed to solve UI pain points.
Closest thing to what you're describing is Flutter, which is a UI framework designed from ground up for modern UI app needs, without delegating much to OS level.
electron is better for the developer only. It is worse for everyone else, especially the users.
it is an insult when an application is delivered to me as an Electron application. "your time is less important than ours, ha ha."
sure, the developers might save some development time, but EVERY SINGLE USER loses time over a native application. Now multiply that loss by the number of users that you have. That magnification or amplification is called "an ecological disaster in terms of time wasted and electricity consumed."
> they still don't understand Electron is vastly superior technology
For the record, I'm one who loves the idea of Mac-assed Mac apps, I believe that the macOS ecosystem would have been much better if all macOS apps were written in AppKit instead of keep being rewritten into Electron. (See: 1Password, Raycast)
I hate Electron as much as the next person, and I hated Electron before hating Electron became a trendy thing to do. I loathe that Electron apps ship an entire Chromium instance for each app, and that it doesn't deduplicate. I am annoyed as hell that out of my 24GB of RAM that my MBA has, Slack, Linear, and Notion decided to each have a "Helper (Renderer)" process that uses 700MB of RAM each.
I do NOT think that Electron or the HTML/CSS/JS stack has an inherent advantage over other display technologies. I can list of at least 15 reasons on the spot on why it's inappropriate to use the web stack for desktop apps.
Yet, despite all of its flaws, people decided to commonly use it (with good reasons, the big one being cross-platform support!) as a display technology for desktop apps. And turns out that it works out okay-ish, they iterated on it and it improved a lot over the last 10 years, and at this point it's a pretty nice solution for the problem. And we already have a bunch of apps that run on it. Sometimes not the best tech wins, and that's okay.
My point was that despite all of the flaws, we developers as a whole decided to use web stuff for desktop apps, and it has properties that make it a good fit for some use cases that we have not solved yet, and we can use that to our advantage.
And if a lot of applications started to be written in the web stack, an OS could integrate an evergreen web browser as a first-class app runtime, and at least we might get less of the Chromium duplication that we currently have with Electron… at least I can dream. (Seems like Windows is going down this route.)
> I do NOT think that Electron or the HTML/CSS/JS stack has an inherent advantage over other display technologies
If you want the real answer, it was all driven by responsive design and CSS. Qt tried to bring that to native apps and failed miserably. Modern devices need apps that work the same across any screen/window size, any aspect ratio, any resolution, support accessibility features, etc. The list of things you get out of the box with a webview is massive and only growing. Any attempt to clone this while ignoring W3C specs and browser quirks will fail.
I can't think of a more heroic and crazy uphill battle than managing to decouple CSS from HTML and JS, and get app devs to like it, and get users to like it.
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
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.
Indeed, a new hire should be able to use Google to find https://puttygen.com/download-putty#Download_PuTTY_on_Linux_... in short order
evil grin
https://www.chiark.greenend.org.uk/~sgtatham/putty/
puttygen.com looks super fishy, the disclaimer:
> Puttygen software is not created, nor supported by Puttygen.com. The program has been tested and is believed to be safe. [...] The use of Puttygen through Puttygen.com is done at your own discretion and risk
Edit: or is that the evil grin?
multiple issues right
apt install putty seems... useful? Don't get it.
PuTTY is (or was, in the years before WSL) the go-to SSH client for Windows. If you're a Windows user getting onboarded at a job / uni class which uses Linux machines, installing it is the first thing you'd be told. The laptop in question would obviously have a terminal emulator and SSH client pre-installed, but a Windows user wouldn't think to look for them, and they might not even know that SSH exists outside of PuTTY or that it's a separate concept to the terminal.
Sure, I'm well-aware, and am also aware that someone familiar with a GUI-based way of doing something on one OS may seek the same, or similar, GUI on another (new) OS. It's a familiar anchor in a sea of unknown, a natural thing to do for most users.
I still don't follow the evil grin. Is the apt package some kind of malware or trojan?
It's nothing evil, it's just Putty for Linux, and they say why you might want it. Mostly for people coming from Windows, but supposedly it can also deal with raw sockets that OpenSSH can't.
or just ask an llm
Ever hired someone who, when you ask them to send you an ssh key for access to something, sends you their private key? Yeah, that's happened more than once.
Who's sending ssh keys around anymore? Just get theirs off gitHub.com/username.keys and shove it in their user account.
http://gitHub.com/fragmede.keys, for example. Stick that in authorized_keys to let me into your server.
Not everyone works in a field where the developers or engineers have public github accounts or publish their profile of things like ssh keys for the world to read.
this touches two pieces of my knowledge:
Gotta auto-reject anyone listing Windows experience on resume
wow, what a way to prejudice against people fluent in multiple paradigms
works for me. are you hiring? :-)
I dislike this story and it’s because I can believe it.
Any experience with ‘programmers’ not knowing git?
That's more ageism than anything else. I mean surely real "programmers" know the new hotness "ghsfgusdfu", right? How could you live without?
I know companies running on SVN and they're fine. In fact, it's a better fit for them. Yes, Git is not always superior.
I'll give you a helpful concept to navigate these issues: "Cargo culting refers to the practice of imitating the superficial aspects of a process or practice without understanding the underlying logic or reasons behind it. This phenomenon is often seen in software development, where developers may adopt certain coding styles or methodologies without grasping their true purpose."
Git is over 20 years old at this point. If somebody is in their 60s now, they were in their 40s when it came out. This is not about age. They must have slept on it for a long time.
Nobody expects an engineer to be a git expert, but if a senior software engineer has heard of git only yesterday or don't have a vague concept of how DVCSs like hg or git work (DAG of commits), then something has gone very wrong.
Maybe there are use cases where SVN is superior (I can't come up with any but they may exist), and maybe engineers in that industry really are so specialized that they never get around to working on anything else!
But maybe it's because nobody else is willing to hire them.
If you are not in an environment where it is being actively used it is not something you'll pick up. Not every programmer is on HN or being cool with blogs etc. I agree not knowing about source control at all is a .. different matter. Also, 20 years is less impressive once you subtract the time it wasn't popular. Even if it was 20 years, it is still not impressive. Perhaps if you are 15-30, but to older folks it's like a drop in the bucket.
Many people are not familiar with "git" and don't have to be. Picking up "git" is a one afternoon type of thing but the parent did not mention timelines. It was just about "knowing" git and I pushed back on that.
There are so, so many tools you guys on here find indispensable that don't actually get used by vast swaths of people in the field. I sometimes wonder where all you guys work.
If you're actively looking for a job, you should have some familiarity with the common dev stack when you're looking. Today you should be comfortable working on a Mac, know Bash / Zsh, a little bit of Vim for SSHing, git, docker, react, postgres, etc.
If you don't, spend a few weeks before you start your search. You're almost definitely going to need them. Unless you're in a niche where the common stack is different.
This isn't me gatekeeping or something, it's just common sense. When 80% of the jobs are Python + Javascript / Typescript, running in Docker, using Postgres, using React on the frontend, FastAPI on the backend, and git plus github for deploying and reviewing, you're going to stumble without cursory knowledge. You don't need to be an expert in it all…
> This isn't me gatekeeping or something, it's just common sense. When 80% of the jobs are Python + Javascript / Typescript, running in Docker, using Postgres, using React on the frontend, FastAPI on the backend, and git plus github for deploying and reviewing,
Then I don't apply. I'm not interested in working with garbage tech.
Interesting! I'd love to hear what type of work you do where you can get away without any of those because frankly I think most of those are pretty garbage too.
Postgres is decent for a free ($$$) database, although it's lack of clustered indexes and in-place updates (its MVCC approach) sucks for many use cases. I find it a sensible default but not the best at any one use case.
Python, frankly, sucks nowawadays. Maybe it had its time, but there are so many better lingos now. It's got type hints that are ignored, really bad patterns ("dependency injection" that's really just the singleton pattern, FastAPI encourages you to open a db connection and a transaction at the front of every request and commit at the end while you're making other requests, writing to disk, etc), and it's slow in both user experience and runtime (no real parallelism).
But generally I have to make some trades to get a great job. I love Go, personally, and the incredible simplicity it encourages.
Seriously, if you'd be willing to share, I'd love to hear what you do!
Fair enough that I did not mention any timeline. And could’ve been general with “VCS”. And you are absolutely correct, that basics of some of these tools can be learnt in an afternoon.
In fact the industry i work in we don’t have git, but something similar to SVN (and proprietary, expensive and pathetic UI/UX)
Since, I am not in software industry, I won’t comment on whether such people might survive for more than 5 years without knowing about ‘VCS’.
However, I have slightly died inside when some Computer science students (graduate school, mind you) were using google drive with manually created timestamps as a backup strategy. The submission for this entire semester long actual project was on Github. as a final single commit uploaded a day before. (And no this wasn’t a squashed commit from a different repo.)
There might be a blurry line between people not sharpening their auxiliary tools vs never using or being slightly curious about them.
I am more of a glamour and bling on my tools person, and I don’t expect every engineer to derive the same pleasure that I derive just from tinkering with them; however, does make me wonder if there is a point when such an approach to not fully caring about simplifying your workflow (aka being lazy), might spill over into making poor engineering decision?
It's possible to always work for big tech companies and never use some popular tools like git. Not a good thing either, but it doesn't mean they're wannabe programmers, cause I've seen those too.
Honestly, I suspect you'd find a lot of self-taught people have random gaps in their knowledge that someone with a mentor/degree won't.
I had a linguist attend a CS class and he didn't know how to copy and paste.
When I went to college (early 2010s) professors were still encouraging students to use SVN, so I probably have a fair number of peers who didn't learn git until they got out into the real world
Was the encouragement to use SVN to the detriment of git, or was it to the detriment of renaming the file multiple times, from final to final (1).zip to final-no-really-this-is-it.zip?
It was more that IT considered the college-hosted git instance "experimental" still, in multiple project courses we were required to use college hosted version control as part of the class, but those who wanted to use git were on their own to figure it out.
Had experience with programmers not knowing VCS in general.
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 ?
A terminal UI is the best thing we pipe through SSH because it's the tool we built specifically for piping a terminal UI. Abandoning Xorg has admittedly made streaming a GUI over SSH less simple, but still not impossible, and you can forward whatever data you want (a VLC stream of a 4k movie) with tunneling.
I do agree that new Linux users who have different needs from their computers might cause some incentive to change some of these 40 year old UX decisions. We don't really have a modern, capable remote desktop solution at least on par with RDP.
> Why a TUI is the best thing we pipe through ssh?
`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
It's not 4k, but ssh to funky.nondeterministic.computer if you're using a modern* terminal emulator program. (aka ghostty)
>character-only trash from 1960s
You take that back!
>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?
The old magick speak of X forwarding. The newer wizards now use waypipe.
Because content is orthogonal to form. Development at its core is virtually pure content. The form, the fonts, the graphics, the "pixels". It's noise with regards to the task at hand. It's not useless, because surely we have eyes and need to witness text on the screen (for now), but it is orthogonal to the main axis of resistance we are trying to overcome (for which we get paid).
People that don't understand the separation between content and form cannot separate between data and rendering, between models and views. They stuff JS in CSS and CSS in databases.
In short, they make shitty architects and are to be shunned from programming important software in general. No offense.
because it is TEXT
you want your GUI then set up VNC
The problem with VNC is the same as the problem with IRC. The new user experience is trash. They're both on the level of protocols, like SMTP is, so you get variable support for user quality of life features and users bounce because those features aren't built into the protocol. For VNC, it's per window support and image compression format/acceleration. For IRC it's pre-join-history scrollback, and anything you need a moderation bot for. SMTP's problem is spam. (Doesn't matter if that's a problem with the protocol or the wider situation and should be managed at the application level, it sucks for users.
> Why ssh terminal has to look like character-only trash from 1960s?
We should re-implement it with Comic Sans and happy shiny buttons to click everywhere? Click here for "ls -alh" ?
No, but I wouldn't mind if keyboard worked properly.
Where keyboard no work?
that seems a little harsh. I think there is a real usability gap which this takes a crack at.
Some ideas like using viewing a linux dir over _ssh_ using native UI components.. seem cool.
I do agree, some of these do seem like they have already been solved in other ways (like an sshfs mount).
That is exactly what X was designed to do. And part of why X is considered insecure today.
I mean, I do this all the time via sshfs. I don't think these tools or ideas are bad, they just mostly aren't new, the innovation is maybe a particular ux or a particular bundle of toys?
> "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 benefit it’s advertising”. A good UI knows how to minimize that gap.
as someone with a fancy IoT thermostat... yeah.
I want to set the temp. Maybe set a schedule and a timer. Once I have to start navigating multiple, deep menues with a thermostat I stop giving a shit.
I miss old VCRs that had 8 buttons and only those 8 functions
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.
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.
They had the benefit of hindsight and bigger hardware, but UNIX got too popular and now we're struggling to move past it. It would have been interesting to see what the fourth try would be like (though looking at Go I would probably not completely like it).
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.
BeOS was marketed, there was an attempt. But it was a harder sell. Plan 9 on the other hand was was kept as a research project only and was restrictively licensed in the 90s when it was actively developed.
i mean they did understand unix, both in that they created it, and created plan9 to be closer to their original vision.
but unix got widely adopted and you go with what sells not blue-sky woulda-coulda
Yes and no. Defining network devices in a different namespace, for example, was an early break from what might be called the UNIX tradition.
this kind of dismissive comments is why many apps have an awful usability. If someone thinks a web interface would be easier than a text terminal, there's at least one customer in need for a product (which either doesn't exist or they could not "googlify") - it's also why I welcome AI generating apps on the fly, "replacing" engineers who "know better" ;)
Why learn to do anything?
compilers, IDE, syntax highlighting too, everyone should learn assembly, ed, and stick to b&w
> there's at least one customer in need for a product
just because whales exist does not mean feeding them is a goal to aim for as a society. 99.9% of technology could disappear tomorrow and life would become better.
hyperbole: a lot of tech we give for granted today, started as niche products for "whales" like government agencies, so I suppose computers and Internet shouldn't exist and life would be better
> computers and Internet shouldn't exist and life would be better
I don't think that's remotely controversial
>"Those who do not understand Unix are condemned to reinvent it, poorly." ~Henry Spencer
I need something like this for network management tools.
I think this is a `There’s no such thing as bad publicity`
UNIX/GNU/LINUX is not TUI. Period.
It's like they decided to reinvent webmin
That quote does not have anything against GUIs, does it?
Or did you mean it in another way?
I like the idea of separating the frontend and backend of a graphical app. But I feel like this is hardly a novel idea, maybe I'm missing something.
I take it you don't know about "X11Forwarding yes" or "html5 web app"
That is a security concern, that's why it isn't implemented. At least raw unix socks. You can have WebSockets and other ports only limited to http.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/)
JavaScript and wasm should not be able to open generalized networks sockets because no one wants an asshole to be able to buy an ad on a shitty ad network and send malicious code to people’s browsers which attacks all the internal devices on the user’s network simply because the user wanted to read a movie review.
i'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, to get access to these, you had to open a new terminal and run:
> ssh -L 24601:localhost:8889 mrcslws@lambda4.mycompany.com &
> ssh -L 24602:localhost:6006 mrcslws@lambda4.mycompany.com &
is this true? isn't the normal thing just to do this ssh forwarding for prototyping, then for deployment, you set up a website like myjupyternotebook.com, and then set up auth so that others can't access it. HTTP basic auth is not too much work.
if you want SSH, not HTTP, to be what's publicly exposed, there's other options too, like putting it behind a VPN or tunnel.
all this to say, outer loop is super cool, but I don't get it. I must be missing something about why you built it, so could you help me understand?
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.
I still don't get it. Isn't this what X11 forwarding is for?
It's too slow. I mention this in the video at 1:20 - 1:50.
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
And then just "./caddy start"Caddy can also proxy to unix sockets !
I just use https://tuns.sh which has a handy bash script to make the ssh tunnel simple
does this work with multiple caddy servers? ie can you bind multiple caddy servers to port 80/443?
You can have multiple configs in a single Caddyfile and reload when you make changes, and it'll just route them as you wish, e.g.
domain1.com -> service on port 1234
domain2.com -> service on port 5678
domain3.com -> serving a file directory.
And then you still access domain1.com, domain2.com, domain3.com on port 80/443
You set up multiple services behind a single caddy reverse proxy
Btw, if you find yourself sending a lot of ports over ssh, you can also consider the option of having ssh start a socks5 proxy
ssh -D 4711 -q -C -N user@host
sets localhost:4711 up as a socks5 proxy you can tell your browser to use
...
A wireguard VPN is better of course; among other things because ssh is multiplexing over a single TCP connection and will encounter head of line blocking (where one dropped packet blocks all forwarded traffic until resent)
HTTP basic auth is not secure.
basic auth is secure, if used in combination with TLS.
Unfortunately, that only takes care of one of the vulnerabilities that comes with basic auth.
As basic auth sends the header for every single request, it is also vulnerable to CSRF attacks.
My typical use case for SSH port forwarding is to rescue a network from some kind of configuration failure.
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.
> 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
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.
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.
...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.
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.
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..
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 -- 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.
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.
> 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.
https://x.com/i/status/1957798084181901333
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.
; - )
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.
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.
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)
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.
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?
I never heard of cockpit either
what is it?
https://cockpit-project.org/
Lovely writeup! I'll bookmark this for my own research.
My terminal's "clickity clackity" features [0] are local to the machine so I lose graphical-ness as soon as we remote in somewhere.
That's starting to change a bit with offline replay [1] where the native GUI and TUI work in tandem to unlock some rewind. But there's quite a road ahead and I love seeing others experiment properly. (Terminals are massively underserved.)
[0] https://terminal.click
[1] https://terminal.click/posts/2026/06/tui-stability/#:~:text=...
Do not do this. There are many, many excellent long-standing security and "web control plane isolation" reasons browsers are not permitted generic socket permissions.
The closest mechanical analog that comes to mind is why 3-wheeled ATVs are a bad idea.
I think it's okay as long as:
More here: https://outerloop.sh/security/There’s no such thing as a root socket. Stop using that phrase.
This is amazing! Most definitely headed in the right direction. The separation layer between front and back must be cut at the smallest possible 'slice'.
Lots of people here snarking would understand if they 'felt' the latency and additional overhead. Not enough thought has been put in carfully slicing the data for individual use cases.
I'd go even further, in his demo of 'generating load by moving the config often' -- I think that 'top' app should have 'jit-ed' more of the rendering on the client such that the only information traversing pi<>client is compresed delta's of the ps hose.
Not what OP means but there is Zellij [0]
Zellij is nice, it's as close to a window manager in a terminal as I ever got. Right now I'm trying to get used to it in Termius, with a Logitech Pebble for some light remote devving.
[0] https://zellij.dev/
Thanks for the hint! Didn't know about zellij, but indeed looks very interesting. Downloaded and will try it out.
That's interesting idea. If we put into CLI with some ANSI escape code, that may become something real. Imagine a normal terminal app just render part of the UI in web and communicating in UNIX socket. While doing the fancy UI, everything is still controllable with keyboard, and optionally with mouse. The UI will fallback to text UI for older terminal
If your UI is not fully controllable with a keyboard, the same forces that made that happen will eventually make a mouse mandatory for this hypothetical tech stack too.
The terminal has no Platonic quality of being keyboard only. It is an accident of history and the limitations it has had. Remove the limitations and remove the accident of history and you will just end up drawn into the strange attractor of GUIs, warts and all.
There could be a brief honeymoon where the tech stack looks like some of you are imagining in your heads, but it would only last as long as it wasn't used by very many people. Google "gemini protocol" for a similar situation. That protocol has basically a cap on how popular it could possibly get before it just turned into HTTP B as the rest of the world forcibly upgraded it regardless of what the core project thinks. They exist in the shadow of HTTP, as the terminal exists in the shadow of GUIs. This is not a bad thing. It is what lets them be what they are. The shadows of GUIs or HTTP is large and there is plenty of space to be. Trying to give the terminal more GUI capabilities is like trying to give Gemini more web capabilities; you'll just end up in the same place, only with less refinement.
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, ...
Web technologies are significantly larger and more complex than framebuffers, and they don't even let you start arbitrary programs like Chrome under them.
I think the approach here where interfacing with a device is considered from first principles is one that is rarely taken on, and this is a thought provoking implementation. Kudos.
Ok few resources people interested in the topic might like on the "Web can do so much more front" :
- WebDAV to serve files, very quick to setup using e.g. CopyParty. It's important this way your Web applications can then pass content to each other.
- WebSSH to get a terminal via the Web and thus potentially backend maintenance, e.g. start/stop CopyParty (also useful to bypass corporate firewalls and connect to your machine)
- WebTop container based on Selkies to get a full containerized environment, including a graphical interface. You can run pretty much any of your native application in there, even video games. Can be local or remote at 60fps.
- WebContainers to run containers directly from the browser
- QEMU-wasm to run a different architecture on yours, again from the browser
Terminal people forget how hostile SSH is to anyone who didn't learn it in college.
If this lowers the floor for small teams managing a VPS without hiring a platform person, that's a win. I'm just curious how it handles keys and jump hosts.
Is this really the future that people want?
https://raw.githubusercontent.com/outergroup/outershell/refs...
https://raw.githubusercontent.com/outergroup/Top/refs/heads/...
I am surprised at the lack of technical criticism. In the past, even an ignorance of history could be useful, since one would have to solve again the problems in detail, and so be forced to acquire a deep understanding of the issues. Now one can sell this paper clock with chaotic internal workings that thwarts human fabrication or maintenance.
This reminds me of an idea that I build a PoC of many years ago (maybe 2013 if I recall) that I always felt was the nugget of a useful idea. You would SSH into a server and processes on the other end would emit data which was then displayed in a webapp that was served from a localhost port, with a local backend that consumed the data. So for example a short-lived web-based remote 'top'. I did it as part of a company-internal hackathon and thought it was really cool, but nobody else was impressed with it. It was a very half-baked idea, and this looks like a fully-baked version of it. I'll check it out.
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
That's similar to the direction I went with my PC. It's a server that sits in a datacenter. It is wireguard protected and has SSH access for general stuff, copyparty for file access, webtop in a container for graphical tasks like audio editing, software like Navidrome for music and Immich for photos.
I could just call it a "home" lab server. But I actually use it as a general purpose computer, not just a server.
I think this is broadly similar to a thing I built as a Proof of Concept a while ( eek youtube video is 11 years old, time does fly) ago. It had a server that only listened on localhost and required a reverse proxy to make it available via https. Numerous one line commands could do that job.
https://www.youtube.com/watch?v=7namj7iy16Y&t=60s
Going to a native, but still browser-ish, client might simplify it somewhat as a ssh rather than https program, electron didn't exist when I started on this thing though.
If you go to the simple tick demo around 7 minutes in https://youtu.be/7namj7iy16Y?t=433 It shows a minimal node app running and connecting to the socket indicated by process.env.WEBSESSION to open a window on the client and sends it the webpage to handle it's own output.
I have been recently revisiting some of the ideas here using web technologies that have been created since (using promises, web-components for the window). At the moment I'm doing the whole thing client side, which actually makes it a completely different beast. I think both browser hosted backend, or real machine hosted backend have merit, but somewhat incompatible. I'm still pondering how to reconcile this.
The entirely browser side means you can host a command line environment on neocities https://lerc.neocities.org/ (has a bug where you need to reload the page once to get it working, but then it's good) It is also very much just proof-of-concept.
If you try the client thing out on neocities. Some command suggestions that reveal some of the subtleties.
> These HTTP servers will typically be private, inaccessible to other devices on the network. Instead, you’ll use them over SSH, or locally.
So, if I read it correctly, SSH is there to provide connectivity and security, and the core app idea is based on HTTP and web?
On the HTTP side, there are already some "app managers" such as Dokku and Coolify, and you can already `ssh ...-L...` map their ports to your local. But I guess the browser you build will do that (or something similar) automatically to make it more convenient for the user, so that's nice.
Not sure about the Outerframe idea tho. Right now you can already build things with webasm and have it send commands to draw stuff on to a canvas to create very rich custom UI elements, that is in addition to the standard HTML UI elements provided by the browser. Why another standard?
In general I would like to see a web browser escape sequence for console applications. Just send a command to the terminal to connect a web browser to your stdin/out and present any UI you want over html. The terminal can then open a regular socket listening on localhost and act as a CGI server. For security the terminal should pick a random IP in the localhost range and a random URL. Technically that is security by obscurity, but guessing a cryptographically secure URL should be hard enough for attackers. The reasons to do it as an escape sequence and not just have the application open a socket and start the browser are: To enable remote GUI; To avoid the complexity of each application implementing networking; To enable better desktop integration, since the terminal itself is part of the Desktop Environment, so it can start a DE-specific browser, preferably in single-application mode. Also, it should be possible to automatically put the application in the background so you basically just run GUI applications like normal.
Interesting, kind of like a more fancy web shell. Haven't really ever seen the need for those, mostly because terminals work better than browsers.
Sometimes the browser is the only "computing platform" you have available (e.g. on some mobile devices, hotel kiosks).
Reminds me of “WebRSH” back in the day.
There was also a standalone Java based SSH client that worked from browsers. (Of course now with WebSockets and modern JavaScript capabilities, no need to have the a “real” SSH client on the user’s actual system…)
Unfortunately, not sure there is enough drive for mainstream applications to be developed in for this proposed “web native” interface. Practically speaking, there would probably have to be a way to run them as native GUI apps without the browser or for a text terminal.
Unfortunately, the three environments have relatively little in common aside from the trivial parts… Operating efficiently in all quickly becomes nontrivial…
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 but you have less technical team members to do it for you, which is very often the case in big places, most people are familiar with the web browser and having a website to do these sorts of actions makes it easier to have things done in one place without a lot of tools like Remote Desktop, SSH, WinRM, etc. configured.
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.
Within your company, sure. But there's some engineers (think medical) who know standards like DICOM and PACS imaging but aren't familiar at all with OS internals or systems administration.
If you’re not a sysadmin, there’s no reason to wrestle around with OS internals and system tools. We have moved away from mainframes and now everyone is root on one’s computer, but honestly anything in /etc, /sbin and /usr/sbin should be irrelevant for daily workflows.
I can ssh into a server yet would still prefer a GUI for a lot of work.
Lovely video and ingenious implementation. Kudos!
As someone managing various servers, both at home and at work, I see how this can be really useful. I see it not in the production space yet but rather in the experimenting, using a Linux machine as a second compute device!
So regarding your last point, I'm convinced. I think it is useful! The one fact that is bugging me is that now it requires a client specific app, with GUI, on my PC and I wonder if using ssh port forwarding could reduce the surface. I mean I wonder if either having a rich client that executes commands via ssh or a rich server (including Web Server) with ssh port wouldn't suffice, so that I can avoid installing stuff on the server AND on my computer.
Just had a quick look but I like the look so far. I’ve been thinking along similar lines for ages but never quite got around to making something. I very much support any effort to make remoting less dependent on the archaic character grid.
I'm actually way more interested in option 2 - the VNC-like experience.
TUI apps are convenient over SSH because they're right there in your terminal. But they suck because they're restricted to shitty monospaced character grids. Why can't we have something more like VNC over SSH? Like, `top` and `micro` but with good graphics?
I did try doing something like that with the Kitty graphics protocol and you can get kind of close..ish, but it's really restricted by having to send everything as PNGs.
Anyway upvote for not being blinkered and thinking terminals are just for CLI stuff and must be forever.
I’m good with just tailscale and self-hosted web-apps. Seems the main selling point is either native UX or reduced barriers to entry security-wise. I like barriers to entry.
This is cool. Though I don't see why someone would want to do more work/design for the custom GUI rendering for a custom/renderer (your viewer app) ?
I can’t make up my mind if I love it or hate it. On one hand this is like SSHapi on the other there’s no structure, no contract… i had similar doubts with Cockpit.
I thought this looks interesting, but was a little confused with what appears to be MacOS-only support at https://outerloop.sh/? I'm running Ubuntu 24.04, I kind of assumed from context that it'd be something I could spin up in a few minutes just to give it a go?
Also worth noting, my decision to give it a go relied mostly on the fact that I couldn't quite work out what the product is. Having "Outer Shell" and "Outer Loop" described as distinct-but-connected entities is a little confusing, IMO, which do I need to install, on what, and in what order?
Cool idea anyway, no shade here.
I have also been having trouble grasping the difference between Outer Loop and Outer Shell. I thought maybe one was the desktop browser app for macOS and the other was something running locally on the Pi to create the socket. However, after bouncing between the links for the two, I don't think that assumption was correct.
> Isn’t it weird that this doesn’t already exist?
It does. MobaXterm have a bunch of it already, file manager on the side and ability to pass X11
Being able to initiate a shell app from a regular remote ssh CLI prompt (like "ApacheConfig myhost.com" or "Editor ~/myrepo") might improve integration with people's existing CLI workflows.
It does need an agent that starts with every X or Wayland session and waits for requests from remote SSH sessions to start an app.
I don't really know what outerframe frame is. I tried to understand from the video and the blog but I'm still not sure what it is. Is it like a web browser but instead of DOM, HTML and JS you have Swift and SwiftUI running in a sandbox?
If so how would that work on non Apple devices? Also how much will that sandbox protect you?
It's purportedly cross-platform. The documentation leaves a lot to be desired, but it is described more here:
https://outerframe.org/ and https://outerloop.sh/native-apps/
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.
It's a cool video and I like the idea in general. The author mentions that the code runs in a sandbox. I'm surprised that WASM hasn't come up. You want the code to be platform agnostic anyway (it should run whether you start Outshell on Linux, macOS or whatever on different CPU architectures).
Thanks :)
I wrote a previous blog post that discussed WASM in the FAQ: https://probablymarcus.com/blocks/2026/05/10/like-a-web-view...
Since the half of the app that is running on my local X or Wayland can only display a GUI and doesn't need QtNetwork, QtWebkit, Gtk Webview etc, what lightweight UI toolkit other than html+js do you recommend ?
Feedback: Home pages of each of Outer Loop, Outer Frame and Outer Shell contain basic intro of each instead of a link redirecting to them. By the time I click the link and on the new Outer X I have already what Outer X I came from and what it meant.
I am not sure I'd use this over exposing websites with wireguard as those will automatically work across platforms. But it looks like you could create some really cool experiences with it, and I'm happy people are exploring this space.
wow i really dig this concept, worked on something similar recently, a ssh browser as transport layer on top of ladybird with id profiles based on ssh pubkeys https://github.com/ricardo-reboot/sshttpd. also i think the web should head in this direction and give browsers an alternate transport layer other than http for browsing.
I'm confused -- does this compile it live when the server ships code? How do we resolve dependencies, toolset etc.. Is the idea to just pick an old enough platform toolchain you expect to be present?
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).
I wrote an early version of the Cylance AV desktop client. The UI side was a web app that talked to its windows service backend using HTTP over windows pipes. This was surprisingly easy to do using WCF.
The interface design reminded me of yunohost a bit.
again, this is something that Plan 9 made very easy and that other operating systems ignored.
I'm honestly getting tired of typing that. Bell Labs thought ahead when they made Plan 9. It's definitely not perfect, but it's got a lot of nice features that we are still reinventing 30 years later.
I like the idea, but without a cross-platform OSS browser it’s hard to consider adopting it (and I am primarily a Mac/iOS user…)
I prefer hytelnet and MUDs but I don’t count, I’m just too old.
This looks pretty cool! I can already imagine use cases for admin portals or other tools that I'd prefer to run over ssh.
Edit: withdrawing this objection, had no idea that right-clicking allowed the speed to be adjusted.
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.)
Thanks (and to pelzatessa as well), TIL about the right-click menu on these. That'll come in handy.
but its just standard <video> element, in firefox I can even right-click to change the speed to 2x. It's certainly better privacy-wise.
Looks good. I'll stick to Emacs and tramp though.
coool, its very basic idea and neatly built. TUI is allows all the customization however GUI good for quick & less complex tasks.
not sure what problem this solves. smells like setup for a security exploit. tho my most generous take is its CV-ware
So a bit like X-forwarding used to do? Cool.
this exists as https://xpipe.io/
You would have loved XUL
Heresy!
So.... webmin
This is really cool. I love it.
What'd be really funny would be for someone to use this to implement an app that's a terminal. XD
Ha, I’ve thought the same thing.
> every app is a small HTTP server
This adds unnecessary overhead for communication. using web and web-like approaches on desktop system is a terrible idea.
Cool, I hate it.
[dead]
[dead]
[dead]
[dead]
[dead]
UI/UX is very bad why would we need it over Warp / Wave Terminal
Defeats the purpose of the shell. The shell is for CLI interaction.
No. A shell is any user interface. Windows shell is explorer.exe and it used to be possible to change that via a config line in a system INI file.
SSH protocol also isn’t just for CLI work. It supports file transport (eg SFTP), TCP/IP forwarding and even SOCKS HTTP proxying.
You also used to be able to run GUI applications over SSH via X11.
You have a very loose definition of a shell that conflicts with about 40 years of history.
The earliest versions of MacOS, all the way up through 9, had a ROM call at 0xA9F4 which was labeled `_exitToShell`. In the days before pre-emptive multitasking, this instruction's job was to force the current application to close and return the user to the MacOS desktop (the Finder). The "shell" in this context being the desktop user interface.
Just FYI.
I don't have a dog in this fight, and anyway dogfighting is bad, but the intro to the Wikipedia article[0] reads:
> An operating system shell is a computer program that provides relatively broad and direct access to the system on which it runs. The term shell refers to how it is a relatively thin layer around an operating system.
> Most shells are command-line interface (CLI) programs. Some graphical user interfaces (GUI) also include shells.
The last line I think supports the notion that the term "shell" at least implies a CLI, but I can understand both positions.
---
0. https://en.wikipedia.org/wiki/Shell_(computing)
Edit: I'm shite at formatting on HN
Not "implies", just "more commonly refers to".
Both usages (graphical and CLI) of the term are correct. Saying "shell" doesn't by itself imply one or the other, even if the technology that is more commonly discussed when we say "shell" is those CLI things in UNIX-like OSs.
A bit like how cars are typically small vehicles with internal combustion engines, but that doesn't mean EVs are not a classification of cars too.
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.
Why do you think GNOME Shell is called GNOME Shell?
https://gitlab.gnome.org/GNOME/gnome-shell
(just as one example)
38 years ago: https://en.wikipedia.org/wiki/DOS_Shell
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 the hosts capabilities. But that hasn’t been an apt description for most of those 40 years.
Appeal to authority.
[dead]
command line shell vs graphical shell. My first experience with a graphical shell was dosshell[1]. For a while we called the Windows 3.1 interface "the shell". I guess the terminology has changed since that time.
[1] https://en.wikipedia.org/wiki/DOS_Shell