Do you really mean that if your git repo were corrupted, restoring a snapshot of the repo from backups wouldn't work? If that's true, then it sounds like your backup system is broken. The hashes after restoring ought to be identical to what they were before the backup.

If git used the files' iNode numbers for its hashes, then I could understand how a filesystem-based backup/restore might not really work; you'd have to backup at the block level instead. But git doesn't use the iNode numbers.

git isn't magical. It only knows files. It doesn't know if you moved the repo, copied the the repo, or restored the repo from a ten year old backup. I have moved git repos around plenty of times, `cp -a`ed directories with repos, tared and un-tared directories that contain repos, and the copies have always Just Worked without any hash mismatches.

mkdir ~/test. cd ~/test. git init, touch test.txt, git add test.txt and git commit. cp -a ~/test ~/test2. cd ~/test2 and check out the backup repo. The backup is valid. Then simulate a disaster with rm -rf ~/test. Then recover from the disaster with cp -a ~/test2 ~/test and you've just restored a repo from filesystem-level backup. The resulting repo works perfectly and its hashes aren't off. git has no idea you deleted and restored under its nose. Try it yourself.

What am I missing? I'm not surprised to be called idiotic, and the shoe often fits. But I'm surprised to be called that over this.

My router's hardware's parts were made in China. Its software was made as a worldwide effort but the team seems to be officially based in the Netherlands. And I'm not asking my government's permission for updating either one. Trumptards and their micromanaging far-left centralized-economic-planners can go fuck themselves. Keep your damn dirty ape hands off my computers, comrade.

MS could be far more evil than they are, given their power and market-share. At least Satya is the devil we know.

Lying to the Board and lying to the public are different things.

rivals like AMD and Intel offer competitive specs on paper, but their software stacks have struggled with bugs, compatibility issues, and weak adoption. As a result, Nvidia has built an Apple-like moat around AI computing, leaving the industry dependent on its expensive hardware.

Nvidia's competitors need to work together to improve open-source software tooling and to standardize hardware interfaces, or else go the way of Commodore and Tandy.

Cheapskate co. doesn't want to pay for retraining from one IT specialty to another.

Boeing MCAS, run!

PeopleSkillsGPT failed them

and that takes effort.

Is there room for consciousness to manifest in a brain?

> Throttling is ineffective if you base it on IP address...

I didn't dictate any specific throttling algorithm. You are stabbing a strawman.

> an attacker obtaining the encrypted vault is probably not going to be able to decrypt many passwords,

That may not be how they breach them. It's an extra layer or device that may have an inadvertent security flaw. The more turtles in the stack, there more turtles there are to hack.

It will be interesting to see who gets rich after the bubble pops. Biggest Game of Financial Chicken Ever, Believe Me!

"Covfefe"

The random ones are too hard to remember, most will copy and paste. Either that, the help-desk is swamped with resets.

I'm not understanding why the traditional approach doesn't need throttling. Keep in mind a DOS attack is usually considered a smaller "sin" than a breach(es). If you allow too many retries, then the second sin is more likely. I see no third option*, it's either a DOS freeze or lots of retries.

If hackers find a design weakness in your company's preferred/required password-keeper, they can potentially hack them all. A company can allow multiple keeper brands, but then they either have to vet them all, or accept that some users will select a dodgy brand.

> I read your setup as a global throttle. If that's not what you meant...

* The best throttling and/or DOS defense strategy/algorithm is a more involve topic, but so far not a difference maker in what we are comparing.