I would respectfully disagree. I would much prefer a way to unshoot my foot than be bothered by "proper precautions." Why does every action have to be so final? It's not like disk space is at a premium anymore.

At some point, any action will become final, eg. once you send the report off to the client, you can't edit it any more. "Undo" is simply a way to delay that point; saving the undo stack to the disk (or otherwise saving previous versions) is merely an extension to that.

If the "shooting in the foot" involves running a CNC mill in a way the user probably didn't intend, or placing an unusually large order with a supplier, or sending out a half-written press release, it's easier to make it a difficult task than it is to figure out how to add an "undo" feature to the program.

Hell, just transmitting large blocks of 100% mathematically random data is a red flag. "One-time pad in use! Something very interesting going on here!"

In theory, there are three things that are 100% mathematically random:

1) Random data, such as the output of a hardware random number generator.
2) Encrypted data. One of the criteria for an encryption algorithm is that the output is indistinguishable from randomness. If you can tell the two apart, you can gather information about the plaintext.
3) Compressed data. If you can tell it from a stream of random bits, that represents a redundancy you can use to compress it even further.

In practice, you can tell the three apart, because compressed data usually comes with a header or other uncompressed structure, and almost nobody sends large random numbers around.

Understandable English text doesn't have very much entropy, averaging 1.5 bits per character. Your sentences have 162, 98.5, and 88.5 bits respectively (I gave you an extra bit for your typo of "entropy" in the second sentence. Just be sure you remember it the next time you type your pass-sentence in.)

If you actually do any PW cracking, you'd know that comic is wrong. Dictionary attacks with not just words, but with phrases and 1337 replacements, and exclamations, and numbers after or before or in between words, runs of N repeating characters to 'pad out' a password, etc, all get tried before brute force.

If you understood combinatorics, you'd know that the comic is right. The first row is a password made from known tricks, and is probably in a dictionary (the 28-bit strength represents the size of the smallest dictionary likely to contain it, or how far you need to go through the dictionary before running into it). The second row represents a password generated randomly from what is effectively a 2048-letter alphabet.

How good are the meters as an indication of password strength? If you've got a meter that calls "Password1" (nine characters, mixed upper and lower case with a number) strong, it doesn't matter if the meter has an effect or not.

Password strength is inherently impossible to measure (it's related to the password's Kolmogorov complexity, which is incomputable). A good heuristic meter would check the password against the output of a few password-cracking programs and assign a strength based on how long it takes the password to show up, but I doubt anyone's doing that.

The studies you cite don't distinguish cause from effect -- suicide risk leading to gun possession versus gun possession leading to suicide risk. The American Journal of Epidemiology study, in particular, emphasizes that it's a study of correlation rather than causation. A good study would be done somewhere where an external force (say, the government) caused a widespread change in the availability of guns.

The study I'm referring to did distinguish cause from effect: it studied the suicide rate before and after the UK-wide replacement of town gas, which contains carbon monoxide and can be used to commit suicide, with natural gas, which cannot. Taking away one of the most common methods of committing suicide did not have a noticeable effect on suicide rates.

Not true at all. If suicide is easy and convenient, the suicide rate will be much higher.

Epidemiological studies say otherwise: restricting access to means of suicide just changes the method. It has no impact on the suicide rate. Ban guns, and people switch to hanging, or wrist-cutting, or stepping in front of trains, or...

Cryptosystems (even trivial ones) are still regulated, just not banned from export. I looked into this recently when I was considering releasing an open-source program that implemented a number of archaic cyphers: the only cypher that wasn't covered by the arms export regulations was ROT-13 -- even the Caesar cypher is covered.

Sieverts are weighted by biological effectiveness of the particles, so that when comparing committed doses from different sources ("nature of the exposure") they are intended to be comparable.

Delivery vector matters as well. 20 mSv/yr of alpha particles delivered to the skin is essentially harmless (alpha particles cannot penetrate the dead outer layer to reach somewhere where they can cause damage), while 20 mSv/yr of alpha particles delivered to the surface of the lungs is more harmful (the lungs have no such protective layer).

The Sievert takes into account the relative effectiveness of different radiation types in causing damage (relative biological effectiveness), but not the relative susceptibility of different tissue types to damage (tissue weighting factor).

So we're back to playing "guess the verb"? Is it called a "console", a "command prompt", a "shell", or a "terminal"?

The SDHC read-write tab? It's more like a vague suggestion than a lock. I've yet to find a card reader that will actually refuse to write to a "write-protected" card.

Did you seriously just say that it's impossible for a piracy check to flag a legitimate registered user?

No, I did not. Read my post again, carefully: your scenario 4 is my "2) Anti-pirate check is run, program tells user to get an honest copy, bug is never hit."

Only someone who's stripped out the piracy check -- something a legitimate user will not do -- will hit case #3, encounter the bug, post on the forum, and be told by the program's author that they pirated it. If the piracy check works, an honest user get a bug-free program; if the piracy check fails, an honest user can't run the program and so never encounters the bug.

Except I guarantee you that some of those "pirates" were legitimate customers and all it will take is ONE person posting proof of purchase side by side with you treating them like criminals to ruin you.

If he did it right, then every one of them was a pirate. There are three states the program can be in:

1) Registered copy. Anti-pirate check is run, bug is patched, everything's good.
2) Unregistered copy. Anti-pirate check is run, program tells user to get an honest copy, bug is never hit.
3) Pirated copy. Anti-pirate check is bypassed, bug is not patched, program crashes on level 10.

Note that the only way to encounter the bug is to bypass the anti-piracy check. A legitimate customer who's had the check falsely trigger will encounter case 2, not case 3.

Actually, a HTML document starts with something like

HTTP/1.1 200 OK
Date: Fri, 15 Mar 2013 02:18:32 GMT

followed by a bunch of other headers, before you get to the DOCTYPE and such.

Knowing that the document begins with "HTTP/1.1 200 OK" isn't very helpful, because as I understand it, this isn't a known-plaintext attack, but rather a constant-plaintext attack: RC4 as used by SSL/TLS doesn't produce the same cyphertext from a given plaintext every time. Ideally, there wouldn't be any correlation between cyphertexts of the given plaintext, but flaws in the cypher mean there are, and the attack uses these flaws to figure out what the plaintext is, given a sufficient number of encrypted versions of the same plaintext.

100-120lb bows don't need that much practice. I'm not pretending I can draw one 35 inches, but I know people that do - and they haven't spent their formative years learning

Can you draw that 120-pound bow fifteen times a minute for as long as a runner keeps bringing you fresh bundles of arrows? That, not the pull weight of the bow, was the secret of the English longbow archers, and why training them took so long. The sustained rate of fire of a longbow archer was unmatched by any other combat infantry until the early 1900s.