Live data from Hacker News

A native graphical shell for SSH

probablymarcus.com

231–239 of 239 posts

Re: A native graphical shell for SSH

#231

Earlier quoted context omitted.

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.

Re: A native graphical shell for SSH

#232

Earlier quoted context omitted.

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

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,

Then I don't apply. I'm not interested in working with garbage tech.

Re: A native graphical shell for SSH

#233
post #83

Earlier quoted context omitted.

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.

Re: A native graphical shell for SSH

#234

Earlier quoted context omitted.

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

Re: A native graphical shell for SSH

#235
post #230
post #228

Earlier quoted context omitted.

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

It's not insanely hard, I've done it before with a dummy plug and it's possible with the current implementations (essentially what you said: just a separate Wayland session). The reason it is not better supported, I would hazard, is because not many people really need their session locked when they're away - they just need to remote in.

Re: A native graphical shell for SSH

#236

Earlier quoted context omitted.

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

[flagged]

Re: A native graphical shell for SSH

#237
post #13

Earlier quoted context omitted.

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

Appeal to authority.

cool burner, can I have one?

Re: A native graphical shell for SSH

#238

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…

I never liked TUIs. Proper GUI , even Electron based apps are far superior than TUI , it just need to be built properly. But bad GUI is a bad GUI. This have all the UI/UX smells.

Re: A native graphical shell for SSH

#239

Earlier quoted context omitted.

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

Exactly - and all the best UX Decision are outdated as F - where the rest of the world consider those UI/UX Smells.
Post reply on HN