> well if you have encrypted storage and already need password to get to it, secondary password is of little value
That's only true when your machine is powered off. If an attacker manages to yank files from your disk while it is running, that ssh-key password is the difference between "they stole my ssh key" and "they stole worthless random data".
> use hardware key for ssh
That's the real solution. I don't understand why people still store ssh keys on disk when hardware keys are simple, easy, and significantly more secure.
> That's the real solution. I don't understand why people still store ssh keys on disk when hardware keys are simple, easy, and significantly more secure.
At work, every place big enough to maybe care about this was so “enterprisey” and “cloudy” that I almost never use/used ssh anyway, even with tons of Linux systems all over the place. Pretty much only to talk to GitHub.
I lose stuff all the time. The idea of these things gives me anxiety. The first time I lost 15 minutes figuring out where I put my hardware key, before I could ssh in to do 20 seconds of running commands, I’d back out of the whole project and return to using a file on disk, guaranteed.
Files on disk are free, hardware keys cost money.
25 years as a backend-heavy programmer, sysadmin, and devops-sort (sometimes all at once, lol). I’ve still never even touched one of these devices, and have only rarely seen one.
Do you lose your keys? I just keep my main yubikey on my keychain. Never gets lost or else I'd be homeless. I keep a 2nd backup key in a secure place just in case, so I don't get locked out of my accounts if I get struck by lightning.
> hardware keys cost money
Barely. You can get u2f keys for $10-$20 which are usable with ssh. My yubikeys were $50 each (I have 2, one main key and one backup) which adds up to $100 but yubikeys are built like tanks, they'll last forever. I've had mine for the past 7 years and I have no reason to replace them. That's only $14/year so far for the pair of keys. Totally worth it for the knowledge that I could load every virus/trojan/keylogger known to man onto my computer and they still would be completely unable to steal my ssh+pgp keys.
> You think you know it, but only after you've spent some time iterating in the space of solutions, you'll see the path forward.
I'd turn it around- this is the reason asking questions does work! When you don't know what you want, someone asking you for more specifics is sometimes very illuminating, whether that someone is real or not.
LLMs have played this role well for me in some situations, and atrociously in others.
I think what's lacking in LLMs creating code is they can't "simulate" what a human user would experience while using the system. So they can't really evaluate alternative solutions tothe humna-app interaction.
We humans can imagine it in our mind because we have used the PC a lot. But it is still hard for use to anticipate how the actual system will feel for the end-users. Therefore we build a prototype and once we use the prototype we learn hey this can not possibly work productively. So we must try something else. The LLM does not try to use a virtual prototype and thne learn it is hard to use. Unlike Bill Clinton it doesn't feel our pain.
This looks cool! But I guess it doesn't work with GitHub itself?
Github's cli tool `gh` is great for interacting with github in the terminal, e.g. opening PRs, checking workflows, PR status, etc). I do PR reviews on the site, but you can read comments in the terminal with `gh` (it does require internet access)
My day to day requires internet regardless of github, so there's no need to go for disconnected solutions, I think that's a different situation for the author. I quite like the idea of only turning the internet faucet on at select times!
The distance the boat has to cover is 11800 kilometers, and the truck covers only 54 kilometers. Taking that average of 12 times more usage from the table of sibling comment means the ship is still 20x worse.
Useful pointers, which match my experience well when trying this out. The one big question that springs to my mind is: when you've done all these steps, how much time did you really save?
You've chosen a strategy, broke down the solution into small easy to code parts, validated business logic, noted traps to avoid, searched for all relevant code, set up a context packing document particular to this section of the code base, experimented with multiple agents, reviewed each version of the code to see if you understand it-
That sounds like a lot of work!
And why, so the AI can do the last 10% of actually coding it up? Is there even a speedup here over doing it yourself? There's some evidence against AI speedups [1]. Of course some of these steps are themselves AI enhanced, and some of them are part of the work regardless of whether you use AI.
I still feel skeptical on this workflow and how big the gains could possibly be. I feel more for the alternate approach of writing it yourself, but using the AI for the boring parts (e.g. copy this section, but use those functions), or for sparring / research. I have however no data to show which approach takes less time.
I can however tell you from experimenting with full on vibe coding- you can do it with half the attention you'd give the task yourself. Is that what I'm gaining, that I can read a book during code generation? (https://xkcd.com/303/)
To my mind, the interjector is just playing a nitpick game: refocus the question (" I coudn't see it's back") to another ("did you circle the squirrel"), and then acting as though the original question is off topic.
Yes technically he did circle the squirrel from his reference point, what of it? that wasn't the point. The point was he couldn't see the squirrel, and this question is only tangentially related.
This was a great read. I think the twin concepts of rising expectations and rising requirements go a long way to explaining the complaints expressed by that popular 140k post.
I also really liked the game designer rule;
> People are very good at noticing when things suck. Not as good at figuring out why (...) If you want to address people’s concerns rather than win an argument, then it is you who must identify and state their concerns accurately.
I'd compare this to the concept of "steelmanning"- not easily dismissing a statement based on some small detail, but trying to adress the statement fully.
You're presumably joking? If not, could you elaborate?
reply