The idea of selling EV battery energy back to the grid is silly given the high depreciation costs of current EV batteries, but a closely related idea makes a lot of sense: allowing the grid operators to control the power level of EV chargers in exchange for lower rates.
Even during the day there's almost always unused generation that's much cheaper than the depreciation cost of EV batteries. Problem is, it takes time to fire up in response to an unexpected load increase. Usually the extra load is temporarily met with quickly dispatched (but more costly) spinning reserves until the more economical generators are online. Temporarily reducing EV charging powers could be an alternative to those expensive reserves, and it only needs to last until the extra generation is online. The temporary power reductions could be rotated among different EV drivers so no one user has his cranked down too often or for long.
Last night I was running Skype on a publicly routable IP address, which probably made my machine a supernode candidate. I noticed a lot of idle traffic between my Skype client and quite a few IP addresses within the Amazon EC2 compute cloud. I'd never seen that before. Usually my background traffic is to random cable and DSL addresses.
My guess is that Amazon is where Skype brought up their "extra mega-supernodes". EC2 is handy for things like that.
I'm a big Mac and OSX fan. OSX is a good UNIX system that also makes a good development front end for Linux and BSD.
But I have absolutely no interest in developing or even owning an iPhone.
First, it doesn't work with CDMA networks like Verizon and Sprint.
Second, it's not really your phone if you have to get Apple's permission to run a program on it.
People really should avoid locked-down platforms like the iPhone. They're simply not worth it. Buy a small netbook instead.
You're exactly right, Zn-air batteries have been around for a long time. Larger Zn-air batteries have also been under development for some time. So it REALLY bugs me when I see a Slashdot title like this one that's just flat-out wrong.
Any battery's theoretical energy/weight ratio is determined by its reactants. Not only do you want a lot of energy from each atom or molecule in the reaction, you also want a high ratio of valence number to atomic weight. The nuclei in the reactants are just dead weight to balance the charge on the electrons that do the work.
The ideal reactant would be cheap, nontoxic, easy to handle and electrically conductive. Nothing fits them all so you have to compromise.
Good battery fuels are easier to find than good battery oxidizers. You can't beat lithium as a fuel if you want a metal at standard temperature and pressure. The oxidizer is the big problem. In current use are MnO2, LnxCoO2, LiFePO4, AgO, PbO2, NiOOH, SO2, SOCl2, SO2Cl2, FeS, CF(n), HgO, S and lots and lots of others. They're all heavy, expensive, toxic, and/or non-conductive.
So using O2 from the air as an oxidizer is a really big win if you can do it. Zinc-air batteries and automotive fuel cells already do this. (Fuel cells for space use have to carry both H2 and O2.)
So it seems to me that if you can make a rechargeable battery with Li as the fuel and atmospheric O2 as the oxidizer, you'd really have something.
So this asks the obvious question: is Skype still secure?
Obviously it can be broken by planting malware in the target's computer, but what are the other ways? Last we heard, independent reviews of the crypto protocols said they were pretty good.
But I am quite sure there are exploitable weaknesses in the login server and protocol. Skype operates that server, so we can assume that it either is or soon will be compromised.
Consider the following simple observations. I can install Skype on another computer, sign in with my existing user name and password, and talk to any of my existing contacts without any of them noticing anything unusual. I transferred nothing from my old installation, so my new installation cannot have any of its existing secrets. It knows only one long term secret: my account password, and I use that only to authenticate myself to the Skype login server.
Furthermore, unlike most IM programs, I can sign in from multiple computers and switch between them during chat sessions. All will get copies of all that is said.
This seems to demonstrate quite clearly that with the cooperation of the operator of the Skype login server, you can impersonate any Skype user and conduct either a man-in-the-middle attack or a conferencing attack.
The weakness here is that you're relying on the login server to authenticate your correspondents instead of doing it yourself on an end-to-end basis. Without authentication, encryption is meaningless.
You could probably add packet-level authentication mechanisms to Skype traffic to protect against this attack, but if you're going that far you might as well use something completely different that you can fully trust.
The original UNIX clock counted seconds. That was always much too coarse, so BSD soon introduced a clock in microseconds. A 64-bit count of microseconds would wrap around in 584,542 years. That's probably long enough.
But is a microsecond small enough? GPS pseudorange accuracies are typically a few meters, so GPS timing is already good to ten to a few tens of nanoseconds. Future systems will undoubtedly do better, especially if atomic clocks become cheap and small enough to be standard PC motherboard items.
A 64-bit count of nanoseconds would wrap around in 584.5 years. Is that too soon?
A compromise would be 10ns counts, wrapping around in 5845 years. That would be a good match to current GPS timing precision.
Maybe we should jump right to a 128 bit count of femtoseconds. That would wrap around at about a million times the age of the universe.
You are absolutely right. UNIX and its derived systems simply made a big mistake in choosing UTC for internal use. They should use an atomic time scale, either TAI or GPS time internally, I don't really care which.
If they really have to, UNIX could define their own epoch with a zero offset to UTC as of right now. Then timestamps made in the past few years won't have to jump in the changeover. This would give exactly the same benefit as no longer applying leap seconds to UTC without removing UTC's ability to track earth rotation time.
Whatever timescale UNIX chooses, it MUST have a known offset to TAI that remains fixed for all time. Period.
It's just absurd that every time there's a leap second it ripples through the whole NTP network for hours. GPS receivers ride smoothly through leap seconds because they don't see them. Why should glitches happen in NTP/UNIX?
It should be up to the library routines to properly handle conversations between internal time and human-friendly UTC representations, driven by updated tables of leap seconds in the same way they're already driven by updated tables of daylight savings time. Both are unpredictable and subject to administrative whims. You can't base internal timescales on them. I'm tired of having to write these routines myself for my satellite tracking programs.
It's important to remember that timescales based on the rotation of the earth simply didn't exist before certain specified dates. Before 1961, UTC simply didn't exist. There's simply no proper way to date an astronomical event back in 1900 in UTC.
Even worse, between 1961 and 1972, frequent ad-hoc frequency offsets were introduced into UTC to keep it close to earth time. The UTC second and the TAI second differed slightly, and this difference was constantly changing! Only in 1972 did the present leap second system start, with the lengths of the UTC and TAI seconds exactly equal. It was an improvement over the previous system, but it's still no substitute for an atomic time scale for basic use.
Actually I thought one of the (many) advantages of the Integral Fast Reactor was a substantially reduced risk of plutonium diversion. The actinides (including plutonium) never leave the reactor site, and they are always spiked with highly radioactive fission products that make them hard to steal. Unlike thermal reactors, fast reactors can burn actinides faster than they are produced. So they are extracted and burned in the reactor.
The only radioactive materials that do leave the IFR site are the medium-lived fission products (Sr-90, Cs-137). Without the long-lived actinides, they will decay to the levels of uranium ore in only a few hundred years. And the volume of this waste will be far less than the volumes of once-through unprocessed reactor fuel now piling up in reactor pools.
The blog article at the Planetary Society website says that Ulysses will encounter Jupiter and be ejected from the solar system. Is this a theoretical possibility, or has a date for this been determined?
Ulysses originally encountered Jupiter to fling it out of the ecliptic plane so it could study the sun at high latitudes. Its aphelion is still at Jupiter's orbit. If it encounters Jupiter again, any number of things could happen to it. The statement about it being ejected seems to imply that a specific encounter trajectory is already predicted.
As trivial as it seems, I think computer naming reflects on the corporate culture. Doesn't it seem like it'd be more fun and laid back to work where the computers have names like homer, marge, maggie, lisa, etc, than net001, net002, server-6a, firewall-3a, etc?
I agree with just letting the administrators of each machine pick its name, subject to some basic rules that should be fairly obvious.
If true, this is very good news. Asteroids, the smaller and more numerous ones being undifferentiated bodies, have considerably more scientific value than the moon. It's actually much easier to rendezvous with and return from many asteroids than to land softly on the moon and return. The moon is relatively large, with a big gravity well, and without an atmosphere, aerobraking is impossible. Landing from lunar orbit and takeoff to orbit each require delta Vs greater than 2000 m/sec. Entering and leaving lunar orbit takes even more. Asteroids require earth escape, but that is only slightly more than reaching the moon's high altitude (400,000 km). The velocity change required to rendezvous with the asteroid could be minimized by careful choice of asteroid and launch window.
Asteroids would take much more time to reach, and a mission could not be quickly aborted in an emergency. The communications lag would also be significant; real time conversations would be impossible and communications might even be blocked entirely by solar conjunction for a few days at a time. These are challenges for human space flight, but not insurmountable ones.
"What is the distinction between a "lithium ion battery" and a "lithium metal battery"?"
Read the announcements and you'll see them clearly explaining the distinction. Lithium ion batteries are rechargeable. Lithium metal batteries are primary (nonrechargeable).
The hazards are distinctly different. Lithium metal is obviously reactive with water, and flammable metal fires are notoriously hard to extinguish. Lithium ion batteries are hazardous because of the *other* materials in the cell: the (flammable) organic electrolyte and the cobalt dioxide in the cathode. Cobalt dioxide is a good oxidizer.
Lithium battery fires have occurred on aircraft so it is not an imaginary concern. The question is how to maximize the benefit with the least hassle to the public. The one aspect of the new rules that makes little sense is the prohibition on spare batteries in checked luggage. What matters is whether the battery terminals are properly insulated, and there are better ways to accomplish this than putting it in the device it powers.
Hopefully there will soon be "approved" battery containers that will count as a "device" for the purposes of the checked luggage rule.
A few years ago I had to remove a plastic plug that I had accidentally dropped into our sewer cleanout, and the idea occurred to me that these lines could be conduits for fiber cables.
But the cleanout problem you mention occurred to me too, and it seemed like a show stopper. The business ends of those professional sewer snakes have some pretty nasty looking blades, designed to cut tree roots or whatever else is plugging the line, so they'd make quick work of any fiber cables in the pipe.
I hadn't thought about what would happen to the fiber cables when a sewer line is dug up for repair, but that does seem like another serious problem. Even if slack were provided, the cable would likely be damaged. If the sewer pipe needs to be replaced, the fiber in it would have to be pulled out and reinstalled, or cut and replaced with a new one.
I do not understand why everyone "just knows" that fiber to the home is too expensive, and why they're still looking for easy short-cuts. I already have six separate underground utility lines coming into my house: water, sewer, natural gas, electric power, telephone and cable TV. They didn't break the bank when they were installed, so why should fiber do so? Fiber cable itself is cheap, so nearly all of the cost is in the labor of installation. Fiber is easier to install, even underground, than sewer or water lines. It's certainly no more difficult to install than the telephone and cable TV lines they'd replace.
Others have suggested what I've long thought is an excellent way to proceed: municipalities install and maintain dark fiber networks and lease them on equal terms to competitive, commercial service providers. The telcos and cablecos act as if this were some sort of evil "socialism", but that's bullshit. Governments everywhere build and maintain public roads that are available to private and competitive commercial transportation alike, and only a few fringe libertarians object. Everyone who pays their road taxes has open access to the public roads. Municipal dark fiber networks would work exactly the same way, and we'd finally have real alternatives. Network neutrality laws would be unnecessary as competition would keep them in line.
Geothermal power is actually a form of nuclear power. It comes from the radioactive decay of potassium-40, uranium-238 and thorium-232 inside the earth.
Actually, there is a way to "tie gears to the planets". Tidal power extracts the kinetic energy of the earth's rotation using the moon as a brake.
The DMCA is so overbroad that it explicitly covers breaking anyone's encryption without their permission for any reason or creating or distributing a system that breaks the encryption.
Except that any reasonably modern cryptosystem designed to maintain confidentiality is already practically unbreakable except
by means that are already illegal, such as burglary, computer cracking, extortion, theft or torture, so a law that explicitly bans encryption breaking for that application
is essentially pointless. Only when cryptography is misused for DRM, where the basic axioms of every cryptosystem are violated, is cryptography
breakable. So only there does the DMCA have any meaning or practical applicability.
They do. If you set the option StrictHostKeyChecking to "yes", then SSH will refuse to talk to a machine whose key is not already in the local database. So the administrator
can create the database by presumably trusted means, and the users can't connect to machines without trusted keys.
The irony factor of going after AT&T with the DMCA would indeed be highly satisfying, but AT&T has enough lawyers that they can probably find a loophole in the DMCA.
Besides, the DMCA is really about the copying of material that is already publicly available to anyone who wants to buy it. It's not about protecting
the confidentiality of private conversations. Although most DRM schemes do (ab)use cryptography, the DRM threat model is fundamentally one that cryptography cannot address. Every cryptosystem assumes that the parties trust each other to not reveal plaintext to their enemies, and that the parties possess secrets that the enemies do not have.
DRM violates both assumptions, so any use of crypto by DRM is fatally flawed. If your (potential) enemy has physical possession of all
the relevant secrets to decrypt the material (and they must, otherwise they wouldn't buy it), then the cipher is breakable no matter how strong it might be when the keys are secret.
So DRM is ultimately impossible at a purely technical level, and therefore it must be backed up by laws.
Cryptography is all about protecting the confidentiality of a private communication between two trustworthy parties against an eavesdropper who doesn't have the keys.
And it has become very successful at that objective. We should just use it, routinely and for everything.
I didn't know that point-of-sale systems run over VPNs. I figured they were either dedicated networks (which I guess VPN is one form) or they used SSL. This is good to know, thanks.
And when they do, the end-points will start signing their key exchanges. Or they'll play the port-hopping game. Or they'll find any of dozens of other ways to obscure the fact that they're doing a Diffie-Hellman key exchange.
As for traffic filtering and shaping, the battle between ISP and user will end only when they agree on QoS markings and policies that are advantageous to both. This can happen.
I absolutely agree that it would be wonderful if everybody opportunistically and automatically encrypted every connection they make. It would sure help stop port filtering
and other aggravated assaults on the end-to-end principle.
But IPsec (FreeSWAN is an IPsec implementation) didn't exist when Microsoft was copying all the Internet protocols into Windows. FreeSWAN also existed as a set of patches that you had to apply yourself to the Linux kernel sources and recompile. You also needed a fair number of user-space tools and a fair bit of knowledge to
set it all up. Not even your average Linux user routinely builds his own kernels, and (as we know) only a small fraction of computer users run Linux.
At least VPNs (which also use IPsec) are already widespread in telecommuting. Any move by the ISPs to block them would be met with an immediate
user outcry, and even better, heavy pressure by the affected employers wanting to know why the ISPs Hate Business, and by extension, Hate America...
As far as SSH, if you don't already have the public key of your SSH server, or it isn't given to you in a cert signed by someone whose public key you do have on your computer, you *are* vulnerable to a MitM type attack.
True as far as it goes, but I think people often overestimate the ease of a MitM attack, even by a government, at least on a large scale.
Most encrypted communications, especially with SSH, take place repeatedly among a small, fairly well-defined set of nodes. You probably SSH into your work from home,
your home from work, and both from your laptop several times a day from several different locations: your home LAN, your office LAN, a public WiFi hotspot, over a cellular connection, etc. Unless the party in the middle manages to intercept all of these paths, you'll soon discover that a MitM attack has taken place. Eavesdroppers don't like to be discovered. It embarrasses them. Especially governments who break their own laws by doing so.
Because it's so much harder to conduct a MitM attack on a LAN wholly at one location, you can further reduce the risk of a MitM attack by making that first
connection over a local LAN. Once you've got that key cached in your laptop, you're immune to future MitM attacks (assuming you don't ignore or override the
warning message when one occurs). You can also carry the keys with you on your laptop or on a flash stick to computers at another location, avoiding even
the initial MitM vulnerability.
If the US government really decides that they want you, they have many ways to do it besides a MitM attack. They can do a black-bag job and install a keystroke
logger or Trojan on your computer (we know this has already happened in at least one bookmaking case). They can spirit you away to Gitmo and apply rubber-hose cryptanalysis.
They can plant other kinds of bugs. They can turn a friend, associate or family member into an informant. Or they can do it the quaint, old fashioned way by getting a search
warrant and hauling off all your stuff. But even they can't do this to everybody. Unlike a passive optical tap on AT&T's SONET trunks, the old fashioned techniques
take a not insignificant amount of time and effort for each and every target. Even to perform MitM attacks on a large scale
would take a fair bit of effort, and worse they would run a severe risk of being noticed. Just one well-documented case of a MitM attack by an Internet carrier would
be a pretty big story.
So set up a Linux or BSD machine in a co-lo and establish an encrypted tunnel to it over your DSL line or cable modem. Then all your traffic will appear to originate from the co-lo, not your home ISP, and eavesdropping on your broadband connection will be useless (except to reveal the identity of your co-lo).
Compared to broadband ISPs that serve your house, co-los are a dime a dozen. If one kicks you out, you can find another one. This has the additional advantage of giving you a place to serve your most popular files so you don't have to push them repeatedly over your slow upstream link.
I certainly do not recommend this as a shield for deliberate copyright infringement. They can still find you through the co-lo. But at least you'll have an extra layer of protection against a spurious complaint that can all too easily deprive you of your broadband connection without any due process.
A friend of mine recently learned this the hard way when he repaired a friend's PC. After
he fixed it, he left it running on his own network. His broadband ISP summarily cut off his service because his friend's PC was running a P2P program with copyrighted files he didn't have permission to share. He was lucky and managed to get it back, but he might not be so lucky in the future.
Slashdot Mirror
Did you actually determine those figures for yourself, or are you just repeating NRA propaganda or stuff everybody "just knows"?
The idea of selling EV battery energy back to the grid is silly given the high depreciation costs of current EV batteries, but a closely related idea makes a lot of sense: allowing the grid operators to control the power level of EV chargers in exchange for lower rates. Even during the day there's almost always unused generation that's much cheaper than the depreciation cost of EV batteries. Problem is, it takes time to fire up in response to an unexpected load increase. Usually the extra load is temporarily met with quickly dispatched (but more costly) spinning reserves until the more economical generators are online. Temporarily reducing EV charging powers could be an alternative to those expensive reserves, and it only needs to last until the extra generation is online. The temporary power reductions could be rotated among different EV drivers so no one user has his cranked down too often or for long.
Last night I was running Skype on a publicly routable IP address, which probably made my machine a supernode candidate. I noticed a lot of idle traffic between my Skype client and quite a few IP addresses within the Amazon EC2 compute cloud. I'd never seen that before. Usually my background traffic is to random cable and DSL addresses. My guess is that Amazon is where Skype brought up their "extra mega-supernodes". EC2 is handy for things like that.
I'm a big Mac and OSX fan. OSX is a good UNIX system that also makes a good development front end for Linux and BSD. But I have absolutely no interest in developing or even owning an iPhone. First, it doesn't work with CDMA networks like Verizon and Sprint. Second, it's not really your phone if you have to get Apple's permission to run a program on it. People really should avoid locked-down platforms like the iPhone. They're simply not worth it. Buy a small netbook instead.
You're exactly right, Zn-air batteries have been around for a long time. Larger Zn-air batteries have also been under development for some time. So it REALLY bugs me when I see a Slashdot title like this one that's just flat-out wrong. Any battery's theoretical energy/weight ratio is determined by its reactants. Not only do you want a lot of energy from each atom or molecule in the reaction, you also want a high ratio of valence number to atomic weight. The nuclei in the reactants are just dead weight to balance the charge on the electrons that do the work. The ideal reactant would be cheap, nontoxic, easy to handle and electrically conductive. Nothing fits them all so you have to compromise. Good battery fuels are easier to find than good battery oxidizers. You can't beat lithium as a fuel if you want a metal at standard temperature and pressure. The oxidizer is the big problem. In current use are MnO2, LnxCoO2, LiFePO4, AgO, PbO2, NiOOH, SO2, SOCl2, SO2Cl2, FeS, CF(n), HgO, S and lots and lots of others. They're all heavy, expensive, toxic, and/or non-conductive. So using O2 from the air as an oxidizer is a really big win if you can do it. Zinc-air batteries and automotive fuel cells already do this. (Fuel cells for space use have to carry both H2 and O2.) So it seems to me that if you can make a rechargeable battery with Li as the fuel and atmospheric O2 as the oxidizer, you'd really have something.
Obviously it can be broken by planting malware in the target's computer, but what are the other ways? Last we heard, independent reviews of the crypto protocols said they were pretty good.
But I am quite sure there are exploitable weaknesses in the login server and protocol. Skype operates that server, so we can assume that it either is or soon will be compromised.
Consider the following simple observations. I can install Skype on another computer, sign in with my existing user name and password, and talk to any of my existing contacts without any of them noticing anything unusual. I transferred nothing from my old installation, so my new installation cannot have any of its existing secrets. It knows only one long term secret: my account password, and I use that only to authenticate myself to the Skype login server.
Furthermore, unlike most IM programs, I can sign in from multiple computers and switch between them during chat sessions. All will get copies of all that is said.
This seems to demonstrate quite clearly that with the cooperation of the operator of the Skype login server, you can impersonate any Skype user and conduct either a man-in-the-middle attack or a conferencing attack.
The weakness here is that you're relying on the login server to authenticate your correspondents instead of doing it yourself on an end-to-end basis. Without authentication, encryption is meaningless.
You could probably add packet-level authentication mechanisms to Skype traffic to protect against this attack, but if you're going that far you might as well use something completely different that you can fully trust.
But is a microsecond small enough? GPS pseudorange accuracies are typically a few meters, so GPS timing is already good to ten to a few tens of nanoseconds. Future systems will undoubtedly do better, especially if atomic clocks become cheap and small enough to be standard PC motherboard items.
A 64-bit count of nanoseconds would wrap around in 584.5 years. Is that too soon?
A compromise would be 10ns counts, wrapping around in 5845 years. That would be a good match to current GPS timing precision.
Maybe we should jump right to a 128 bit count of femtoseconds. That would wrap around at about a million times the age of the universe.
I like the idea. Might as well fix two things at once. Should the new 64-bit counter count seconds, milliseconds, microseconds, what?
If they really have to, UNIX could define their own epoch with a zero offset to UTC as of right now. Then timestamps made in the past few years won't have to jump in the changeover. This would give exactly the same benefit as no longer applying leap seconds to UTC without removing UTC's ability to track earth rotation time.
Whatever timescale UNIX chooses, it MUST have a known offset to TAI that remains fixed for all time. Period.
It's just absurd that every time there's a leap second it ripples through the whole NTP network for hours. GPS receivers ride smoothly through leap seconds because they don't see them. Why should glitches happen in NTP/UNIX?
It should be up to the library routines to properly handle conversations between internal time and human-friendly UTC representations, driven by updated tables of leap seconds in the same way they're already driven by updated tables of daylight savings time. Both are unpredictable and subject to administrative whims. You can't base internal timescales on them. I'm tired of having to write these routines myself for my satellite tracking programs.
It's important to remember that timescales based on the rotation of the earth simply didn't exist before certain specified dates. Before 1961, UTC simply didn't exist. There's simply no proper way to date an astronomical event back in 1900 in UTC.
Even worse, between 1961 and 1972, frequent ad-hoc frequency offsets were introduced into UTC to keep it close to earth time. The UTC second and the TAI second differed slightly, and this difference was constantly changing! Only in 1972 did the present leap second system start, with the lengths of the UTC and TAI seconds exactly equal. It was an improvement over the previous system, but it's still no substitute for an atomic time scale for basic use.
I assume you meant "power in the exhaust", not "energy as thrust"?
Actually I thought one of the (many) advantages of the Integral Fast Reactor was a substantially reduced risk of plutonium diversion. The actinides (including plutonium) never leave the reactor site, and they are always spiked with highly radioactive fission products that make them hard to steal. Unlike thermal reactors, fast reactors can burn actinides faster than they are produced. So they are extracted and burned in the reactor. The only radioactive materials that do leave the IFR site are the medium-lived fission products (Sr-90, Cs-137). Without the long-lived actinides, they will decay to the levels of uranium ore in only a few hundred years. And the volume of this waste will be far less than the volumes of once-through unprocessed reactor fuel now piling up in reactor pools.
The blog article at the Planetary Society website says that Ulysses will encounter Jupiter and be ejected from the solar system. Is this a theoretical possibility, or has a date for this been determined? Ulysses originally encountered Jupiter to fling it out of the ecliptic plane so it could study the sun at high latitudes. Its aphelion is still at Jupiter's orbit. If it encounters Jupiter again, any number of things could happen to it. The statement about it being ejected seems to imply that a specific encounter trajectory is already predicted.
As trivial as it seems, I think computer naming reflects on the corporate culture. Doesn't it seem like it'd be more fun and laid back to work where the computers have names like homer, marge, maggie, lisa, etc, than net001, net002, server-6a, firewall-3a, etc? I agree with just letting the administrators of each machine pick its name, subject to some basic rules that should be fairly obvious.
If true, this is very good news. Asteroids, the smaller and more numerous ones being undifferentiated bodies, have considerably more scientific value than the moon. It's actually much easier to rendezvous with and return from many asteroids than to land softly on the moon and return. The moon is relatively large, with a big gravity well, and without an atmosphere, aerobraking is impossible. Landing from lunar orbit and takeoff to orbit each require delta Vs greater than 2000 m/sec. Entering and leaving lunar orbit takes even more. Asteroids require earth escape, but that is only slightly more than reaching the moon's high altitude (400,000 km). The velocity change required to rendezvous with the asteroid could be minimized by careful choice of asteroid and launch window.
Asteroids would take much more time to reach, and a mission could not be quickly aborted in an emergency. The communications lag would also be significant; real time conversations would be impossible and communications might even be blocked entirely by solar conjunction for a few days at a time. These are challenges for human space flight, but not insurmountable ones.
"What is the distinction between a "lithium ion battery" and a "lithium metal battery"?"
Read the announcements and you'll see them clearly explaining the distinction. Lithium ion batteries are rechargeable. Lithium metal batteries are primary (nonrechargeable).
The hazards are distinctly different. Lithium metal is obviously reactive with water, and flammable metal fires are notoriously hard to extinguish. Lithium ion batteries are hazardous because of the *other* materials in the cell: the (flammable) organic electrolyte and the cobalt dioxide in the cathode. Cobalt dioxide is a good oxidizer.
Lithium battery fires have occurred on aircraft so it is not an imaginary concern. The question is how to maximize the benefit with the least hassle to the public. The one aspect of the new rules that makes little sense is the prohibition on spare batteries in checked luggage. What matters is whether the battery terminals are properly insulated, and there are better ways to accomplish this than putting it in the device it powers.
Hopefully there will soon be "approved" battery containers that will count as a "device" for the purposes of the checked luggage rule.
But the cleanout problem you mention occurred to me too, and it seemed like a show stopper. The business ends of those professional sewer snakes have some pretty nasty looking blades, designed to cut tree roots or whatever else is plugging the line, so they'd make quick work of any fiber cables in the pipe.
I hadn't thought about what would happen to the fiber cables when a sewer line is dug up for repair, but that does seem like another serious problem. Even if slack were provided, the cable would likely be damaged. If the sewer pipe needs to be replaced, the fiber in it would have to be pulled out and reinstalled, or cut and replaced with a new one.
I do not understand why everyone "just knows" that fiber to the home is too expensive, and why they're still looking for easy short-cuts. I already have six separate underground utility lines coming into my house: water, sewer, natural gas, electric power, telephone and cable TV. They didn't break the bank when they were installed, so why should fiber do so? Fiber cable itself is cheap, so nearly all of the cost is in the labor of installation. Fiber is easier to install, even underground, than sewer or water lines. It's certainly no more difficult to install than the telephone and cable TV lines they'd replace.
Others have suggested what I've long thought is an excellent way to proceed: municipalities install and maintain dark fiber networks and lease them on equal terms to competitive, commercial service providers. The telcos and cablecos act as if this were some sort of evil "socialism", but that's bullshit. Governments everywhere build and maintain public roads that are available to private and competitive commercial transportation alike, and only a few fringe libertarians object. Everyone who pays their road taxes has open access to the public roads. Municipal dark fiber networks would work exactly the same way, and we'd finally have real alternatives. Network neutrality laws would be unnecessary as competition would keep them in line.
Actually, there is a way to "tie gears to the planets". Tidal power extracts the kinetic energy of the earth's rotation using the moon as a brake.
They do. If you set the option StrictHostKeyChecking to "yes", then SSH will refuse to talk to a machine whose key is not already in the local database. So the administrator can create the database by presumably trusted means, and the users can't connect to machines without trusted keys.
Besides, the DMCA is really about the copying of material that is already publicly available to anyone who wants to buy it. It's not about protecting the confidentiality of private conversations. Although most DRM schemes do (ab)use cryptography, the DRM threat model is fundamentally one that cryptography cannot address. Every cryptosystem assumes that the parties trust each other to not reveal plaintext to their enemies, and that the parties possess secrets that the enemies do not have.
DRM violates both assumptions, so any use of crypto by DRM is fatally flawed. If your (potential) enemy has physical possession of all the relevant secrets to decrypt the material (and they must, otherwise they wouldn't buy it), then the cipher is breakable no matter how strong it might be when the keys are secret. So DRM is ultimately impossible at a purely technical level, and therefore it must be backed up by laws.
Cryptography is all about protecting the confidentiality of a private communication between two trustworthy parties against an eavesdropper who doesn't have the keys. And it has become very successful at that objective. We should just use it, routinely and for everything.
I didn't know that point-of-sale systems run over VPNs. I figured they were either dedicated networks (which I guess VPN is one form) or they used SSL. This is good to know, thanks.
As for traffic filtering and shaping, the battle between ISP and user will end only when they agree on QoS markings and policies that are advantageous to both. This can happen.
But IPsec (FreeSWAN is an IPsec implementation) didn't exist when Microsoft was copying all the Internet protocols into Windows. FreeSWAN also existed as a set of patches that you had to apply yourself to the Linux kernel sources and recompile. You also needed a fair number of user-space tools and a fair bit of knowledge to set it all up. Not even your average Linux user routinely builds his own kernels, and (as we know) only a small fraction of computer users run Linux.
At least VPNs (which also use IPsec) are already widespread in telecommuting. Any move by the ISPs to block them would be met with an immediate user outcry, and even better, heavy pressure by the affected employers wanting to know why the ISPs Hate Business, and by extension, Hate America...
Most encrypted communications, especially with SSH, take place repeatedly among a small, fairly well-defined set of nodes. You probably SSH into your work from home, your home from work, and both from your laptop several times a day from several different locations: your home LAN, your office LAN, a public WiFi hotspot, over a cellular connection, etc. Unless the party in the middle manages to intercept all of these paths, you'll soon discover that a MitM attack has taken place. Eavesdroppers don't like to be discovered. It embarrasses them. Especially governments who break their own laws by doing so.
Because it's so much harder to conduct a MitM attack on a LAN wholly at one location, you can further reduce the risk of a MitM attack by making that first connection over a local LAN. Once you've got that key cached in your laptop, you're immune to future MitM attacks (assuming you don't ignore or override the warning message when one occurs). You can also carry the keys with you on your laptop or on a flash stick to computers at another location, avoiding even the initial MitM vulnerability.
If the US government really decides that they want you, they have many ways to do it besides a MitM attack. They can do a black-bag job and install a keystroke logger or Trojan on your computer (we know this has already happened in at least one bookmaking case). They can spirit you away to Gitmo and apply rubber-hose cryptanalysis. They can plant other kinds of bugs. They can turn a friend, associate or family member into an informant. Or they can do it the quaint, old fashioned way by getting a search warrant and hauling off all your stuff. But even they can't do this to everybody. Unlike a passive optical tap on AT&T's SONET trunks, the old fashioned techniques take a not insignificant amount of time and effort for each and every target. Even to perform MitM attacks on a large scale would take a fair bit of effort, and worse they would run a severe risk of being noticed. Just one well-documented case of a MitM attack by an Internet carrier would be a pretty big story.
I certainly do not recommend this as a shield for deliberate copyright infringement. They can still find you through the co-lo. But at least you'll have an extra layer of protection against a spurious complaint that can all too easily deprive you of your broadband connection without any due process. A friend of mine recently learned this the hard way when he repaired a friend's PC. After he fixed it, he left it running on his own network. His broadband ISP summarily cut off his service because his friend's PC was running a P2P program with copyrighted files he didn't have permission to share. He was lucky and managed to get it back, but he might not be so lucky in the future.