That seems to me to be one of the least generous interpretations, no?

It could also imply that, for whatever reason, the LLM opted for those tools. Therefore there isn't necessarily "reason" in the asked sense.

depending on how you view it, the build server _does_ serve the APKs, right?

Why is this?

I don't want to presume your use case, but Ghostty has a command for dumping the buffer to a file, which I use for processing output "too late" to use grep.

keybind = ctrl+alt+shift+o=write_scrollback_file:open

Bitwarden has a desktop GUI app as well as an official CLI. If you're comfortable with it, there are also community ones like https://github.com/doy/rbw

Wouldn't "partially" be fair? Since not ALL of the project is, but only source of a certain age?

That in my mind would be a much fairer categorization.

It definitely is, buy I think the silent majority just don't care all that much. Is that what you're referring to?

What is the first-best choice for a new project? SQLite?

No, generally Postgres, just not for everything. If you understand the tradeoffs SQLite can be fine. Once you have more than one service (even just for HA) SQLite means doing kind of crazy things like using NFS in your infra. If you know you will only have one service and can bind it to an EBS like volume it is totally fine.

That’s my point, there is no best-first choice for everything. There will always be trade-offs. But Postgres makes the right trade-offs to be good enough in almost every scenario.

Doesn't enforcing this require storing the password in cleartext somewhere, which is a much more dangerous concept to begin with?

In practice, that's probably how it's done. But in theory: no.

Assume you keep the hashes of the last few passwords around. Then you can search in the 'neighbourhood' of the new password to check if any of this matches the old password's hash.

By neighbourhood, I mean something like within a small edit-distance, where the kind of edits depend on what measure of similarity you want.

If you only care about similarity to the last password (or care about that one specifically), then that's even easier: during the password change procedure you can have clear text access to both the old and the new passwords without storing them anywhere unhashed: because the user has just entered both passwords.

Wouldn't this be super slow if you're using a proper password hashing algorithm?

Yes, if it takes one cpu second to hash a password, it'll take a while to try a few like this.

You can do a quick check against the last password (which you have in clear, because it was just entered), though.

Not if they ask for the current password at the same time.

https://news.ycombinator.com/item?id=44265372

Similarly of new vs current password is simple enough by just requiring the current password as part of the password change call. Which is a good idea anyway so someone can't just walk up and change your password if you forget to lock things over lunch.

Similarly vs older passwords is what would be an issue.

> Similarly vs older passwords is what would be an issue.

Which isn't unheard of, though it's been years since I've seen it.

It probably requires some sort of decreased security (if the password hash is truly slow & secure, it would be hard to enforce dissimilarity); but there might be other methods that leak less than cleartext (like salting and storing hashes of overlapping/separate n-grams from the previous password and checking for number of similar n-grams; etc). Or as another commenter suggested checking all passwords within edit distance 1 (though if you can do that, your password hashing algorithm is likely too fast).

Interesting perspective. Wonder why so many SaaS service currently enforce this.

Cargo culting.

Currently work here and we're definitely still building and supporting Elixir applications and enjoying it!