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.

Or I'm commenting on the actual article this was attached to.

Good lord.

Anyone that thinks you're going to high-side yourself by having a moving flywheel interacting with a clutch either hasn't rode a motorcycle in their life, or hasn't been doing it very long.

Hint: you can use the rotational mass of the engine to keep you upright at stop signs, and then slip the clutch to start moving again with the RPMs you already are turning. This is very normal for experienced riders to do if they don't think they'll be stopped very long (i.e. stop sign with right turn)

I want to know if they can replicate a "hover" that you can do with an ICE + clutch, where you can come up to a stop sign, go full clutch and give enough throttle to turn the engine at about 1500 RPM to create gyroscope balance effect and keep you upright, allowing you to ease out the clutch for a takeoff quickly after seeing it's safe to do so.

That would be a trick.

The plural of "anecdote" is not "data."

We're working with Ford's stated sales numbers here, not surveying people for how many of a particular car they see.

Also remember that you can recharge the truck at any campground you might be parking the trailer at. A lot of posts I've seen have a TT30 on them as well as a NEMA 14-50 and they both work because one is 120V@30A and the other is 240V@40A.

Plug your trailer and your tow vehicle in at the same time.

It's also officially abandoned by the company that created that protocol and connector, which I believe was the point.

I'm sorry, do you not understand the correlation between the charging connector in use, and availability of charging infrastructure?

Why do people think that embedded systems that don't get kernel updates will stop working because kernel maintainers are not supporting 40 year old hardware for next year's kernel release?

It's not like every previous kernel winks out of existence the instant a new version is published. They can go right on running Linux 6.x on their 40 year old hardware forever.

I want the MRI to run on whatever allows it to generate a valid imaging. I don't give two fucks if it runs a 10 year old kernel, or a 10 day old kernel.

There are ways to keep things secure through network sequestration if you have an embedded system that isn't getting updates - this isn't a new concept, and we've been doing that since embedded systems started existing.

There were problems if you didn't know what to look for, and in the early days of the Internet, people didn't know what to look for.

Namely: crap motherboards that would overclock the PCI or AGP busses, crap motherboards that would share interrupts between PCI and AGP slots, and due to the presence of ISA bus devices, could not enter the world of PCI bus mastery and edge-level triggered interrupts.

Also, there were problems with Windows 95 that would cause random bluescreens and shit if you didn't load some shim driver you had no idea you needed.

If you had the knowledge you needed and the drivers and patches available to make it work right, they were great. But there was a lot of people out there that wanted to save money over Intel, and didn't know what they were buying themselves into.

Is there some purge of all previous versions of the kernel underway from every system in existence, or can you continue to run the version you're running today, forever?

More than that - are there any improvements happening to 32-bit Linux that would have any positive effect on a 25-year old system?

At some point you just surround it in bricks and let it go as long as it's gonna go.

To be fair, the 3Dfx Voodoo / Voodoo2 and Voodoo Banshee were the best you could get at the time. Then they decided to compete with their customers by releasing the Voodoo3 series, and literally every one of their customers started licensing Nvidia Riva TNT / TNT2.

3Dfx was a dead company 2 years later, with Nvidia buying the asset portfolio, and Nvidia SLI was born.