Live data from Hacker News

A native graphical shell for SSH

probablymarcus.com

141–150 of 239 posts

Re: A native graphical shell for SSH

#141

Earlier quoted context omitted.

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

Re: A native graphical shell for SSH

#142
post #73

Earlier quoted context omitted.

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.

Any experience with ‘programmers’ not knowing git?

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.

Re: A native graphical shell for SSH

#143

Earlier quoted context omitted.

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

Re: A native graphical shell for SSH

#144
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…

Re: A native graphical shell for SSH

#145
post #73

Earlier quoted context omitted.

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.

Any experience with ‘programmers’ not knowing git?

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

Re: A native graphical shell for SSH

#146
post #95

Earlier quoted context omitted.

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.

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.

Re: A native graphical shell for SSH

#147
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

Re: A native graphical shell for SSH

#148
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?

Re: A native graphical shell for SSH

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

Re: A native graphical shell for SSH

#150

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

>"Those who do not understand Unix are condemned to reinvent it, poorly." ~Henry Spencer

I need something like this for network management tools.

Post reply on HN