Live data from Hacker News

A native graphical shell for SSH

probablymarcus.com

161–170 of 239 posts

Re: A native graphical shell for SSH

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

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

or just ask an llm

Re: A native graphical shell for SSH

#164

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…

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.

I can ssh into a server yet would still prefer a GUI for a lot of work.

Re: A native graphical shell for SSH

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

Re: A native graphical shell for SSH

#166
post #158

Earlier quoted context omitted.

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 an…

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

Re: A native graphical shell for SSH

#167

Earlier quoted context omitted.

You have a very loose definition of a shell that conflicts with about 40 years of history.

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…

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.

Re: A native graphical shell for SSH

#168

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 argu…

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 an…

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

Re: A native graphical shell for SSH

#169
post #158

Earlier quoted context omitted.

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

Re: A native graphical shell for SSH

#170
post #158

Earlier quoted context omitted.

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 an…

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

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.
Post reply on HN