Boston and Washington DC will have merged into a giant city with 40 million inhabitants
He came close, though: he underestimated the population of BosWash (it's just shy of 50 million), and it's still a group of distinct governmental entities rather than a single unit, despite being a continuous urban area about 300 miles long.
The biggest sign of a vanished high-tech civilization is not a presence, but an absence: a near-total absence of high-grade metal ores. Probably the best evidence that humans are the first widespread technological species on Earth is the presence of high-grade iron ore spread across virtually the entire world.
I suppose the Wikipedia article needs to be corrected, then, and someone should probably tell Google to update their maps; they might also want to inform Nicaragua and Costa Rica that the Cañas-Jerez Treaty is based on a misunderstanding of geography.
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).
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.
The techniques you describe will be effective against someone who just wants free Internet access, but if they're attacking for any other reason, it's like going into a bar in the bad part of town and proclaiming how tough you are: it does nothing to improve your safety, but makes you a much more attractive target.
The failure mode of flash memory is to become read only. If you couldn't access it after a week it is NOT the flash memory that failed. Most likely it's the controller
Is it? Not one of the drives being tested in the Xtremesystems endurance test had a failure mode of "went read-only". Drives have failed to retain data, they've corrupted data, they've failed to be detected by the OS, but they've never entered read-only mode.
IOW: they went lunatic over a 80kg of weight savings. Give me a fucking break. Someone at Boeing should get a beating with a cluebat.
Extra weight is expensive when you're flying. That 80kg of weight saving translates into around a half-million dollars of reduced lifetime operational costs per airplane.
The address Space of 64 bit processes is vast compared to available memory. The process will run out of memory before the address Space could be filled.
Every 64-bit OS I know of uses delayed allocation: when a program asks the OS for memory, the OS assigns a chunk of address space, but doesn't assign memory (physical, virtual, or otherwise) until the program actually tries to use it. It's quite possible for a program to exhaust the available address space without actually using very much memory.
Slashdot Mirror
He came close, though: he underestimated the population of BosWash (it's just shy of 50 million), and it's still a group of distinct governmental entities rather than a single unit, despite being a continuous urban area about 300 miles long.
If you can't see far enough ahead to spot the cop before he tags you, you can't see far enough ahead to safely go that fast.
The biggest sign of a vanished high-tech civilization is not a presence, but an absence: a near-total absence of high-grade metal ores. Probably the best evidence that humans are the first widespread technological species on Earth is the presence of high-grade iron ore spread across virtually the entire world.
I suppose the Wikipedia article needs to be corrected, then, and someone should probably tell Google to update their maps; they might also want to inform Nicaragua and Costa Rica that the Cañas-Jerez Treaty is based on a misunderstanding of geography.
Why am I having flashbacks to the Pentium 4?
1995? MultiFinder came out in 1987.
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.
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 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.
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.
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.
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.
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
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.
The techniques you describe will be effective against someone who just wants free Internet access, but if they're attacking for any other reason, it's like going into a bar in the bad part of town and proclaiming how tough you are: it does nothing to improve your safety, but makes you a much more attractive target.
Is it? Not one of the drives being tested in the Xtremesystems endurance test had a failure mode of "went read-only". Drives have failed to retain data, they've corrupted data, they've failed to be detected by the OS, but they've never entered read-only mode.
You own the car. You don't own the license plate.
Extra weight is expensive when you're flying. That 80kg of weight saving translates into around a half-million dollars of reduced lifetime operational costs per airplane.
Every 64-bit OS I know of uses delayed allocation: when a program asks the OS for memory, the OS assigns a chunk of address space, but doesn't assign memory (physical, virtual, or otherwise) until the program actually tries to use it. It's quite possible for a program to exhaust the available address space without actually using very much memory.