Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A native graphical shell for SSH

probablymarcus.com

Post reply on HN
Print view View original

191–200 of 239 posts

Re: A native graphical shell for SSH

#191

Post by fragmede »

walrus01 wrote: post #131
hughw wrote: 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.

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.

Re: A native graphical shell for SSH

#192

Post by blueflow »

fragmede wrote: post #180
goranmoomin wrote: post #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 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.

It's gnome. You will have a developer explain to you how your usecase is invalid.

Re: A native graphical shell for SSH

#193

Post by sdfsdfs34dfsdf »

hiimkeks wrote: post #175
sdfsdfs34dfsdf wrote: post #173

Earlier quoted context omitted.

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

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.

Re: A native graphical shell for SSH

#194

Post by divan »

sdfsdfs34dfsdf wrote: post #170
divan wrote: 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?

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.

Re: A native graphical shell for SSH

#195

Post by divan »

otabdeveloper4 wrote: post #187
divan wrote: post #169

Earlier quoted context omitted.

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

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.

Re: A native graphical shell for SSH

#196

Post by egeozcan »

hatradiowigwam wrote: post #51

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

That quote does not have anything against GUIs, does it?

Or did you mean it in another way?

Re: A native graphical shell for SSH

#197

Post by sdfsdfs34dfsdf »

whatever1 wrote: post #71
hatradiowigwam wrote: post #51

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

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 ?

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.

Re: A native graphical shell for SSH

#198

Post by akritid »

aragilar wrote: post #174
goranmoomin wrote: post #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 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…

Up to Gtk2 is still good

Re: A native graphical shell for SSH

#199

Post by nirui »

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

Re: A native graphical shell for SSH

#200

Post by Skwid »

otabdeveloper4 wrote: post #187
divan wrote: post #169

Earlier quoted context omitted.

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

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.

Well now I want an interactive LaTex UI framework in the style of NeWS
Post reply on HN