Live data from Hacker News

A native graphical shell for SSH

probablymarcus.com

171–180 of 239 posts

Re: A native graphical shell for SSH

#171

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…

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

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

Re: A native graphical shell for SSH

#172
post #133

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

HTTP basic auth is not secure.

basic auth is secure, if used in combination with TLS.

Re: A native graphical shell for SSH

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

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

Re: A native graphical shell for SSH

#174

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…

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

Re: A native graphical shell for SSH

#175

Earlier quoted context omitted.

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…

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.

Re: A native graphical shell for SSH

#176

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…

Pretty annoying that the first comment is always someone complaining about the other commenters and dismissing their opinions

Re: A native graphical shell for SSH

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

Re: A native graphical shell for SSH

#179

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…

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

especially with features that xpra brings. But everyone's attention is elsewhere.

Re: A native graphical shell for SSH

#180

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…

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

Post reply on HN