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.

Baking and candy making regularly specify temperatures in Fahrenheit up to 500 degrees in America. As for engineers, it largely depends on the policies of their employer. For most material properties, since the boiling point of water isn't terribly relevant, F works just as well as C (though obviously for any calculation beyond a simple threshold, you're going to want an absolute scale.)

Another advantage to Shapeways (and similar services) is that they offer significantly better printing technologies than the affordable hobby printers. SLS Nylon produces very nice parts, with relatively tight tolerances, and useful strength and stiffness properties, but last time I checked, the cheapest SLS machine was on the order of $50k US.

I obsess about lighting plenty (more than just color temperature - florescent flicker that most people don't notice irritates me to no end,) but I don't subscribe to the idea that incandescent light sources are automatically better.

I recently acquired a 40W-equivalent version of this bulb, and in A/B testing vs a 57W "efficient" incandescent, I lost track of which bulb was which. The LED bulb actually had a warmer color that the incandescent, plus very similar brightness.

Of course, most of my bulbs are horrible, dim, slow, ugly, toxic, cool white CCFLs, installed by the previous owner (even in fixtures with exposed bulbs,) so pretty much any bulbs constitute a serious improvement.

In my experience, Android multitasking still doesn't work like a desktop (or even my old n900.) Certain applications (those registered as services) can continue to work in the background, but many suspend entirely.

Sometimes I want to do something else while I wait for a large web page to load over my mobile data connection. On my n900 this worked fine, but as soon as I switch to another task, Chrome on Android 4.2.2 quits loading the page.

Plus, task switching is still a heavy operation on Android - swapping back and forth between two applications is a bulky, slow operation compared to the n900, which, itself, was bulky and slow compared to a desktop window manager.

To add to that list, I viewed the page on my (rather slow) phone, and my User Agent wasn't sufficient to get me to a mobile version of the page (assuming one exists.)

That dismissable footer covered half my screen, and the site ran so slowly that I was entirely unable to get it to dismiss.

And here I thought that relying on a browser's User Agent to make a page usable was bad form.

But Linux servers require root access (or physical access, which frequently amounts to the same thing) to modify the bootloader. If you've already got root, then you don't really need to install a bootkit - you may as well just install a modified kernel or kernel module rootkit.

Note: Lead (and dense materials in general) are not known for their abilities to absorb or slow neutrons - typically shielding is composed of materials composed of a high proportion of light hydrogen atoms, such as water, wax, or plastic.

When you've got thousands of dollars worth of tools at risk, you don't let software guess what to do - you can program most machine tools to damage themselves without a complaint. Software can help, but suggesting that a computer can produce a flawless CAM program for a CNC tool is like suggesting that computers should write web browsers or filesystems.

CAM programming is an art, and it requires intimate knowledge of the machine you're coding for if you hope to get a final product without too many trial and error iterations.