I don't understand how entropy consumption is fundamentally different than I/O consumption or memory consumption, or why it would need a different solution to the problem of competing demands for scarce resources.
Only if you demand perfect randomness (for which there is little practical use in typical computers). And even then "perfect" only means "perfectly preserving randomness" not "correctly detecting every single event/non-event". Given the relative simplicity of a radiation detector "perfect" or some very close equivalent thereto is probably not all that unrealistic anyway.
You're assuming that more noise is equivalent to more entropy -- that may or may not be true. People typically walk at a fairly even cadence, speak in a certain frequency range. Traffic noise has a predictable dopler shift and fairly well-characterized frequency distribution. And most importantly, the data isn't secret so someone else could just slap up a second mic next to yours and record the data.
Regardless, it's far from an optimal solution even if you assume that no dedicated hardware RNG is available. (Which is a bad assumption; many CPU and motherboards provide them, and they are available via USB dongle or PCI card as well). For one thing, it's really not hard to measure the time between *actually* random events, like radioactive decay, and there are a whole variety of quantum-based resistor-noise solutions available, some of which require even less hardware than the microphone solution you suggest (and which are the basis for most hardware RNG cards/chips/etc.).
And let's not even get into the danger of storing random data. In typical use the value of random numbers is that they are unpredictable -- as soon as you start storing your random data you run the risk of getting a whole list of PRNG seeds through something as simple as bad file permissions (which is entirely possible given the apparent non-importance of a file full of random data).
The general point is it's actually *not* that hard to get random data in modern computers, and you probably *can't* figure out a better solution on your own, at least not without some serious effort. The only real problem described in TFA is that VMs do not always offer access to the already-available entropy sources, and that admins don't take care to ensure the careful use of those sources.
First, real-world images are not very random just be virtual of being part of the real world; random things also need to happen. This is particularly mostly-static images like you'd see in 24/7 web cams -- there is not much entropy available.
Second, most of the reason we want random data for seeing purposes is because the seed needs to be something an attacker cannot derive. The output of truly random number generator cannot be predicted by a remote attacker, but publicly available video streams most certainly can, so any source that sends the same data to more than one person is not suitable for things like cryptography. Frankly that's the whole point of the article; if there are many VMs on the same host, or many real hosts on the same hardware and network, started at the same time, and using the same source for entropy they will all generate the same "random" number.
Finally, this is a well-solved problem. Many CPUs and motherboards include a hardware RNG that is perfectly sufficient both in terms of randomness and speed for typical PRNG seeding needs. VIA has had one directly in all their CPUs for a long time, Intel includes one in their firmware hubs, and I'm sure there are similar options on most other architectures. Using that on-board RNG to individually seed each VM/host would solve the problem described in the article. There's no reason to try to invent ways to get random data unless you have very specific requirements not met by the existing solutions, as you're quite likely to come up with something inferior either in design or implementation.
Many do. VIA has had CPU-integrated dual-oscillator hardware RNGs for a long time. Intel firmware hubs also commonly contain a hardware RNG, as do other motherboard architectures.
They aren't very fast sources of random data -- it's actually pretty hard to get truly random data, even outside the world of desktop CPUs -- but they are fast enough to provide a relatively long seed for a PRNG within seconds of boot. Assuming you use a reasonable PRNG, providing a truly random seed is sufficient to let the PRNG generate a high-speed sequence of data random enough for most practical applications, and certainly is unpredictable enough to protect against the situations described in TFA.
That's even worse than the microphone idea -- every server and VM within 20 miles of you would have the same source for "random" data.
And that's ignoring the fact that clouds aren't random at all; they change in very well-understood ways given the wind, humidity, temperature, etc. The path, shape and density of clouds can be predicted in general terms a week in advance, and pretty specifically over the course of a few minutes.
Unless you wanted all of the servers (and all of the VMs on each server) to have *different* entropy sources, which was the whole point of TFA. Unless you run a lot of single-device racks each in their own room you're just going to end up with an expensive way to get exactly the same "random" data on each machine.
There's also some correlation between things like disk activity and sound output of the machine; there may be some entropy available in the ambient sound -- it may even be chaotic -- but it's certainly not a source of random data.
Most of the RNG chips publish pretty good specifications on the design of their entropy source, the amount of real entropy it provides, and the circumstances in which that entropy level might be reduced. There could be implementation or production errors or course, just like there could be runtime or compiler errors with software, but the design is available for perusal and has been analyzed.
Anyone who doesn't have a clear view of the south sky. Besides possible natural obstructions -- like living on the north side of a hill -- there are many manmade obstructions that prevent communication with most geo satellites. For example, people who live in a multi-tenant building and don't have a direct southern exposure, or who do have a southern exposure but are too close to nearby tall buildings to see the right bit of sky. Not to mention the complication in mounting a dish out your 7th story window.
Beside that, satellite Internet is either 56kbps landline upload or extremely high latency (and even with a landline uplink the latency isn't good by any standard, as the downlink is still sat-based), and it's relatively expensive to boot.
Recent versions of BIND (8+) are not terrible to administer, and have much more reasonable data files. Older version were *really* nasty, and had a data file format so complicated that we invented a dedicated zone-transfer mechanism just so people could send DNS data to each other.
And while djbdns uses an unconventional admin system with lots of environmental variables, that's a one-time setup (that is probably done in large part by your package manager) and the actual data files are dead-simple -- plain text, one record per line, can do DNS lookups at build time, can concatenate files, etc. There are valid complaints to be made about djbdns, but I don't think "difficult to wrangle" is one of them.
I'm probably 10 time more likely to be in a situation where I don't have a pen or paper handy. For example, I rarely leave my house without my cell phone, but I only carry a pen if I expect someone will want me to fill out a form. Diagrams a bit of hassle on a cell phone -- unless it has a touch screen -- but given a real computer there shouldn't be any issue if you simply switch to a drawing program.
And there are other benefits to typing notes instead of drawing them on paper -- even if drawing words by hand was much faster I'd likely still choose to type my notes so that I can search quickly; if I have to read my entire set of notes just to find the section I want they are vastly less useful.
And that's far from the only example. Many jurisdictions have even enacted strict liability laws against private-residence underage consumption -- where simply "failing to prevent" underage consumption is a crime, even if you didn't provide the alcohol, or did not have reason to believe that it would be consumed by underage individuals.
I agree that HTTPS will not solve this problem. But if you're paying $$$ you're paying too much. You can get 99+% of web users with certificates that cost $30/year or less.
Moreover, if it's your own browser and your own computers, you can simply set up your own CA, add the CA cert to your local X.509 authority lists, and then issue a many certs as you'd like for $0. There's a small time investment if you don't already have OpenSSL setup and configured somewhere, but probably not even $30 worth if you know what you're doing. Of if you only need one certificate it can even be self-signed, so long as you only trust that particular certificate (as opposed to any self-signed certificate with the same CN).
So your argument against long copyright terms hinges on a you're-too-dumb-to-decide-how-to-spend-your-own-money argument? Really? I also wonder why authors couldn't just buy life insurance like the rest of us; it's relatively cheap for people young enough to have children who need ongoing support.
First I'm wondering why the faraday cage you propose blocks only GPS and not cellular radio -- while you could certainly construct such a thing it doesn't seem like something that would happen accidentally.
Second, you should be aware that a full-metal case is not an incredibly typical construction for semi trailers. Many have plastic top, since the top bears little load and plastic can be made translucent to allow outside light into the trailer. Many also have wooden bottom, as wood is much cheaper and easier to replace than sheet metal would be, and the floor is subject to a lot of abuse. It's also not uncommon to have non-metal sides, or sometimes even tensioned-fabric sides, on trailers where there is not likely to be a lot of lateral stress.
Re:Amusingly..
on
R.I.P. FTP
·
· Score: 2, Informative
FTP opens an entire new TCP connect for each file transfered, and is plenty chatty in the command channel while that happens. It's probably not the handshake times that are slowing you down.
More likely it's the relative inefficiency of SFTP on high-latency links -- SFTP has a relatively small transfer and pending request window, which means that with any significant latency you'll spend a lot of time waiting for confirmations instead of actually sending data.
For example, in OpenSSH prior to 4.7 the default limit for outstanding requests was only 16. Since 4.7 the default has been 64, and in both versions you can adjust the limit at runtime with `-R num_requests`. OpenSSH 4.7 also increased the default receive window size, which improves transfer speeds on links with non-trivial latency.
I know you're half-trolling, since the current iPhone has both GPS and a magnetic compass. And I can certainly see why you're not as irrationally excited by the iPhone as other are. But when you say "Had robust Exchange connectivity" wouldn't it be more reasonable to ask that Exchange "Had robust IMAP connectivity"? We have a widely-used, well-documented, long-established, royalty-free protocol for remote mailbox access, which the iPhone supports fairly well -- it's Exchange that doesn't speak email.
If you're going to whine about email access on a phone you should whine about the BlackBerry (any of them) and their lack of an IMAP client, or the ability to monitor more than one mail account, or the ability to not send your credentials to the BB server if you do use their non-syncing, inbox-only "IMAP" service. I know they're "helping" by providing push email, and it's not a terrible option for some people, but I get perfectly good battery life polling for email in 3 separate accounts, and the 2-minute average/4-minute maximum delay between message delivery and notification doesn't seem like a big problem for most uses.
I agree, there are problems SQL doesn't solve well. But I think it's unlikely that other, better solutions to those problems will also be superior to SQL where it *does* perform well. As such, "no SQL" is probably not the right plan any more than "SQL only".
Unless you want to browse by IP address there's no way to avoid DNS lookups when you're browsing, no matter what the browser does or doesn't store. There's also no way for the browser to disable that caching -- it's an OS-level function (in all OSes, not just OS X), not a browser feature.
It's silly anyway, because if someone is trying to track your DNS lookups it would likely be easier to simply listen for them on the network, or to guess against your network DNS cache, rather than to interface with your local cache. Unless your machine is already compromised, in which case they can see where you're browsing and what DNS queries you make no matter what OS or browser you're using, or what privacy settings you've got enabled.
If there was a slow-moving motorized vehicle -- something traveling at less than say 75% of the median speed of other traffic on the road -- many drivers would expect that vehicle to pull over to allow them to pass, rather than forcing them to drive long distances behind me at low speeds. And in many cases the driver of the slow-moving vehicle will comply on a relatively frequent basis; I have rarely been stuck behind a slow-moving motorized vehicle for more than 60-90 seconds before they pulled over to allow safe passing.
I expect the same sort of behavior from bicyclists -- if they can't keep up with the normal flow of traffic it's their duty to take the same actions we'd expect from drivers of motorized vehicles: A) choose another route better suited for the limitations of their vehicle (either wider or slower moving or with less traffic) B) allow other vehicles to pass as frequently as is practical, at intervals of no more than about a minute, even if that requires them to pull out of the roadway from time to time.
I'll give you that a good half of the ire that cyclists get is undeserved; most people are not great drivers, don't terribly enjoy the activity, and are annoyed by anything that even slightly upsets their expectations. But the other half of what gets cyclists honked at is either a failure to extend such basic roadway courtesy, or the hypocritical attitude that asks motorists to "share the road" while spouting things like "I don't care...that you have to slow down". You'd never tolerate someone driving at 2/3 the speed limit and justifying it by saying "I don't feel safe driving faster", so why should we tolerate it from people on bikes?
Was it possible to fake a moon mission -- probably. But you're missing the hard part of conspiracies: getting everyone involved to keep quiet for 50 years.
Even if you assume that most of the NASA staff an contractors really believed they were launching people, there's still a lot of people involved -- the actual astronauts, the radio relay operators, the guys who sealed no-one into the capsule, the guys who recovered no-one from the capsule, not to mention the staff involved in running the filming location(s).
At the very least I'm guessing you'd need 20+ people who *know* the moon landing was faked, and probably 2-3 times as many who could reasonably guess based on things they personally witnessed. How would you keep that many people quiet for so long?
I'm also not sure what you gain by not sending people to the moon. You've already built a giant rocket than can lift a space craft to the moon. You've already built and used human-capable space capsule technology. You're actually going to land some relatively large spacecraft on the moon. You're already going to transmit radio from the moon from several days. You're already going to land your space capsule back on Earth. Why not just put people in your space capsule and forgo the faking bit?
If you're going to define a radio as something without an LCD screen or USB port then I say we should rightly let it die -- there's no reason you can't provide both entertainment and useful emergency services on radio equipment with modern interfaces.
Also, if a flood wipes out power, communications and transportation, and you we're not able (and/or willing) to leave before that happened, or to prepare for it (say with a generator and a satellite Internet link) a radio is probably not going to save you whether you know how to use it or not.
Not checkpoints. Just electronic devices that monitor for the presence of a vehicle and increment a counter every time the presence indicator completes a full cycle. It wouldn't require anyone to stop, would cost only maybe $1k per lane to install, and most importantly wouldn't collect any information about *who* was traveling or *where* they were going.
I've got a 120" projection system that I used to think looked pretty good playing upscaled DVDs. Then I got a BD player, and I immediately wanted to replace all my old content -- it's so much better than even months later I'm still impressed when I switch from TV captures or DVDs to BD.
But most people don't have 120" screens, and at say a 12' viewing distance you probably can't see more than a few hundred lines of resolution on any screen under 50", so BD isn't a huge benefit even if you technically have a 1080p display -- on my 32" screen the DVD player is perfectly sufficient in terms of image quality, and testing on the screen with the BD player there was no appreciable increase in perceived quality from my regular viewing position.
I would still like to be able to rip BDs though, because I don't want to pay another $300 to watch BD on another monitor in the same house -- if I could rip them it wouldn't be necessary.
Slashdot Mirror
I don't understand how entropy consumption is fundamentally different than I/O consumption or memory consumption, or why it would need a different solution to the problem of competing demands for scarce resources.
Only if you demand perfect randomness (for which there is little practical use in typical computers). And even then "perfect" only means "perfectly preserving randomness" not "correctly detecting every single event/non-event". Given the relative simplicity of a radiation detector "perfect" or some very close equivalent thereto is probably not all that unrealistic anyway.
You're assuming that more noise is equivalent to more entropy -- that may or may not be true. People typically walk at a fairly even cadence, speak in a certain frequency range. Traffic noise has a predictable dopler shift and fairly well-characterized frequency distribution. And most importantly, the data isn't secret so someone else could just slap up a second mic next to yours and record the data.
Regardless, it's far from an optimal solution even if you assume that no dedicated hardware RNG is available. (Which is a bad assumption; many CPU and motherboards provide them, and they are available via USB dongle or PCI card as well). For one thing, it's really not hard to measure the time between *actually* random events, like radioactive decay, and there are a whole variety of quantum-based resistor-noise solutions available, some of which require even less hardware than the microphone solution you suggest (and which are the basis for most hardware RNG cards/chips/etc.).
And let's not even get into the danger of storing random data. In typical use the value of random numbers is that they are unpredictable -- as soon as you start storing your random data you run the risk of getting a whole list of PRNG seeds through something as simple as bad file permissions (which is entirely possible given the apparent non-importance of a file full of random data).
The general point is it's actually *not* that hard to get random data in modern computers, and you probably *can't* figure out a better solution on your own, at least not without some serious effort. The only real problem described in TFA is that VMs do not always offer access to the already-available entropy sources, and that admins don't take care to ensure the careful use of those sources.
First, real-world images are not very random just be virtual of being part of the real world; random things also need to happen. This is particularly mostly-static images like you'd see in 24/7 web cams -- there is not much entropy available.
Second, most of the reason we want random data for seeing purposes is because the seed needs to be something an attacker cannot derive. The output of truly random number generator cannot be predicted by a remote attacker, but publicly available video streams most certainly can, so any source that sends the same data to more than one person is not suitable for things like cryptography. Frankly that's the whole point of the article; if there are many VMs on the same host, or many real hosts on the same hardware and network, started at the same time, and using the same source for entropy they will all generate the same "random" number.
Finally, this is a well-solved problem. Many CPUs and motherboards include a hardware RNG that is perfectly sufficient both in terms of randomness and speed for typical PRNG seeding needs. VIA has had one directly in all their CPUs for a long time, Intel includes one in their firmware hubs, and I'm sure there are similar options on most other architectures. Using that on-board RNG to individually seed each VM/host would solve the problem described in the article. There's no reason to try to invent ways to get random data unless you have very specific requirements not met by the existing solutions, as you're quite likely to come up with something inferior either in design or implementation.
Many do. VIA has had CPU-integrated dual-oscillator hardware RNGs for a long time. Intel firmware hubs also commonly contain a hardware RNG, as do other motherboard architectures.
They aren't very fast sources of random data -- it's actually pretty hard to get truly random data, even outside the world of desktop CPUs -- but they are fast enough to provide a relatively long seed for a PRNG within seconds of boot. Assuming you use a reasonable PRNG, providing a truly random seed is sufficient to let the PRNG generate a high-speed sequence of data random enough for most practical applications, and certainly is unpredictable enough to protect against the situations described in TFA.
That's even worse than the microphone idea -- every server and VM within 20 miles of you would have the same source for "random" data.
And that's ignoring the fact that clouds aren't random at all; they change in very well-understood ways given the wind, humidity, temperature, etc. The path, shape and density of clouds can be predicted in general terms a week in advance, and pretty specifically over the course of a few minutes.
Unless you wanted all of the servers (and all of the VMs on each server) to have *different* entropy sources, which was the whole point of TFA. Unless you run a lot of single-device racks each in their own room you're just going to end up with an expensive way to get exactly the same "random" data on each machine.
There's also some correlation between things like disk activity and sound output of the machine; there may be some entropy available in the ambient sound -- it may even be chaotic -- but it's certainly not a source of random data.
Most of the RNG chips publish pretty good specifications on the design of their entropy source, the amount of real entropy it provides, and the circumstances in which that entropy level might be reduced. There could be implementation or production errors or course, just like there could be runtime or compiler errors with software, but the design is available for perusal and has been analyzed.
For example, the Intel 82802:
http://www.cryptography.com/resources/whitepapers/IntelRNG.pdf
Anyone who doesn't have a clear view of the south sky. Besides possible natural obstructions -- like living on the north side of a hill -- there are many manmade obstructions that prevent communication with most geo satellites. For example, people who live in a multi-tenant building and don't have a direct southern exposure, or who do have a southern exposure but are too close to nearby tall buildings to see the right bit of sky. Not to mention the complication in mounting a dish out your 7th story window.
Beside that, satellite Internet is either 56kbps landline upload or extremely high latency (and even with a landline uplink the latency isn't good by any standard, as the downlink is still sat-based), and it's relatively expensive to boot.
Recent versions of BIND (8+) are not terrible to administer, and have much more reasonable data files. Older version were *really* nasty, and had a data file format so complicated that we invented a dedicated zone-transfer mechanism just so people could send DNS data to each other.
And while djbdns uses an unconventional admin system with lots of environmental variables, that's a one-time setup (that is probably done in large part by your package manager) and the actual data files are dead-simple -- plain text, one record per line, can do DNS lookups at build time, can concatenate files, etc. There are valid complaints to be made about djbdns, but I don't think "difficult to wrangle" is one of them.
I'm probably 10 time more likely to be in a situation where I don't have a pen or paper handy. For example, I rarely leave my house without my cell phone, but I only carry a pen if I expect someone will want me to fill out a form. Diagrams a bit of hassle on a cell phone -- unless it has a touch screen -- but given a real computer there shouldn't be any issue if you simply switch to a drawing program.
And there are other benefits to typing notes instead of drawing them on paper -- even if drawing words by hand was much faster I'd likely still choose to type my notes so that I can search quickly; if I have to read my entire set of notes just to find the section I want they are vastly less useful.
You've really never heard of strict liability in relation to the underage consumption of alcohol? Have you heard of google?
http://lmgtfy.com/?q=%22strict+liability%22+sale+alcohol
Here's one example, from California, in the first page of Google hits:
http://law.onecle.com/california/business/25658.html
Which was enacted in 1998 and upheld in court by 2002.
And that's far from the only example. Many jurisdictions have even enacted strict liability laws against private-residence underage consumption -- where simply "failing to prevent" underage consumption is a crime, even if you didn't provide the alcohol, or did not have reason to believe that it would be consumed by underage individuals.
I agree that HTTPS will not solve this problem. But if you're paying $$$ you're paying too much. You can get 99+% of web users with certificates that cost $30/year or less.
Moreover, if it's your own browser and your own computers, you can simply set up your own CA, add the CA cert to your local X.509 authority lists, and then issue a many certs as you'd like for $0. There's a small time investment if you don't already have OpenSSL setup and configured somewhere, but probably not even $30 worth if you know what you're doing. Of if you only need one certificate it can even be self-signed, so long as you only trust that particular certificate (as opposed to any self-signed certificate with the same CN).
So your argument against long copyright terms hinges on a you're-too-dumb-to-decide-how-to-spend-your-own-money argument? Really? I also wonder why authors couldn't just buy life insurance like the rest of us; it's relatively cheap for people young enough to have children who need ongoing support.
First I'm wondering why the faraday cage you propose blocks only GPS and not cellular radio -- while you could certainly construct such a thing it doesn't seem like something that would happen accidentally.
Second, you should be aware that a full-metal case is not an incredibly typical construction for semi trailers. Many have plastic top, since the top bears little load and plastic can be made translucent to allow outside light into the trailer. Many also have wooden bottom, as wood is much cheaper and easier to replace than sheet metal would be, and the floor is subject to a lot of abuse. It's also not uncommon to have non-metal sides, or sometimes even tensioned-fabric sides, on trailers where there is not likely to be a lot of lateral stress.
FTP opens an entire new TCP connect for each file transfered, and is plenty chatty in the command channel while that happens. It's probably not the handshake times that are slowing you down.
More likely it's the relative inefficiency of SFTP on high-latency links -- SFTP has a relatively small transfer and pending request window, which means that with any significant latency you'll spend a lot of time waiting for confirmations instead of actually sending data.
For example, in OpenSSH prior to 4.7 the default limit for outstanding requests was only 16. Since 4.7 the default has been 64, and in both versions you can adjust the limit at runtime with `-R num_requests`. OpenSSH 4.7 also increased the default receive window size, which improves transfer speeds on links with non-trivial latency.
I know you're half-trolling, since the current iPhone has both GPS and a magnetic compass. And I can certainly see why you're not as irrationally excited by the iPhone as other are. But when you say "Had robust Exchange connectivity" wouldn't it be more reasonable to ask that Exchange "Had robust IMAP connectivity"? We have a widely-used, well-documented, long-established, royalty-free protocol for remote mailbox access, which the iPhone supports fairly well -- it's Exchange that doesn't speak email.
If you're going to whine about email access on a phone you should whine about the BlackBerry (any of them) and their lack of an IMAP client, or the ability to monitor more than one mail account, or the ability to not send your credentials to the BB server if you do use their non-syncing, inbox-only "IMAP" service. I know they're "helping" by providing push email, and it's not a terrible option for some people, but I get perfectly good battery life polling for email in 3 separate accounts, and the 2-minute average/4-minute maximum delay between message delivery and notification doesn't seem like a big problem for most uses.
I agree, there are problems SQL doesn't solve well. But I think it's unlikely that other, better solutions to those problems will also be superior to SQL where it *does* perform well. As such, "no SQL" is probably not the right plan any more than "SQL only".
It may or may not be, but it's not really relevant -- adding support for a new codec and/or file format doesn't require fixing the underlying system.
Unless you want to browse by IP address there's no way to avoid DNS lookups when you're browsing, no matter what the browser does or doesn't store. There's also no way for the browser to disable that caching -- it's an OS-level function (in all OSes, not just OS X), not a browser feature.
It's silly anyway, because if someone is trying to track your DNS lookups it would likely be easier to simply listen for them on the network, or to guess against your network DNS cache, rather than to interface with your local cache. Unless your machine is already compromised, in which case they can see where you're browsing and what DNS queries you make no matter what OS or browser you're using, or what privacy settings you've got enabled.
If there was a slow-moving motorized vehicle -- something traveling at less than say 75% of the median speed of other traffic on the road -- many drivers would expect that vehicle to pull over to allow them to pass, rather than forcing them to drive long distances behind me at low speeds. And in many cases the driver of the slow-moving vehicle will comply on a relatively frequent basis; I have rarely been stuck behind a slow-moving motorized vehicle for more than 60-90 seconds before they pulled over to allow safe passing.
I expect the same sort of behavior from bicyclists -- if they can't keep up with the normal flow of traffic it's their duty to take the same actions we'd expect from drivers of motorized vehicles:
A) choose another route better suited for the limitations of their vehicle (either wider or slower moving or with less traffic)
B) allow other vehicles to pass as frequently as is practical, at intervals of no more than about a minute, even if that requires them to pull out of the roadway from time to time.
I'll give you that a good half of the ire that cyclists get is undeserved; most people are not great drivers, don't terribly enjoy the activity, and are annoyed by anything that even slightly upsets their expectations. But the other half of what gets cyclists honked at is either a failure to extend such basic roadway courtesy, or the hypocritical attitude that asks motorists to "share the road" while spouting things like "I don't care...that you have to slow down". You'd never tolerate someone driving at 2/3 the speed limit and justifying it by saying "I don't feel safe driving faster", so why should we tolerate it from people on bikes?
Was it possible to fake a moon mission -- probably. But you're missing the hard part of conspiracies: getting everyone involved to keep quiet for 50 years. Even if you assume that most of the NASA staff an contractors really believed they were launching people, there's still a lot of people involved -- the actual astronauts, the radio relay operators, the guys who sealed no-one into the capsule, the guys who recovered no-one from the capsule, not to mention the staff involved in running the filming location(s). At the very least I'm guessing you'd need 20+ people who *know* the moon landing was faked, and probably 2-3 times as many who could reasonably guess based on things they personally witnessed. How would you keep that many people quiet for so long? I'm also not sure what you gain by not sending people to the moon. You've already built a giant rocket than can lift a space craft to the moon. You've already built and used human-capable space capsule technology. You're actually going to land some relatively large spacecraft on the moon. You're already going to transmit radio from the moon from several days. You're already going to land your space capsule back on Earth. Why not just put people in your space capsule and forgo the faking bit?
If you're going to define a radio as something without an LCD screen or USB port then I say we should rightly let it die -- there's no reason you can't provide both entertainment and useful emergency services on radio equipment with modern interfaces. Also, if a flood wipes out power, communications and transportation, and you we're not able (and/or willing) to leave before that happened, or to prepare for it (say with a generator and a satellite Internet link) a radio is probably not going to save you whether you know how to use it or not.
Not checkpoints. Just electronic devices that monitor for the presence of a vehicle and increment a counter every time the presence indicator completes a full cycle. It wouldn't require anyone to stop, would cost only maybe $1k per lane to install, and most importantly wouldn't collect any information about *who* was traveling or *where* they were going.
I've got a 120" projection system that I used to think looked pretty good playing upscaled DVDs. Then I got a BD player, and I immediately wanted to replace all my old content -- it's so much better than even months later I'm still impressed when I switch from TV captures or DVDs to BD. But most people don't have 120" screens, and at say a 12' viewing distance you probably can't see more than a few hundred lines of resolution on any screen under 50", so BD isn't a huge benefit even if you technically have a 1080p display -- on my 32" screen the DVD player is perfectly sufficient in terms of image quality, and testing on the screen with the BD player there was no appreciable increase in perceived quality from my regular viewing position. I would still like to be able to rip BDs though, because I don't want to pay another $300 to watch BD on another monitor in the same house -- if I could rip them it wouldn't be necessary.