nexox

Spinning disks have enough rotational momentum to keep spinning (which keeps the heads floating) for long enough to park the heads via a weak spring, with zero electricity. A head crash doesn't corrupt a few sectors so much as cause catastrphic damage - that disk would likely never read another sector again. Properly-functionioning spinning disks haven't had issues with random data loss on power failure for at least a decade now.

And your impression of cheap SSDs is dead, flat wrong. They're cheap - every unnecessary part is left off to save money. And we've all (all of us who pay attention) known for years that SSDs (even some with power fail protection) will lose data (even bits which it has reported to have sync'd) on power loss.

A UPS is not enough, if you need to have your data, you need multiple layers of backup, and an SSD must have some method of writing out voltatile data (mostly internal metadata, not cache) before it shuts down.

That bug was not as prominent as you make it sound - I was unable to reproduce the issue (or any other issue) across tens of thousands of reboots on the buggy firmware (running Linux and a quality SAS HBA.) The circumstances to produce a corruption were much more rare than simply "power loss," and many users with "safe" platforms could easily expect 0.5% AFR.

Even with "risky" OS and controller combinations, there was an element of probability involved, so most (probably almost all) power loss events would not hit the bug.

Plus the SSD320 was difficult to obtain back then, and reasonable operators upgraded to the firmware version with this bug fixed, so only a small percentage of the units were ever even vulnerable.

The "super capacitors" (almost nobody uses actual super capacitors after early models discovered that super capacitor lifetime at server temperature was inadequate) are just a low-pass filter - they usually only keep the drive online for a couple dozen milliseconds after main power goes down.

Most reasonable SSDs do not write cache at all, but thanks to the wear-leveling issues, they need to have a sector-mapping table to keep track of where each sector actually lives. That table takes many, many updates, and since it's usually stored in some form of a tree, it's expensive to save to media which does not support directly overwriting data (IE NAND, which requires a relatively long erase operation to become writable.) This table is typically what is lost during power events, and it is not usually written out when you sync a write.

So what happens is you write, sync, get an ack, lose power, reboot, and magically that sync'd data is either corrupt, or, even worse, it's regained the value it had before your last write, with no indication that there is a problem. This can cause some extremely interesting bugs.

And also make sure no UPS is ever loaded over ~40%, so when one of the pair fails the other can handle the full load. And always set them up in isolated pairs, with no equipment plugged into a pair member and a non-member, to prevent cascading failures.

I've seen a few different models of 2.5" Enterprise SAS drives go through a similar test (as a control,) and they were perfectly fine with no corruption after around 2 weeks of reboots at approximately 10 minute intervals.

It's the SSDs that I worry about - some store their own firmware on the same NAND as the User's data, and allow it to become corrupted during power-loss events. Several cheap models won't last more than a couple days before they simply drop off the SATA bus and never come back.

Sounds like you might be interested in this function that I keep in my bashrc, which prints a random line from Uncyclopedia (note, output may contain NSFW language and mangled unicode characters):

  mknoise(){
    curl -Ls http://uncyclopedia.wikia.com/wiki/Special:Random/ | sed -n '/<p>/,/<\/p>/p' \
        | sed -e 's/<[^>]*>//g' -e '/^*$/d' -e '/article/g' | \
        perl -MList::Util=shuffle -e 'print shuffle(<STDIN>);' | sed -n '/^.\{35\}/p' | head -n1
  }

My issue with this is that the pit stops will be so long and variable (it's not mentioned in the article, but the driver must sprint 100m to switch cars, and a 6 point harness is non-trivial to buckle and tighten,) that it will nullify any sort of on-track advantage, which is the actual interesting part of racing.

You seem to have ignored my "All other things the same" qualifier - that means you have to assume that power, weight (except for the difference between the gearboxes,) suspension, environment, tires, and everything else, is identical for the quoted part of my sentence to apply.

I don't see how your first two points are relevant to what I said, or your original post. You can love the GTR all you want, I don't mind, and I never claimed that there was anything wrong with it.

As for point 3, if you were to compare to a theoretical manual transmission GTR, that half a second of extra power would still only net you a couple tenths advantage, since acceleration and aerodynamic drag are nonlinear.

And I stand by my claim that a couple tenths on a 12 second quarter mile is 'not much faster.'

Actually VW sold a dual clutch DSG transmission in the 2003 R32, years before the GTR hit the market, and for a fraction of the price. All other things the same, a dual clutch is not much faster than a properly-operated manually-clutched gearbox, but in the case of the GTR, we'll never be able to make that comparison.

Yep, these kept going off on the (crowded) train this morning, and I thought they were some sort of fire alarm. It didn't help that everyone assumed the noise was not coming from their phone (because they'd never heard it before or found a configuration page for it,) so they mostly just let it go off while looking around for the source. The whole ride was more than a bit surreal.

In California, it doesn't matter, since it's already illegal to give speeding tickets from a manned airplane (even though they still have plenty of signs to warn you that they might do just that.)

Crucially (at least on my device,) there's no granularity to this opt in - I cannot choose to backup my application data but not my WiFi passwords. Now my options are to either accept Google's storage of my network passwords or set up and maintain my own backup system.

If you release multiple copies of the document, each with a slight variation, then keep track of who got which version, you can (potentially) figure out who leaked the document.

Or data like this could simply be released before the market opens or after it closes, like most quarterly and annual reports.

I find that many desktop websites are entirely unusable on mobile, because I can't hover over menus without a mouse. Plus, I dislike waiting for 5MB (or more) of webfonts, ads, and javascript to download over a mobile connection in order to read a 3 paragraph blog post.

I don't see desktop sites getting smaller, and I don't think they should get rid of hover-based navigation, so the solution could easily be a stripped-down version for touchscreen devices on slow networks. That doesn't require huge buttons, locked scaling, or high-end design and layout.