This post was originally going to be an analysis of Al Gore's energy challenge speech and some of the criticism of it.
If you view the speech as a logical or rhetorical argument, it has its share of problems. For example, when talking about the falling price of silicon for solar cells, Gore says, "the same thing happened with computer chips--also made out of silicon. The price paid for the same performance came down by 50 percent every 18 months--year after year, and that's what's happened for 40 years in a row." This conclusion doesn't follow: the price per unit of performance for computer chip drops because transistors keep getting smaller, but making the features on a solar cell smaller will quickly run out of steam because you're fundamentally limited by the amount of sunlight per unit area. Even if you increase efficiency by 50% every 18 months, and in a few years you get darn close to 100%, you still hit the limit imposed by the sun. That's not to say that solar cells won't get cheaper, but microchips' cost per unit performance is not the right model. Also, Gore has the annoying habit of not citing his sources, even in the transcript, which makes the speech very hard to fact-check.
The criticism is worse. It opens by saying "Al Gore wants you to do as he says, not as he does" and spends fully a third of its length calling Gore a hypocrite. But that doesn't follow either: the validity of Gore's contention that we need this energy challenge, and the underlying reasoning he presents, have nothing to do with his personal energy consumption habits. It could just as easily come from, for example, T. Boone Pickens. The next third of the criticism is devoted to an argument that says, essentially, it's impossible because we're not doing it now: renewables are a tiny percentage of our current energy production, therefore it is unreasonable to expect that they could reach 100% in ten years. But at its core, this argument is a simple assertion that change is impossible, which we know by experience to be false. Finally, two thirds of the way down, the criticism brings up a scientific paper that denies human impact on global temperature change, which is at least fodder for debate. (More background on that paper here and here.)
But you know, my heart just isn't in the analysis. Deep down, the reason is that I missed the last Apollo project and want one I can be a part of. And this is a cause I can get behind. It's big, it's inspiring, it'll create some fantastic spinoff technologies, and it'll produce great results. Even on the (exceptionally remote) chance that the IPCC is wrong and the paper the criticsm cites is right, that anthropogenic global temperature change is an illusion, it's extremely hard to deny that much of U.S. foreign policy is driven by a dependence on foreign oil, that even if we tap all our domestic sources they won't meet our demand, and that shifting to domestically produced renewables would give us a ton of new flexibility in foreign policy. So, yeah, I hope this thing takes off. And if it does, I want in.
Tuesday, July 22, 2008
Sunday, July 13, 2008
redundancy and unexpected interdependency
A couple weeks ago, the office network went down. Not surprisingly, we couldn't print or get to any electronically filed documents. Maybe a bit more surprisingly, the phones also went out because we've moved to fancy new Cisco network-based phones, and they took voice mail--which is now e-mail-based--with them. And so did the fax machines, because when faxes come in they get scanned and e-mailed to us. The net result was that we were almost dead in the water. Fortunately, the Blackberries stayed up, so we could use cell phones and could still send e-mail through the Blackberry server.
These sorts of unexpected interdependencies are cropping up more and more often as we begin to link one network to another, and as traditional network technologies shift around. I've already written about how my (now former) cell phone's alarm clock stopped working when the phone couldn't reach the cell network. There was a radio discussion today about an issue with digital TV: many people put battery-powered analog TV sets in survival kits so they can get news if there's a natural disaster, but (1) the set-top converter boxes that we'll need to use once HDTV becomes standard require wall power to run, which would make those analog battery powered TVs useless, and (2) many radio stations no longer have a news department, acting more as satellite feeds for a central office, so your transistor radio may not be able to pull in anything useful, either. Oh yeah, and many folks are moving away from conventional land-lines at home and going to VOIP phones or cell phones exclusively.
The classic way to deal with system failure is through redundancy: if the TV network goes out, you still have radio, which can get you much of what you need, or maybe you still have telephone. And so forth. The problem is that redundancy only works where you can stop a failure in one system from propagating to other systems. That's one reason most software doesn't have a redundant design: it's very hard to predict how far the effects of a failure will propagate through software, so it's generally not cost-effective to make it redundant. As our networking capabilities become more sophisticated, we're getting to the point where it's becoming harder to figure out what effect a failure of one network will have on the other networked systems we use.
The right way to do this, from an engineering perspective, is to take these sorts of problems into account when designing the systems, and then to periodically test them to make sure we got it right. That's not going to happen, at least right now, for social and economic reasons. The second-best approach would be to invest time and money into developing the design and evaluation tools necessary to either constrain the effects of a failure, so they don't propagate to other systems, or to at least be able to predict the likely failure modes and how far they'll propagate. We might eventually do that, but it'll take time. What's most likely to happen is the same thing that happened in structural engineering a hundred years ago: we may well see a series of unexpected, unforecasted failures, and they'll likely continue until we implement one of the first two approaches above.
These sorts of unexpected interdependencies are cropping up more and more often as we begin to link one network to another, and as traditional network technologies shift around. I've already written about how my (now former) cell phone's alarm clock stopped working when the phone couldn't reach the cell network. There was a radio discussion today about an issue with digital TV: many people put battery-powered analog TV sets in survival kits so they can get news if there's a natural disaster, but (1) the set-top converter boxes that we'll need to use once HDTV becomes standard require wall power to run, which would make those analog battery powered TVs useless, and (2) many radio stations no longer have a news department, acting more as satellite feeds for a central office, so your transistor radio may not be able to pull in anything useful, either. Oh yeah, and many folks are moving away from conventional land-lines at home and going to VOIP phones or cell phones exclusively.
The classic way to deal with system failure is through redundancy: if the TV network goes out, you still have radio, which can get you much of what you need, or maybe you still have telephone. And so forth. The problem is that redundancy only works where you can stop a failure in one system from propagating to other systems. That's one reason most software doesn't have a redundant design: it's very hard to predict how far the effects of a failure will propagate through software, so it's generally not cost-effective to make it redundant. As our networking capabilities become more sophisticated, we're getting to the point where it's becoming harder to figure out what effect a failure of one network will have on the other networked systems we use.
The right way to do this, from an engineering perspective, is to take these sorts of problems into account when designing the systems, and then to periodically test them to make sure we got it right. That's not going to happen, at least right now, for social and economic reasons. The second-best approach would be to invest time and money into developing the design and evaluation tools necessary to either constrain the effects of a failure, so they don't propagate to other systems, or to at least be able to predict the likely failure modes and how far they'll propagate. We might eventually do that, but it'll take time. What's most likely to happen is the same thing that happened in structural engineering a hundred years ago: we may well see a series of unexpected, unforecasted failures, and they'll likely continue until we implement one of the first two approaches above.
Sunday, July 06, 2008
switching antivirus software
For a couple years, now, I've been using AVG Free edition. And for the last month or two, they've been pressuring me to upgrade to version 8. When I install new software, I often skim the End User License Agreement. In this case, here's what I turned up in the EULA for AVG Free 8.0:
Net upshot: I'm giving Avast Free Edition a try, instead. I've been running it on a desktop machine that I use occasionally for games, but this'll be the first time on the laptop I use frequently. The only difficulty I ran into is that Avast doesn't automatically uninstall AVG, so you need to do that manually via Add/Remove Programs (off the Control Panel). Also, Avast has a spinning logo in the tool tray, which is cute (the logo spins while it's doing its thing), but I find the movement distracting. However, the EULA was clean. Now we'll see how the program works.
I'm not too thrilled with the idea of my antivirus software communicating personally identifiable information back to the manufacturer based on a privacy policy they can change at any time. Based on the language in this agreement, I don't see any restrictions that would prevent them from changing the privacy policy in such a way that they could return any contents of my hard drive that they chose to. I also don't really like the idea of a toolbar redirecting DNS and Error 404 pages. The intent is probably to allow them to redirect to a "we didn't find your web page, but here are several similar pages" search engine that provides revenue to AVG, but (a) they don't make that explicit in the agreement, and (b) I don't know what effect such a redirection would have on Firefox, especially in odd situations like running a search while there's no wireless network connection, something that happens fairly frequently when our wireless cuts out.
6. Miscellaneous.
. . .
b. Privacy.
i. You acknowledge that AVG Technologies collects certain information regarding the users of the Software, including certain personally identifiable information. You hereby consent to AVG Technologies' collection and use of such information, and agree that AVG Technologies' collection and use of such information will be governed by AVG Technologies' Privacy Policy, currently published at www.avg.com, as AVG Technologies may revise the same from time to time.
ii. BY PROCEEDING TO INSTALL THE TOOLBAR, YOU ACKNOWLEDGE AND ACCEPT THAT, UPON ITS INSTALLATION, THE TOOLBAR WILL MODIFY VIA THE SETTINGS OF YOUR BROWSER THE "DNS ERROR PAGE" AND "ERROR 404 PAGE". . . .
Net upshot: I'm giving Avast Free Edition a try, instead. I've been running it on a desktop machine that I use occasionally for games, but this'll be the first time on the laptop I use frequently. The only difficulty I ran into is that Avast doesn't automatically uninstall AVG, so you need to do that manually via Add/Remove Programs (off the Control Panel). Also, Avast has a spinning logo in the tool tray, which is cute (the logo spins while it's doing its thing), but I find the movement distracting. However, the EULA was clean. Now we'll see how the program works.
Subscribe to:
Posts (Atom)