Hacker Newsnew | past | comments | ask | show | jobs | submit | amadeuspagel's commentslogin

Only works in a git directory, and one might want to use git only for manual version control and another tool for automatic.

Then replace git with "rsync" or "borg. But I don't see how running "git init" in a directory you have "days of work" accumulated in is a sticking point.

Git is a convenient implementation detail.

The core loop of "watch a directory for changes, create a delta-only/patch-based snapshot" has been a solved few-liner in bash for a long time...


Something something Dropbox

There are a huge number of people coming into agentic coding with no real background in software dev, no real understanding of git, and even devs with years of experience will readily reach for convenience and polish even when they could otherwise implement it themselves, see: Vercel's popularity.


Create a branch, squash the branch manually when you want and merge things.

or `git reset --soft main` and then deal with the commits

or have 2 .git directories. Just add to the git commit `--git-dir=.git-backups` or whatever you want to name it.


This story of a user deleting their passkey doesn't seem plausible to me. They don't remember why they have a specific passkey for a messaging app? Surely recognizing the app that stores so many memories is enough not to delete the passkey. And why are they "cleaning up" their passkeys in the first place? Yes I put "cleaning up" in quotes, this metaphor, suggesting that a long list of unused passkeys is dirty in some way is inappropriate.

If an app has a billion users, how many do you expect will delete their passkey for no reason? Is this more important then end-to-end encryption for everyone?

If deleting one's passkey for no reason was a thing, I'd expect a real story about a real user, rather then a made-up scenario.

The essay has a condescending attitude towards the normie computer user who can't possibly be expected to know, but it's precisely the normie computer user who would never get the stupid idea of "cleaning up" their passkeys in the first place -- that's something only a nerd with a neurotic attitude to their computer would do.


This past weekend I watched as my mom discovered the password manager in Chrome, and started deleting every entry she couldn't immediately recognize. "Why is this here? I don't need this"

Despite me pleading that they got there for a reason, and takes zero storage, she was confident she didn't need these passwords. So I can totally see her deleting passkeys; my mom is basically Erica, there need to be very explicit implications stated for every action presented and not assume innate understanding


This is the kind of real world example of computer use that I missed in the article.

It's more likely for them to accidentally be deleted (or otherwise lost access): in my experience approximately zero users actually understand where their passkeys are stored, and they can be all over the place: the number one question I get is 'why can't I log in?' because they've accepted a passkey setup dialog on one machine without really reading it and now can't log in on another. Sometimes it's on the same machine but in different contexts. No passkeys should be considered something that the average user is going to reliably hold onto (in large part because the industry has been so keen to foist them on users but not very keen at all to educate them on how they work. This also makes them a lot less useful from a security point of view because it means you can't get rid of the recovery process, which tends to be the weaker link).

> in my experience approximately zero users actually understand where their passkeys are stored

Passkeys are designed to be hidden from the user. The author of this article even went on GitHub telling an open source implementation to not let users copy the private key.

https://github.com/keepassxreboot/keepassxc/issues/10407

There is a good reason for it. If you can copy and paste your passkey, then a phishing site can just ask you for it, making the phishing protection passkeys provide moot.

But the consequence is people, including many technical users on this website, cannot get a grasp on passkeys both as a concept and in a literal sense. How can you perceive, let alone understand, something that is designed to be hidden from you? It also doesn't help that it was pushed on users with little explanation and comes with many seemingly incompatible implementations.

Unless passkeys are redesigned to solve the intangibility problem, grannies will keep losing their accounts for no good reason and we will keep arguing about it on HN.


I cannot believe this guy.

> You absolutely should be preventing users from being able to copy a private key!

> Asking you to put basic protections in place and collaborate with the ecosystem/industry is hardly "anti-user-choice mentality".

> the lack of identifying passkey provider attestation (which would allow RPs to block you, and something that I have previously rallied against but rethinking as of late because of these situations).

Does this guy deflate his neighbors tires before going to work to save them from car accidents?

I cannot believe he has this ridiculous paternalistic behaviour while simultaneously having these bullet points on his personal website that he linked to.

> digital identity ● urban mobility user choice ● boston bruins


I'm curious how much this one guy, all on his own, has stalled passkey adoption.

In theory, this issue could never touch average users. It's only power users who use standalone open-source password managers. All the options normal users are funnelled into aren't going to expose passkeys in plain text (except maybe Firefox?), and thus aren't going to be phishable in any meaningful sense.

But this guy opted to tell the open-source community that having exportable passkeys is wrong, full stop, and that open-source implementations might get banned for allowing this, planting a gigantic red flag right next to the very idea of passkeys, making every single power user who sees that post (which is linked on every thread which touches on passkeys) either completely reject the idea, or approach it with extreme caution. And thus no power user will recommend it to anybody else, not to mention the general usability problems they have.

I guess if it weren't him, the same ideas would have been made clear in other ways.


This is 100% spot on.

Passkeys are a mystery, and no one bothers to explain what they are, what it means, how it works, what to do, what to avoid.

I'm not an average user - MA in Mathematics, Ph.D. in Computer Science, 27 years of experience as a developer. I have a vague idea that a passkey is like a password, but you don't see it and don't type it and it's stored "somehow, somewhere."

I can't make much sense of that. How is an "average user" suppose to make sense of that?

When I try to find out how passkeys work, I get some incomprehensible gibberish about self-signed certificates, public/private key pairs, challenges, and on and on. In short, a Monad is just a monoid in the category of endofunctors of X, with product (X) replaced by composition of endofunctors and unit set by the identity endofunctor. What's the big deal?

Since any device that stores a passkey can be lost or destroyed at any moment, I assume any passkey can be lost at any moment, and there had better be a way to recover from that. Is there? Who knows.


I consider myself pretty sophisticated with passkeys (I wrote a toy implementation of WebAuthN once to understand them better), and yet I still get tripped up by this sometimes: Not via intentional deletion, but accidental overwriting.

As far as I understand, there are several ways to enforce per-account passkey uniqueness via WebAuthN, but every once in a while, some site will somehow not realize that I have a passkey for them available already, they will offer to create a new one for me, and my password manager (Bitwarden) will do this by overwriting the old/existing passkey.

Now consider a synchronization hiccup (updating my password manager storage and the relying party's backend is not atomic), and I could totally see my passkey get lost.


That sounds like broken behavior from you password manager: deleting credentials without making that destructive action clear enough to prevent minor levels of negligence from accidentally destroying them.

I think it's actually the RP being broken, not my authenticator. Conceptually, it's the RP's burden to either avoid this situation or allow eventual consistency:

There's an explicit mechanism in WebAuthN to avoid duplicate credential generation (excludeCredentials). If a RP still insists on rotating, what they should be doing is to first add the new credential, perform a successful authentication with it, and then retire the old one.

So the problem only happens if a "single passkey only" site does not support excludeCredentials, as far as I can tell.


What you describe is annoying but not an issue if the website doesn’t use the passkey for encryption - so definitely a good recommendation

the problem so far is UI and incompatibility across devices, OSes etc. I am a big fan of Passkeys and the idea of using PRF for E2E encryption, but I wouldn't implement that as now, there is almost zero control over where those passkeys are, how I can recover them, how I manage them. Whenever I have to switch computer (mandatory policy at work), or phone (mandatory obsolence) or if I want to work across OSes (Mac for work, Windows for fun), everything falls apart, incomprehensible interfaces, inexistent transparency and control. And I'm a pro user that has actually studied how the standard works.

I'm afraid that it'll take some few more decades before we will get rid of passwords, if ever.


> And why are they "cleaning up" their passkeys in the first place?

The same reason they're cleaning up their Windows or system32 folder.


> (Alternatively, I would consider getting rid of numerical ids altogether and relying on name alone. Internet Archive does it at e.g. archive.org/details/leroy-lettering-sets, but that has some serious limitations that are not hard to imagine.)

I could try to imagine these limitations and how the Internet Archive overcomes them, but I'd prefer reading about it.


I'm always surprised that archive.org's URL scheme is still used. To this day uploads will have URLs like `/details/hey` and IIRC the only thing to distinguish them from other submissions with matching names is the auto appending of a digit. It feels like `New Folder (1)` for URLs.

Edit: I misremembered. They append the date to the URL to avoid name conflicts, like `/details/hey_20260122`.

I think Youtube got it right early. Make it short enough but random, so users won't be tempted to manually type it out and make mistakes but if they really do need to manually type it the length is reasonable. It also made sharing via SMS/Twitter limits more feasible.


I can't say that they don't for sure, but if I was designing the videoID youtube uses for URLs, I'd put a check character in there. For the rare case where it must be entered manually.

Would be nice to know if you'd made a typo rather than just hitting a blank ID in the vast space of all possible video IDs.


Tried this with german as native language and greek as language I want to learn.

First question: Wie steht es um Ihr Greek?

Greek is obviously the english and not the german name of the language. But "Wie steht es um Ihr Griechisch?" wouldn't be grammatically correct either.


FYI greek has a good introductory course by Language Transfer, from which you can graduate to textbooks (available from rutracker) and ChatGPT for practice and OCR. I also maintained decent retention by converting everything I learned into Anki cards. Living in a greek-speaking country helps, but only when you are forced to communicate in EL or when you explicitly ingest new words/phrases from what you read around. Before that, I used Duolingo for the same purpose, had issues keeping the streak up and understanding the material (this was early ChatGPT era, though).


Inventing implicit promises and then wondering whether they're broken by mistake or on purpose is not a good way to understand people. When people move, it's not because they want the exact same community they had before. People move from twitter to bluesky because they want a different community. People take vouchers for market rate housing because they want their kids to grow up in a different community.


I'd expect the website for a design system to look beautiful (or oddly satisfying, if that's the goal here) but this one doesn't. Tailwind's website looks better.

[1]: https://tailwindcss.com/


> unless you have side-by-side columns with headings or pictures mixed in, but this is seldom seen outside print, partly because the web doesn’t support it well

It does now.[1]

[1]: https://developer.mozilla.org/de/docs/Web/CSS/Guides/Grid_la...


All other browser I've tried (firefox, vivaldi, edge, safari, atlas, many others) and all other programs with a tab-based UI I use (zed, vs code, sqlitebrowser) look worse.


> All other browser I've tried (firefox, vivaldi, edge, safari, atlas, many others) and all other programs with a tab-based UI I use (zed, vs code, sqlitebrowser) look worse.

Both you and the poster could both be correct.

Looking good and being a poor interface are unrelated.

IOW, something could look absolutely beautiful and still have a nightmarish UI.

"Looking pretty" is subjective. Being a good UI is objective.


Reminds me of how like 10 years ago there were the fanbois who wanted to do their cars in Material Design or tatto Material Design on their face and such.


Yes, people who disagree with me about which program has the best implemention of a tab-based user interface remind of people who tattoo things on their face as well.


> Some such clichés are not inherently terminating, and only become so when used to intentionally dismiss, dissent, or justify fallacies.

How do you parse this sentence? Dismiss, dissent or justify fallacies? The fallacies are being dismissed, dissented (from?) or justified with a thought terminating cliché? So, the fallacy is the thought that's being terminated with the cliché?

The sentence would make grammatical sense if you remove the comma between dismiss and dissent, so that the thought terminating cliche dismisses dissent or justifies fallacies, but that only leads to more fundamental questions: Why do intentions matter? How could a cliche not be inherently thought-terminating? Are there different kinds of clichés, some thought-terminating, others thought-inspiring, or does the intention make the same cliché thought-terminating or thought-inspiring?


The sentence is meant like this:

> Some such clichés are not inherently terminating, and only become so when intentionally used to dismiss something, to dissent, or to justify fallacies.

The fact that “dissent” is an intransitive verb is an important clue. You can’t dissent fallacies. You can only dissent from something.


So a cliché is thought-terminating when it is intentionally used to dissent?


You missed the “only”. The article states having one of the three as a necessary condition, not as a sufficient one.


But the intention to dissent can be what makes a cliché thought-terminating?


> First came the infamous infinite scroll. I remember feeling uneasy the first time a web page no longer had a bottom. Logically, I knew very well that everything a browser displays is a virtual construct. There is no physical page. It is just pixels pretending to be one. Still, my brain had learned to treat web pages as objects with a beginning and an end. The sudden disappearance of that end disturbed my sense of ease.

Your brain was wrong. And my fingers were hurting (and are hurting when I use websites without infinite scroll, like Hacker News).


> And my fingers were hurting (and are hurting when I use websites without infinite scroll, like Hacker News).

https://hckrnews.com/


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: