Clearly the operator of Lavabit received a national security letter or warrant which he objected to.... I suspect that the request was not just something mild ("This sleazebag's mail account") but something broader, given the reaction was to close down the service completely.
As I read this article in the NY Times today I thought, "Hmm, how can the NSA search the contents of all e-mail leaving the U.S.? What about e-mail from one gmail user to another? Or messages sent between servers using SMTP with SSL? Surely NSA can't decipher those just by cloning the transmission links." Well, this may be the answer -- force the e-mail providers to hand over copies of any messages sent to or from machines with foreign IP address, or written or read via webmail on a foreign machine.
But don't worry, FISA will prevent NSA from obtaining copies of purely domestic e-mail or keeping copies of these messages for more than a few seconds.
Somehow I'd rather have a public discussion of what NSA can and cannot request, rather than relying on a secret court to protect our constitutional rights.
But can you charge the phone or send out video via MHL while receiving keystrokes through the same port, as the grandparent suggested? Sending power to the host is certainly not a standard part of USB. But maybe that's the only obstacle to overcome here.
You suggest controlling volume and playback by having peripherals act like USB keyboards ("support HID"). But in the USB world peripherals can only be connected to hosts (e.g., PCs), not to each other. And currently iPods and iPhones act as peripheral devices, making it impossible to connect them to other peripherals (e.g., devices that act like keyboards). This is true both logically and physically.
To be more specific, iPods and iPhones either have to act as peripherals and use a Type B USB connector, or have to act as hosts and use a Type A connector. In the first case, they could charge and send out audio and video using the approaches you suggest, but they can't receive HID information (as far as I know). In the second case they could receive HID information, but I don't think they would be able to charge or send out audio and video.
Maybe it's time for a true peer-to-peer replacement for USB?
ScreenFlow and various others listed here look like they could also be perfect for the job (recording computer audio, microphone, local video and on-screen video).
I highly recommend using Snapz Pro X on your end. This can record all the audio and video that shows on your computer (which must be a Mac). You would just need to setup a Skype call with your interviewee, start recording and off you go. You can also set it to record only a section of your screen (e.g., the main Skype window). I've used it to record PowerPoint lectures pretty successfully (including ambient audio).
I believe iChat can have better video quality than Skype, but it is not sufficiently cross-platform for all your interviewees. So you're probably stuck with Skype unless you want to start posting videocameras back and forth to your interviewees.
You would probably do well to make a separate recording of the interviewer using a videocamera, and splice that in to the interview.
I use a similar password system (a basic formula with 8 characters, including letters, numbers and symbols, and a way of changing it for every application). This works well for most purposes (e-mail, academic logons, etc.), but generally not for financial websites (my credit card company, bank, brokerage account). So I have a different system for financial sites that _doesn't_ use any special symbols. This seems like a bad idea. Why would any website (especially one that wants the highest security possible) forbid the use of certain characters?
This idea would solve one set of problems (synchronizing events across time zones or figuring out the local time while traveling), but would create a whole new set of problems for long-distance travelers.
Currently people everywhere have a common set of expectations about what time the sun rises, when to eat meals, when to sleep, etc. If you travel to a new region, you change your clock once, and you're instantly slotted in to the local expectations. On the other hand, if we followed the proposal above, travelers would have to do timezone-type math for all these events every day.
Say you travel from California to Japan. What time will the sun come up? Well, at home in California it comes up at 14:00 UTC. California is around 120 degrees W and Japan is around 138 degrees E, so Japan is about 360-258=102 degrees east of California. The sun travels 15 degrees per hour, so events will happen about 7 hours "later" in Japan than in California. Add 7 hours to 14:00 and you can expect the sun to come up around 21:00 UTC. Great. Now what time should you make a lunch appointment with a colleague? Usually in California you have lunch at 20:00 UTC, so add 7 hours, modulus 24 to get 03:00 UTC.
It's a lot of work, but at least you'll know when to catch your flight home without adjusting your clock. You just won't know (without some math) whether that will be the middle of the night, first thing in the morning, etc.
This does not strike me as easier than the current system.
It's amazing to me that until September 2008, S&P was giving AIG a AAA rating, even though AIG was taking the bad side of everyone's bets on the mortgage market, but now S&P downgrades U.S. debt over concerns about "budget deficits and rising debt burden." The U.S. government still has plenty of room to raise revenue to pay off Treasury Bills, and may even be Constitutionally obligated to do so.
It's just hard to believe that the U.S. Treasury is now considered a riskier borrower than AIG was in 2008. It's also ironic, since a good part of the U.S. debt burden was incurred bailing out AIG and the rest of the financial industry (which assumed AIG credit-default swaps would protect them, in part due to S&P's high rating of AIG).
The ever-improving climate models don't actually give estimates of the climate's dependence on CO2 that are much different from the simplest models. Given how long it will take to change our energy system, does it make sense to take action based on our best estimate of the effect of CO2 now, or wait until that estimate is perfect, which may never happen? In your opinion, when would we know well enough to declare climate change a problem and begin doing something about it?
A related question for climate change doubters: Suppose hypothetically that emissions of CO2 really were on track to cause harmful climate change. How would scientists' behavior and results differ from what we're seeing right now? Are you ruling out climate change based on the predominance of the evidence or because you'd rather not believe in it?
Yes it's a complex system, but that doesn't mean we have to understand every last detail before we take action. We've known for over a hundred years that CO2 is transparent to visible light and absorbs infrared. Therefore, adding CO2 to the atmosphere will cause warming (allowing sunlight in, but reducing the amount of heat radiated back to space). The only scientific question left is how much warming, where and when. The most natural (and safest) assumption is that adding CO2 to the atmosphere will change climate. "We should wait until we perfectly understand this insanely complex system" is not a rational response.
People can differ over whether they think climate change will be a bad thing, or whether they should have to pay to prevent bad things from happening to other people or the natural environment, but there is no question we are causing climate change. People who argue otherwise are blinding themselves for their own convenience.
Doesn't this give us a steer towards a short-term fix?... we could offset warming with some floating mirrors [or] tinfoil kites [or] pump some more dust up there.
The problem with these geoengineering approaches is that a ton of CO2 added to the atmosphere will continue to warm the planet for thousands, ofyears. On the other hand, these solutions are temporary, e.g., aerosols are washed out of the atmosphere within a few months or years.
You didn't suggest this, but if we continue emitting CO2 and try to mask the effect with aerosols, we will need to add more and more aerosols every year, until it becomes economically unfeasible and environmentally devastating. You don't want to live in a world where we pump enough aerosols into the atmosphere to mask 700 ppm CO2, and they all come back as acid precipitation.
It would be nice if they invested more in edible food and better service."
I used to wonder how shortchanging customers on food could possibly make a significant difference to the profit on a multi-hundred-dollar ticket. Then I realized that in a world where everyone chooses the cheapest ticket from Orbitz or Kayak, airlines have to get their ticket price as low as possible. If that means nickle-and-diming their customers, scrimping on food and service, then that's what they'll do. Because if they don't, a competitor will, and the competitor will be able to sell many more tickets for a few dollars less.
I have a Compact Cherry Mechanical Switch Mac Keyboard (SMK-88). It has buckling springs with the same "sound and feel" as the old IBM keyboards (which were indeed my favorite for a long time). The narrow layout (without numeric keypad) allows you to put your mousepad or pen tablet more directly in front of you, reducing RSI. It's also good for fitting all the input devices into a narrow kneewell below and old-fashioned desk.
I was pretty happy with the Cherry keyboard for a year or two, but the loud clicks did put me on edge a bit during long typing sessions. When Apple came out with their narrow bluetooth keyboard, I switched to that and haven't looked back.
The nuclear industry claims a chance of major accidents around 1 in 10^7 reactor years, based on this kind of probabilistic analysis. But then we've seen 2 major incidents at western-style nuclear plants (Three Mile Island and Fukushima Daiichi) over a period of about 15,000 reactor-years. The problem is, these studies only account for the risk of simultaneous failures of pre-identified critical components within the engineered system. They don't account for acts of nature or people doing something dumb.
Ah yes, 25 hours in a day. I often work with hourly data from power system operators, and they are completely inconsistent in how they handle daylight saving time. Many only allow for 24 hours per day, and throw out an hour or insert a null when the clocks change (good luck figuring out which hour they threw out!). The better ones have a system which allows up to 25 hours per day. One day has 23, and one has 25, but at least you can tell what's going on. I suppose these will break if the UK switches to a 2-hour leap, or possibly if they switch to two one-hour leaps. Not that Double Summer Time was unforeseeable - it's been done before, even in the UK.
If the device has no automatic way to receive this information, then you have to allow the user to tell it when DST is in effect, either when it occurs or by updating the list of rules. They'll need to be able to update the time anyway if the device is moved to a new time zone, runs fast or slow, or loses power. This worked just fine for computers "back in the day," and it works fine for the clock on my oven. Daylight Saving Time has pretty far-reaching effects, and it's unrealistic to expect policymakers to lock it down forever, just so a few automated-but-not-networked appliances can keep following the same old rules.
The rules for starting and ending U.S. daylight saving time and British Summer Time are both set by legislation and have changed several times. Hard coding them into software is a serious mistake. The only safe way to deal with DST is to maintain a lookup table for the specific dates each year or a list of the years when the rules changed, and update these tables regularly. The more often the rules change, the more incentive people will have to adopt appropriate practice, rather than encrusting their software around the old rules. (Not that the rules should be changed arbitrarily; they just shouldn't be left unchanged for fear of "breaking" something.)
The "real" article is a little more clear than the summary linked here.
The authors claim that a lot of BitTorrent content comes from people who either (a) own a private BitTorrent portal and use it to lure customers (who then share it for free on the rest of the Internet), or (b) promote some for-profit website via the torrent. These websites are promoted by (i) tacking their domain name onto the main download file, (ii) putting the URL into "the textbox" on the torrent search engine (I think this probably means putting the URL into a descriptive text file within the torrent package, which then gets shown as the description on some torrent search engines), or (iii) adding a file to the torrent named after the for-profit website.
I guess the argument is that these 100 users are uploading tons of content in order to get URLs of their own for-profit websites seen by a lot of other users. Then, when the users follow those links, they generate profit for those 100 users, either by signing up for premium bittorrent services or viewing ads on the destination website.
The bank thinks "He used a false check to get money that wasn't his into his account".
This is exactly right. All the bank knows is that this guy deposited some bad checks in his account and then asked the bank to transfer some money overseas. The bank followed his instructions and later discovered that the checks he had deposited were bogus (had been altered). They credited the bogus checks back to the original account, and then where were they supposed to turn to collect the value of those checks? Back to the guy who deposited them of course.
Now the case is between him and the person who gave him the bogus checks (in exchange for a real transfer to Malaysia). That's not the bank's problem -- they were asked to transfer funds to Malaysia and they did so. They certainly can't reverse a successful wire transfer just on his say-so. Maybe he can get some sort of judgment in a U.S. court and instruct the bank to yank back those funds from Malaysia (if they're still there)?
Of course the bank could have made life easier by inspecting the big unusual checks more closely before crediting them to his account, or advising him that the original account holder might challenge them as fraudulent. Maybe there should be a statue of limitations for fraudulent checks (e.g., 60 days), after which you can be sure they were genuine and won't be pulled back?
This does suggest that we should all be doing direct transfers rather than writing checks. There's no way to verify immediately (or even within 20 days) that a check hasn't been altered in transit (or written fraudulently). At least with a wire transfer, the originating bank can check your credentials before they transfer the money.
"I thinks Jobs has gone out of his way to make OS X incompatible with OSes other than windows."
I wouldn't say that OS X is particularly compatible with Windows either. There isn't any file system that can handle >2 GB files and is available for free (in either sense) on Windows and OS X. Windows uses NTFS but has no built-in support for HFS+; Mac uses HFS+, but has only read-only support for NTFS. Neither of them will read or write ext2/ext3, and neither of them has good support for UFS.
Linux gets good marks for supporting all of the above, but Apple and Microsoft can't seem to get their act together. This is probably because Microsoft has never seen fit to support HFS+ (which is publicly documented, although I don't know if it's an open standard) or to publish the specifications for NTFS (which would allow Apple to support it natively).
If you're willing to install third-party software, the options open up a bit. MacDrive does a good job of accessing HFS+ from Windows and HFSExplorer or Apple's Boot Camp driver gives read-only support. MacFUSE can access NTFS and ext2/3, but was slow and/or unstable when I last tried it.
I'm amazed that in 2010 there's still no widely supported modern file system for all three operating systems. It's a big pain if you want to run a mix of OS X, Boot Camp and Parallels on the same machine -- there's no way to keep all your documents in one place.
I suppose you're right, provided the decompression happens in thermal equilibrium with the water reservoir (e.g., underwater). It's hard to see how that could be done, since the air is being fed into a turbine, but maybe it's possible.
I think the process you propose has two elements: a possibly isothermal compression/expansion cycle, and some work done against/by the buoyancy force on the air bags.
My proposal was to eliminate the compression/expansion cycle, and just do the work, which could have 90% roundtrip efficiency (with efficient generator, gearbox, pulleys, etc.) This also wouldn't require you to run a gas turbine to take advantage of the compressed air.
You are using a false dichotomy here. In fact the best approach is to use all available flexibility to improve the match between supply and demand. There is no need to smooth out either supply or demand on a one-to-one basis. Instead, you use a smaller amount of flexible assets (hydro, pumped hydro, air storage, fast-start gas generators, electric vehicle chargers, price-sensitive customers, etc.) to fill in the gaps between the two. To the extent that variations in supply and demand (or between different locations) are uncorrelated, you can take advantage of statistical smoothing and get more bang for your buck by smoothing out the whole portfolio.
It is likely that there will be days when loads are fairly high and wind power production in the same region is relatively low. It is less likely that solar would also be low on those days. If you have customers who are willing to use less power on these rare occasions, then you can take advantage of that. If not, it doesn't cost much to build a few natural gas turbines that you only run on these rare occasions.
I think the losses in the CAES system are due to the fact that it is a non-adiabatic process (a diabatic process?, i.e. one where heat can be lost from the system). When you compress the air, the temperature rises, and some heat is lost to the surrounding ground. But if the cycles are fast enough, those losses may be reduced -- i.e., you allow the air to re-expand, which cools it, and it sucks heat back from the ground. Since heat moves slowly through the ground, you may be able to get a lot of it back before it goes anywhere. The innovation in the Alabama system was to use waste heat in the turbine's exhaust gases to replace this lost heat as well.
I think the solution you propose is isobaric (constant pressure) and isothermal (constant temperature), but still not adiabatic. Some of the energy used to compress the air is converted to heat, and that heat would be lost to the ocean instead of raising the temperature of the air.
A better solution might be to use pre-inflated air bags (or air boxes?) attached to pulleys on the bottom of the ocean. Use a motor to pull the other end of the rope, and you would draw the air bag downward, storing energy. Play out the rope and the rising air bag would turn the motor (now acting as a generator), generating electricity. You could also do this with stones or bags of silt/gravel, just raising and lowering them from the surface.
The problem is, you would need a lot of air bags or stones to store any significant amount of energy. If the stones or gravel have a density of 2000 kg/m^3 (similar to "Gravel, wet" according to http://www.simetric.co.uk/si_materials.htm, higher than "Clay, wet excavated" (1600) but lower than concrete (2400)), then they will have a net weight in water of about 1000 kg/m^3 (i.e., a downward force of about 10000 Newtons per m^3). Air bags would exert a similar force upward. If you can find a near-shore location with a depth of 1 km, you could store 10000 N * 1000 m = 10 MJ of energy per cubic meter of material, which is about 3 kWh/m^3. A 100 MW wind farm (presumably closer to shore) would generate 100,000 kWh of electricity per hour when the wind is blowing, so if you wanted to store 6 hours of energy from this wind farm, you would need to raise and lower about 6 * 100,000 / 3 = 200,000 cubic meters of stone or air (e.g., 200 large chunks, each 10 meters across). I suppose it could be done...
Slashdot Mirror
Clearly the operator of Lavabit received a national security letter or warrant which he objected to. ... I suspect that the request was not just something mild ("This sleazebag's mail account") but something broader, given the reaction was to close down the service completely.
As I read this article in the NY Times today I thought, "Hmm, how can the NSA search the contents of all e-mail leaving the U.S.? What about e-mail from one gmail user to another? Or messages sent between servers using SMTP with SSL? Surely NSA can't decipher those just by cloning the transmission links." Well, this may be the answer -- force the e-mail providers to hand over copies of any messages sent to or from machines with foreign IP address, or written or read via webmail on a foreign machine.
But don't worry, FISA will prevent NSA from obtaining copies of purely domestic e-mail or keeping copies of these messages for more than a few seconds.
Somehow I'd rather have a public discussion of what NSA can and cannot request, rather than relying on a secret court to protect our constitutional rights.
But can you charge the phone or send out video via MHL while receiving keystrokes through the same port, as the grandparent suggested? Sending power to the host is certainly not a standard part of USB. But maybe that's the only obstacle to overcome here.
You suggest controlling volume and playback by having peripherals act like USB keyboards ("support HID"). But in the USB world peripherals can only be connected to hosts (e.g., PCs), not to each other. And currently iPods and iPhones act as peripheral devices, making it impossible to connect them to other peripherals (e.g., devices that act like keyboards). This is true both logically and physically.
To be more specific, iPods and iPhones either have to act as peripherals and use a Type B USB connector, or have to act as hosts and use a Type A connector. In the first case, they could charge and send out audio and video using the approaches you suggest, but they can't receive HID information (as far as I know). In the second case they could receive HID information, but I don't think they would be able to charge or send out audio and video.
Maybe it's time for a true peer-to-peer replacement for USB?
ScreenFlow and various others listed here look like they could also be perfect for the job (recording computer audio, microphone, local video and on-screen video).
I highly recommend using Snapz Pro X on your end. This can record all the audio and video that shows on your computer (which must be a Mac). You would just need to setup a Skype call with your interviewee, start recording and off you go. You can also set it to record only a section of your screen (e.g., the main Skype window). I've used it to record PowerPoint lectures pretty successfully (including ambient audio).
I believe iChat can have better video quality than Skype, but it is not sufficiently cross-platform for all your interviewees. So you're probably stuck with Skype unless you want to start posting videocameras back and forth to your interviewees.
You would probably do well to make a separate recording of the interviewer using a videocamera, and splice that in to the interview.
I use a similar password system (a basic formula with 8 characters, including letters, numbers and symbols, and a way of changing it for every application). This works well for most purposes (e-mail, academic logons, etc.), but generally not for financial websites (my credit card company, bank, brokerage account). So I have a different system for financial sites that _doesn't_ use any special symbols. This seems like a bad idea. Why would any website (especially one that wants the highest security possible) forbid the use of certain characters?
This idea would solve one set of problems (synchronizing events across time zones or figuring out the local time while traveling), but would create a whole new set of problems for long-distance travelers.
Currently people everywhere have a common set of expectations about what time the sun rises, when to eat meals, when to sleep, etc. If you travel to a new region, you change your clock once, and you're instantly slotted in to the local expectations. On the other hand, if we followed the proposal above, travelers would have to do timezone-type math for all these events every day.
Say you travel from California to Japan. What time will the sun come up? Well, at home in California it comes up at 14:00 UTC. California is around 120 degrees W and Japan is around 138 degrees E, so Japan is about 360-258=102 degrees east of California. The sun travels 15 degrees per hour, so events will happen about 7 hours "later" in Japan than in California. Add 7 hours to 14:00 and you can expect the sun to come up around 21:00 UTC. Great. Now what time should you make a lunch appointment with a colleague? Usually in California you have lunch at 20:00 UTC, so add 7 hours, modulus 24 to get 03:00 UTC.
It's a lot of work, but at least you'll know when to catch your flight home without adjusting your clock. You just won't know (without some math) whether that will be the middle of the night, first thing in the morning, etc.
This does not strike me as easier than the current system.
It's amazing to me that until September 2008, S&P was giving AIG a AAA rating, even though AIG was taking the bad side of everyone's bets on the mortgage market, but now S&P downgrades U.S. debt over concerns about "budget deficits and rising debt burden." The U.S. government still has plenty of room to raise revenue to pay off Treasury Bills, and may even be Constitutionally obligated to do so.
It's just hard to believe that the U.S. Treasury is now considered a riskier borrower than AIG was in 2008. It's also ironic, since a good part of the U.S. debt burden was incurred bailing out AIG and the rest of the financial industry (which assumed AIG credit-default swaps would protect them, in part due to S&P's high rating of AIG).
The ever-improving climate models don't actually give estimates of the climate's dependence on CO2 that are much different from the simplest models. Given how long it will take to change our energy system, does it make sense to take action based on our best estimate of the effect of CO2 now, or wait until that estimate is perfect, which may never happen? In your opinion, when would we know well enough to declare climate change a problem and begin doing something about it?
A related question for climate change doubters: Suppose hypothetically that emissions of CO2 really were on track to cause harmful climate change. How would scientists' behavior and results differ from what we're seeing right now? Are you ruling out climate change based on the predominance of the evidence or because you'd rather not believe in it?
Yes it's a complex system, but that doesn't mean we have to understand every last detail before we take action. We've known for over a hundred years that CO2 is transparent to visible light and absorbs infrared. Therefore, adding CO2 to the atmosphere will cause warming (allowing sunlight in, but reducing the amount of heat radiated back to space). The only scientific question left is how much warming, where and when. The most natural (and safest) assumption is that adding CO2 to the atmosphere will change climate. "We should wait until we perfectly understand this insanely complex system" is not a rational response.
People can differ over whether they think climate change will be a bad thing, or whether they should have to pay to prevent bad things from happening to other people or the natural environment, but there is no question we are causing climate change. People who argue otherwise are blinding themselves for their own convenience.
Doesn't this give us a steer towards a short-term fix? ... we could offset warming with some floating mirrors [or] tinfoil kites [or] pump some more dust up there.
The problem with these geoengineering approaches is that a ton of CO2 added to the atmosphere will continue to warm the planet for thousands, of years. On the other hand, these solutions are temporary, e.g., aerosols are washed out of the atmosphere within a few months or years.
You didn't suggest this, but if we continue emitting CO2 and try to mask the effect with aerosols, we will need to add more and more aerosols every year, until it becomes economically unfeasible and environmentally devastating. You don't want to live in a world where we pump enough aerosols into the atmosphere to mask 700 ppm CO2, and they all come back as acid precipitation.
If they are accounted for, why is this news?
Well, actually climate models do account for aerosols and this isn't news.
It would be nice if they invested more in edible food and better service."
I used to wonder how shortchanging customers on food could possibly make a significant difference to the profit on a multi-hundred-dollar ticket. Then I realized that in a world where everyone chooses the cheapest ticket from Orbitz or Kayak, airlines have to get their ticket price as low as possible. If that means nickle-and-diming their customers, scrimping on food and service, then that's what they'll do. Because if they don't, a competitor will, and the competitor will be able to sell many more tickets for a few dollars less.
I have a Compact Cherry Mechanical Switch Mac Keyboard (SMK-88). It has buckling springs with the same "sound and feel" as the old IBM keyboards (which were indeed my favorite for a long time). The narrow layout (without numeric keypad) allows you to put your mousepad or pen tablet more directly in front of you, reducing RSI. It's also good for fitting all the input devices into a narrow kneewell below and old-fashioned desk.
I was pretty happy with the Cherry keyboard for a year or two, but the loud clicks did put me on edge a bit during long typing sessions. When Apple came out with their narrow bluetooth keyboard, I switched to that and haven't looked back.
Another relevant xkcd comic: Good Code
The nuclear industry claims a chance of major accidents around 1 in 10^7 reactor years, based on this kind of probabilistic analysis. But then we've seen 2 major incidents at western-style nuclear plants (Three Mile Island and Fukushima Daiichi) over a period of about 15,000 reactor-years. The problem is, these studies only account for the risk of simultaneous failures of pre-identified critical components within the engineered system. They don't account for acts of nature or people doing something dumb.
Ah yes, 25 hours in a day. I often work with hourly data from power system operators, and they are completely inconsistent in how they handle daylight saving time. Many only allow for 24 hours per day, and throw out an hour or insert a null when the clocks change (good luck figuring out which hour they threw out!). The better ones have a system which allows up to 25 hours per day. One day has 23, and one has 25, but at least you can tell what's going on. I suppose these will break if the UK switches to a 2-hour leap, or possibly if they switch to two one-hour leaps. Not that Double Summer Time was unforeseeable - it's been done before, even in the UK.
If the device has no automatic way to receive this information, then you have to allow the user to tell it when DST is in effect, either when it occurs or by updating the list of rules. They'll need to be able to update the time anyway if the device is moved to a new time zone, runs fast or slow, or loses power. This worked just fine for computers "back in the day," and it works fine for the clock on my oven. Daylight Saving Time has pretty far-reaching effects, and it's unrealistic to expect policymakers to lock it down forever, just so a few automated-but-not-networked appliances can keep following the same old rules.
The rules for starting and ending U.S. daylight saving time and British Summer Time are both set by legislation and have changed several times. Hard coding them into software is a serious mistake. The only safe way to deal with DST is to maintain a lookup table for the specific dates each year or a list of the years when the rules changed, and update these tables regularly. The more often the rules change, the more incentive people will have to adopt appropriate practice, rather than encrusting their software around the old rules. (Not that the rules should be changed arbitrarily; they just shouldn't be left unchanged for fear of "breaking" something.)
The "real" article is a little more clear than the summary linked here.
The authors claim that a lot of BitTorrent content comes from people who either (a) own a private BitTorrent portal and use it to lure customers (who then share it for free on the rest of the Internet), or (b) promote some for-profit website via the torrent. These websites are promoted by (i) tacking their domain name onto the main download file, (ii) putting the URL into "the textbox" on the torrent search engine (I think this probably means putting the URL into a descriptive text file within the torrent package, which then gets shown as the description on some torrent search engines), or (iii) adding a file to the torrent named after the for-profit website.
I guess the argument is that these 100 users are uploading tons of content in order to get URLs of their own for-profit websites seen by a lot of other users. Then, when the users follow those links, they generate profit for those 100 users, either by signing up for premium bittorrent services or viewing ads on the destination website.
The bank thinks "He used a false check to get money that wasn't his into his account".
This is exactly right. All the bank knows is that this guy deposited some bad checks in his account and then asked the bank to transfer some money overseas. The bank followed his instructions and later discovered that the checks he had deposited were bogus (had been altered). They credited the bogus checks back to the original account, and then where were they supposed to turn to collect the value of those checks? Back to the guy who deposited them of course.
Now the case is between him and the person who gave him the bogus checks (in exchange for a real transfer to Malaysia). That's not the bank's problem -- they were asked to transfer funds to Malaysia and they did so. They certainly can't reverse a successful wire transfer just on his say-so. Maybe he can get some sort of judgment in a U.S. court and instruct the bank to yank back those funds from Malaysia (if they're still there)?
Of course the bank could have made life easier by inspecting the big unusual checks more closely before crediting them to his account, or advising him that the original account holder might challenge them as fraudulent. Maybe there should be a statue of limitations for fraudulent checks (e.g., 60 days), after which you can be sure they were genuine and won't be pulled back?
This does suggest that we should all be doing direct transfers rather than writing checks. There's no way to verify immediately (or even within 20 days) that a check hasn't been altered in transit (or written fraudulently). At least with a wire transfer, the originating bank can check your credentials before they transfer the money.
"I thinks Jobs has gone out of his way to make OS X incompatible with OSes other than windows."
I wouldn't say that OS X is particularly compatible with Windows either. There isn't any file system that can handle >2 GB files and is available for free (in either sense) on Windows and OS X. Windows uses NTFS but has no built-in support for HFS+; Mac uses HFS+, but has only read-only support for NTFS. Neither of them will read or write ext2/ext3, and neither of them has good support for UFS.
Linux gets good marks for supporting all of the above, but Apple and Microsoft can't seem to get their act together. This is probably because Microsoft has never seen fit to support HFS+ (which is publicly documented, although I don't know if it's an open standard) or to publish the specifications for NTFS (which would allow Apple to support it natively).
If you're willing to install third-party software, the options open up a bit. MacDrive does a good job of accessing HFS+ from Windows and HFSExplorer or Apple's Boot Camp driver gives read-only support. MacFUSE can access NTFS and ext2/3, but was slow and/or unstable when I last tried it.
I'm amazed that in 2010 there's still no widely supported modern file system for all three operating systems. It's a big pain if you want to run a mix of OS X, Boot Camp and Parallels on the same machine -- there's no way to keep all your documents in one place.
I suppose you're right, provided the decompression happens in thermal equilibrium with the water reservoir (e.g., underwater). It's hard to see how that could be done, since the air is being fed into a turbine, but maybe it's possible.
I think the process you propose has two elements: a possibly isothermal compression/expansion cycle, and some work done against/by the buoyancy force on the air bags.
My proposal was to eliminate the compression/expansion cycle, and just do the work, which could have 90% roundtrip efficiency (with efficient generator, gearbox, pulleys, etc.) This also wouldn't require you to run a gas turbine to take advantage of the compressed air.
You are using a false dichotomy here. In fact the best approach is to use all available flexibility to improve the match between supply and demand. There is no need to smooth out either supply or demand on a one-to-one basis. Instead, you use a smaller amount of flexible assets (hydro, pumped hydro, air storage, fast-start gas generators, electric vehicle chargers, price-sensitive customers, etc.) to fill in the gaps between the two. To the extent that variations in supply and demand (or between different locations) are uncorrelated, you can take advantage of statistical smoothing and get more bang for your buck by smoothing out the whole portfolio.
It is likely that there will be days when loads are fairly high and wind power production in the same region is relatively low. It is less likely that solar would also be low on those days. If you have customers who are willing to use less power on these rare occasions, then you can take advantage of that. If not, it doesn't cost much to build a few natural gas turbines that you only run on these rare occasions.
See, e.g., http://users.ox.ac.uk/~cenv0115/
I think the losses in the CAES system are due to the fact that it is a non-adiabatic process (a diabatic process?, i.e. one where heat can be lost from the system). When you compress the air, the temperature rises, and some heat is lost to the surrounding ground. But if the cycles are fast enough, those losses may be reduced -- i.e., you allow the air to re-expand, which cools it, and it sucks heat back from the ground. Since heat moves slowly through the ground, you may be able to get a lot of it back before it goes anywhere. The innovation in the Alabama system was to use waste heat in the turbine's exhaust gases to replace this lost heat as well.
I think the solution you propose is isobaric (constant pressure) and isothermal (constant temperature), but still not adiabatic. Some of the energy used to compress the air is converted to heat, and that heat would be lost to the ocean instead of raising the temperature of the air.
A better solution might be to use pre-inflated air bags (or air boxes?) attached to pulleys on the bottom of the ocean. Use a motor to pull the other end of the rope, and you would draw the air bag downward, storing energy. Play out the rope and the rising air bag would turn the motor (now acting as a generator), generating electricity. You could also do this with stones or bags of silt/gravel, just raising and lowering them from the surface.
The problem is, you would need a lot of air bags or stones to store any significant amount of energy. If the stones or gravel have a density of 2000 kg/m^3 (similar to "Gravel, wet" according to http://www.simetric.co.uk/si_materials.htm, higher than "Clay, wet excavated" (1600) but lower than concrete (2400)), then they will have a net weight in water of about 1000 kg/m^3 (i.e., a downward force of about 10000 Newtons per m^3). Air bags would exert a similar force upward. If you can find a near-shore location with a depth of 1 km, you could store 10000 N * 1000 m = 10 MJ of energy per cubic meter of material, which is about 3 kWh/m^3. A 100 MW wind farm (presumably closer to shore) would generate 100,000 kWh of electricity per hour when the wind is blowing, so if you wanted to store 6 hours of energy from this wind farm, you would need to raise and lower about 6 * 100,000 / 3 = 200,000 cubic meters of stone or air (e.g., 200 large chunks, each 10 meters across). I suppose it could be done...