I already run an outbound server on a IP address block that isn't in the residential ghetto. I shouldn't have to do that, since I'm quite able to run the same server at home, and relaying through another box just decreases reliability and increases costs and network loading. And it's all so unnecessary.
I assume you're being facetious, but there's a vital issue here.
Any company that own wires in the street should be regulated as a common carrier. That means in exchange for access to public rights of way, they're
required to accept and carry any (legal) traffic to any destination without discrimination as long as
the customer pays his bills.
I consider it a major scandal that the owners of wires used to provide broadband access have so far escaped
regulation as common carriers.
Fortunately, there exists technology with which we users can fight back: encrypted tunnels. A carrier can't discriminate among different kinds of traffic if it all looks like meaningless random bits to him.
All through the 1990s we fought the "crypto wars" thinking that the government was our primary enemy. It still is a significant threat especially now, in the post 9/11 Bush/Ashcroft era. But it may turn out that the single most important
role of widespread encryption will be to enforce the end-to-end model and to kick the telecom carriers back down into their proper role as dumb, transparent bit pipe providers.
I very much doubt that users, given the option, would turn off spam blocking to the extent that it would impair the ISPs' bottom lines.
Everyone wants to block spam. I'm no exception. But we want it done right. We don't want our real mail blocked because some ISP has arbitrarily classified it as spam by its own inscrutable, unchangeable, blunt criteria. Give me, the end user, the best mechanisms available to tell you, my ISP, exactly what I consider to be spam so you can filter it for me.
This can be as simple as a Bayesian classifier on the server that diverts spam into a separate IMAP folder with its own disk quota and expiration interval. As long as I have the ability to periodically scan the junk folder for false positives and retrain the Bayesian classifier as necessary, I think I'll be happy. I'm already doing exactly this on the mail servers I run for myself, and it works extremely well.
I'd even be willing to let the ISP block mail traffic at the IP level as long as the users have the opportunity to override it. So instead of just dropping all packets from a given IP address, the SMTP server allows the transfer to proceed until all the recipients are given. If all of the message recipients have previously agreed to block the IP address in question, then the transfer can be terminated at that point without transferring the message body. This could be done by answering the DATA command with a permanent error code, or just resetting the TCP connection. Otherwise the message is accepted and delivered only to those that haven't requested that it be blocked.
An obvious optimization is possible when all the users on the system have unanimously agreed to block a given IP address. Then, and only then, can the SMTP connection be blocked before it starts. Note that these "agreements" need not be explicit; they could default to, say, the MAPS RBL as long as I can individually opt out of any or all of its entries.
My main point is that even when ISP filtering is necessary for performance reasons it is both necessary and quite feasible to leave the ultimate control over these mechanisms in the hands of the end users. And then everyone will be happy. Except the spammers.
I agree that can avoid heavy-handed filtering at your own ISP's mail server. But what about everybody else's ISP, all those that block my mail to them because I'm coming from an improperly blacklisted IP address? Can I reasonably make everyone else switch ISPs?
I think your arguments against client-side filtering are far too strong.
Client-side filtering does not need to destroy false positives. Nothing keeps a mail filter on a client from generating delivery failure messages just like those produced by a MTA. Of course, I don't know why you'd want to generate such messages in response to every spam and email worm. Besides, there's no real way to know that any message was actually read by its intended recipient (instead of silently ignored) other than for the recipient to manually reply and say so. This is just the end-to-end principle applied to email.
Nothing in client-side filtering inherently prevents you from aggregating useful information about spam. I perform my own spam filtering, and I forward all my spam to spamcop where it is aggregated with spam reports from many other users. In fact, they get better quality reports from me because I manually review the stuff in my spam folder to make sure it really is spam before I report it. (I don't really have to do that since annoyance-filter, my Bayesian spam detector of choice, has an extremely low false positive rate.)
Your one good point is about resource wastage. And I'd have no problem with a mechanism that allows users to delegate spam filtering functions to their ISPs provided that the users retain ultimate control.
The problem is that such control is almost totally lacking in today's ISP spam filtering mechanisms. Filtering is usually imposed (along with IP blacklists) by heavy-handed ISP fiat, and the users get no say over what is or isn't considered spam. If you're lucky, your ISP won't automatically drop what they consider to be spam, but will simply mark it with a header or place it in a separate IMAP folder. But you will probably have no control over their determination except to ignore it and replace it with your own.
Although most of us would probably agree on what is and isn't spam in the majority of cases, ultimately spam is in the eye of the beholder. There can be no justification for withholding email from someone who really wants to receive it, and no justification (other than ISP laziness) for not giving their users ultimate control over all filtering mechanisms.
An obvious implication of your excellent rules for ISP-level spam blocking is that IP-level blacklisting is simply unacceptable. There's no way for an individual user to turn the block off, or to even see the blocked mail since it is never sent. People frequently complain about "false positives" in spam-detection packages, but IP-level blacklisting is the real cause of most false positives.
That said, I do believe there is a place for ISP packet and email filters provided that they're under the control of the individual end user to which the traffic is directed. This is in keeping with the end-to-end principle that there is a proper role for placing certain functions within a network as a performance enhancement. In this case, the ISP can improve performance by dropping traffic that the end user would drop anyway.
Road Runner's "detailed" instructions are useless if you happen to be on what they consider a "residential" IP address block. Doesn't matter if your address is dynamic or static. Doesn't matter if the customer they're "protecting" really wants to hear from you. Doesn't matter if your machine is clean and secure and you've never spammed or relayed a spam in your life. Doesn't matter if you prefer not to use your ISP's outbound relay because it drops half your mail and delays the other half for a day. You can't send them mail. Period.
This is one of the many reasons I run my own incoming SMTP server and my own virus and spam blockers. I control them, not the morons who happen to own the only broadband pipes in town.
It's easy for you to talk about "invisible hands". What if the overly zealous ISP also happens to own the only broadband pipe that runs past your house?
I have so far logged 170,000 incoming attempts to send me the SoBig.F worm. The rate recently peaked near 14,000 per hour. All came to a single email address that
I retired several years ago.
Why? Because I wrote a particular piece of open-source software.
See www.ka9q.net/worm for the gory details. There are some interesting plots at the end.
I can't believe how many of my fellow hams fail to appreciate the danger in this kind of post-crisis breastbeating. If the cell phone networks were overloaded while the ham channels were not, then the obvious solution (to anyone but a ham) is to take some of that underutilized ham spectrum and give it to the needy cellular networks!
The simple sad fact is that ham radio is now virtually irrelevant in emergency communications and other direct public service activities. While the non-ham world has embraced analog and digital cell phones, FRS, 802.11, LEO and GEO satellite terminals and the Internet, most of ham radio is still stuck on methods that predate World War 2. And many hams seem perversely proud of it!
The only remaining reason for ham radio to continue to exist (and it's a really important one) is for the utterly unique educational opportunities it provides. Where else can you, as an individual, design your own antennas, build your own radios, conduct propagation experiments,
experiment with your own modulation schemes, or participate in the design, construction and operation of a spacecraft? Ham radio has launched many
people into productive technical careers, and that has always been its biggest
payoff.
What kind of volume do you consider "large"? Just how many key bits do you need to generate per second? I just checked the speed of the hardware random bit generator in my Pentium 4 system, and it emits about 13.5 kilobits/sec. That's over a hundred fresh 128-bit symmetric cipher keys per second. I run a daemon (rngd) that continually feeds the output of this hardware generator into the Linux/dev/random kernel driver, where they are pooled with the entropy from other external random events like keystrokes, precise clock times of interrupts, etc.
That driver will, via the alternate entry point/dev/urandom, generate "practically" random bits at even higher speeds. In practice, these bits are just as good as the "truly random" hardware bits unless you can manage to invert the MD5 or SHA-1 one-way hash functions. The other threats to my system, such as software bugs or lack of perfect physical access controls, seem far more significant than this one.
The reason for my original comment is that this project, while cute, helps perpetuate the common misconception that elaborate, nonstandard hardware is needed to do strong encryption on a PC. That's just not the case. I'd hate for someone to say "I can't get that hardware, so I might as well not bother encrypting".
My point is simple: many modern commodity PCs already contain hardware that is specifically designed to produce a fast, high-quality stream of random bits for cryptographic purposes. Even if the Intel 810 random number generator is not available on your system, you still probably have a sound interface that you can use that will produce, through the/dev/[u]random driver, a stream of enough high quality random bits for all but perhaps a very high end secure server.
Generating random bits with a lava lamp has always seemed like silly, impractical overkill to me. For years, the Linux kernel has had the/dev/random driver that distills entropy from external events, and now it can be seeded by the hardware random bit generators found in many modern CPUs.
Nearly every PC also has a sound interface that could also be used as a rich source of random seed bits. You don't even need a microphone; just crank up the gain and digitize the analog noise in the microphone preamp.
This is hardly an "anomaly", nor is it the fault of CSMA/CA (note: not CSMA/CD). The problem is inherent in the physics of the situation, and it's well known to radio network designers.
The problem will occur in any shared multiple-access radio network when users are at different distances from the base station. Those far away from the base station use spectrum less efficiently than those close to the base station because they're forced to put more RF energy into each data bit to close the link.
The same thing happens in 1xEV-DO. As in 802.11, a wide range of data rates is available to adapt to varying channel conditions, and the lower data rates use the channel less efficiently.
Digital radio designers work hard to make their modulation, coding and multiple access techniques as efficient and adaptive as possible. But at some point, you have no alternative but to add more base stations so that each need serve only a reasonable number of users.
Does it imply, that faster SAT spinning, more energy it extracts?
For slow (nonrelativistic) satellite rotation speeds, the torque from solar photon pressure is constant. Since mechanical power is the product of torque times rotational speed, then yes; the power extracted from incident sunlight does increase as the satellite spins faster.
The same thing happens when photons strike a solar sail moving in a straight line. If the sail is held at rest with respect to the sun, then the reflected photons have the same energy (and wavelength) as those incident on the sail, and no energy is transferred from the photons to the sail. But if the sail is moving away from the sun, the reflected photons are red-shifted to reflect the work done on the sail.
This all comes from the definition of work: force through a distance. Applying a force to a stationary object doesn't do any work; force on a moving object does.
If the sail is moving away from the sun at a significant fraction of the speed of light, then the photons will be significantly red-shifted before they hit, and the power applied to the sail will be reduced by this factor. At the speed of light, the photons will be red-shifted to zero and no power will be transferred.
I suppose this means there is an optimal sail speed, greater than 0 and less than c, that maximizes the power transferred to it by photon pressure.
You are correct that there is noticeable atmospheric drag at 450km, but that's a pretty low altitude for a satellite. Only manned missions fly that low, or lower, to minimize radiation exposure and to maximize payload (manned missions tend to be big and expensive).
Atmospheric density drops off very quickly with altitude. Go over 1000km, and we're talking orbital lifetimes of many hundreds of years or more.
Here's the letter I wrote to the editor of New Scientist when I first heard of Gold's article:
Tommy Gold and others quoted in the article about solar sails really
should consult some real spacecraft engineers. For us, solar
radiation pressure is an everyday reality. Solar radiation pressure
is a major perturbing force on GPS satellite orbits, for example.
AMSAT, a group of radio hams that builds its own satellites, has for
decades used radiation pressure to impart slow spins to its satellites
with "blade turnstile" antennas. Paint one side of each blade black and the other white, and the spacecraft slowly spins like a Crooke radiometer -- but in the opposite direction, away from the white surface.
A Crooke radiometer is a very different beast. The glass bulb is not
evactuated, so thermal heating on the black side of the vanes heats
and expands air, pushing the vane away from the black surface. This
force overwhelms the much smaller photon pressure, but in the vacuum
of space only the radiation pressure exists.
Gold's thermodynamic argument is silly and wrong. A solar sail is not
a heat engine, so the second law doesn't apply. The first law (energy
conservation) does apply in a very simple way: the photons reflecting
off the sail are red-shifted by the sail's motion, removing energy
from the photons and imparting it to the sail by accelerating it.
Oh, another thing helping the crunch at the DSN is the end of the Galileo mission. When the X-band high gain antenna failed to deploy, the S-band omni antenna was used to salvage the mission.
This placed an enormous strain on the DSN's resources. The very low data rate required more tracking time to transfer a given amount of information, and multiple antennas at each site were often arrayed to increase the received signal. The end of Galileo frees these antennas for other missions.
I visited the Canberra DSN site in September 1997. While I was there, Jupiter rose and most of the antennas at the site were pointed at it. Very impressive to see them all moving together.
It's not so hard. Each mission is on a separate frequency, so you just add extra receivers to share each ground antenna. Even the largest DSN antennas have beamwidths wide enough to take in all of Mars plus the nearby orbital space. (A 64m dish has a beamwidth of about 144 arc-seconds at X-band, while Mars as seen from Earth is currently about 20 arc-seconds in diameter.)
Also remember that Spirit and Opportunity are going to opposite sides of the planet, so generally only one will use the DSN at a time.
Well, sort of. Many AMSAT (amateur radio) satellites have this facility, and it has proven to be very useful.
However, it can also tempt those involved to think that software is somehow less important than hardware, since the hardware has to be at the launch pad on time while the software can always be sent up later. Then, when the software is finally sent up after launch, it hasn't always undergone as much testing as it would have had it been written well before launch.
It takes time to properly test spacecraft software, not because the programs are CPU-intensive (they can't be) but because there are so many special situations for the human authors to consider. Take the Ariane 501 launch failure; the test that proved a software bug in the intertial reference platform took only a matter of seconds to execute, but no one thought to create and run that particular test until after the vehicle had already exploded.
Galileo did. Remember the entry probe? It separated from the main orbiter some time before orbit insertion and made a direct entry to the Jupiter atmosphere. It worked.
No, it didn't "land" on the planet since that's impossible, but the project still had some real technical hurdles to overcome. It was the fastest atmospheric entry by any artificial object, and as we saw with Columbia this sort of thing is never completely routine.
There were also several successful landings on Venus by both Russia and the US, plus a very successful pair of Russian balloons deployed in the Venusian atmosphere. The landers didn't survive long, but that was expected given the extreme conditions on the surface. But they did make it, and I still consider that an incredible achievement.
So how do you explain the significantly higher success rates to planets other than Mars, e.g., Venus and Jupiter? They share the same problems of long delay times and the need for autonomous control.
Your comment about manned vs unmanned makes absolutely no sense. One could buy a hundred or a thousand unmanned planetary missions for what a single manned mission would cost, and there would still be no guarantee that the manned mission would succeed. Yet we could easily afford to have many of those unmanned missions fail.
I say that the manned space program is one of the major contributing factors to the poor Mars success rate. More specifically, the enormous sums of money that the Shuttle and ISS have siphoned from the far more productive unmanned planetary program and flushed down the drain.
I think one of the factors contributing to the poor Mars success rate is orbital mechanics. The launch window to Mars opens for only a month or so every two years. This is the longest interval between window openings for launches from Earth to any other planet; windows to the other planets open at roughly yearly intervals or less. Since missing the launch window means waiting another two years, this undoubtedly creates enormous schedule pressures on any team preparing a spacecraft for launch to Mars.
Thanks for the info. So if I load SIP into a Cisco phone, I can use it with open source servers, or with no servers at all? I don't have to buy any expensive boxes from Cisco? If so, that's a Very Good Thing.
Slashdot Mirror
I already run an outbound server on a IP address block that isn't in the residential ghetto. I shouldn't have to do that, since I'm quite able to run the same server at home, and relaying through another box just decreases reliability and increases costs and network loading. And it's all so unnecessary.
Uh, because that "private company" is digging up a public road?
Any company that own wires in the street should be regulated as a common carrier. That means in exchange for access to public rights of way, they're required to accept and carry any (legal) traffic to any destination without discrimination as long as the customer pays his bills.
I consider it a major scandal that the owners of wires used to provide broadband access have so far escaped regulation as common carriers.
Fortunately, there exists technology with which we users can fight back: encrypted tunnels. A carrier can't discriminate among different kinds of traffic if it all looks like meaningless random bits to him.
All through the 1990s we fought the "crypto wars" thinking that the government was our primary enemy. It still is a significant threat especially now, in the post 9/11 Bush/Ashcroft era. But it may turn out that the single most important role of widespread encryption will be to enforce the end-to-end model and to kick the telecom carriers back down into their proper role as dumb, transparent bit pipe providers.
Everyone wants to block spam. I'm no exception. But we want it done right. We don't want our real mail blocked because some ISP has arbitrarily classified it as spam by its own inscrutable, unchangeable, blunt criteria. Give me, the end user, the best mechanisms available to tell you, my ISP, exactly what I consider to be spam so you can filter it for me.
This can be as simple as a Bayesian classifier on the server that diverts spam into a separate IMAP folder with its own disk quota and expiration interval. As long as I have the ability to periodically scan the junk folder for false positives and retrain the Bayesian classifier as necessary, I think I'll be happy. I'm already doing exactly this on the mail servers I run for myself, and it works extremely well.
I'd even be willing to let the ISP block mail traffic at the IP level as long as the users have the opportunity to override it. So instead of just dropping all packets from a given IP address, the SMTP server allows the transfer to proceed until all the recipients are given. If all of the message recipients have previously agreed to block the IP address in question, then the transfer can be terminated at that point without transferring the message body. This could be done by answering the DATA command with a permanent error code, or just resetting the TCP connection. Otherwise the message is accepted and delivered only to those that haven't requested that it be blocked.
An obvious optimization is possible when all the users on the system have unanimously agreed to block a given IP address. Then, and only then, can the SMTP connection be blocked before it starts. Note that these "agreements" need not be explicit; they could default to, say, the MAPS RBL as long as I can individually opt out of any or all of its entries.
My main point is that even when ISP filtering is necessary for performance reasons it is both necessary and quite feasible to leave the ultimate control over these mechanisms in the hands of the end users. And then everyone will be happy. Except the spammers.
I agree that can avoid heavy-handed filtering at your own ISP's mail server. But what about everybody else's ISP, all those that block my mail to them because I'm coming from an improperly blacklisted IP address? Can I reasonably make everyone else switch ISPs?
Client-side filtering does not need to destroy false positives. Nothing keeps a mail filter on a client from generating delivery failure messages just like those produced by a MTA. Of course, I don't know why you'd want to generate such messages in response to every spam and email worm. Besides, there's no real way to know that any message was actually read by its intended recipient (instead of silently ignored) other than for the recipient to manually reply and say so. This is just the end-to-end principle applied to email.
Nothing in client-side filtering inherently prevents you from aggregating useful information about spam. I perform my own spam filtering, and I forward all my spam to spamcop where it is aggregated with spam reports from many other users. In fact, they get better quality reports from me because I manually review the stuff in my spam folder to make sure it really is spam before I report it. (I don't really have to do that since annoyance-filter, my Bayesian spam detector of choice, has an extremely low false positive rate.)
Your one good point is about resource wastage. And I'd have no problem with a mechanism that allows users to delegate spam filtering functions to their ISPs provided that the users retain ultimate control.
The problem is that such control is almost totally lacking in today's ISP spam filtering mechanisms. Filtering is usually imposed (along with IP blacklists) by heavy-handed ISP fiat, and the users get no say over what is or isn't considered spam. If you're lucky, your ISP won't automatically drop what they consider to be spam, but will simply mark it with a header or place it in a separate IMAP folder. But you will probably have no control over their determination except to ignore it and replace it with your own.
Although most of us would probably agree on what is and isn't spam in the majority of cases, ultimately spam is in the eye of the beholder. There can be no justification for withholding email from someone who really wants to receive it, and no justification (other than ISP laziness) for not giving their users ultimate control over all filtering mechanisms.
An obvious implication of your excellent rules for ISP-level spam blocking is that IP-level blacklisting is simply unacceptable. There's no way for an individual user to turn the block off, or to even see the blocked mail since it is never sent. People frequently complain about "false positives" in spam-detection packages, but IP-level blacklisting is the real cause of most false positives.
That said, I do believe there is a place for ISP packet and email filters provided that they're under the control of the individual end user to which the traffic is directed. This is in keeping with the end-to-end principle that there is a proper role for placing certain functions within a network as a performance enhancement. In this case, the ISP can improve performance by dropping traffic that the end user would drop anyway.
This is one of the many reasons I run my own incoming SMTP server and my own virus and spam blockers. I control them, not the morons who happen to own the only broadband pipes in town.
It's easy for you to talk about "invisible hands". What if the overly zealous ISP also happens to own the only broadband pipe that runs past your house?
Not really. There seem to be a zillion message formats, each in a half-zillion languages. It's a real pain in the ass to filter them all out.
Why? Because I wrote a particular piece of open-source software.
See www.ka9q.net/worm for the gory details. There are some interesting plots at the end.
The simple sad fact is that ham radio is now virtually irrelevant in emergency communications and other direct public service activities. While the non-ham world has embraced analog and digital cell phones, FRS, 802.11, LEO and GEO satellite terminals and the Internet, most of ham radio is still stuck on methods that predate World War 2. And many hams seem perversely proud of it!
The only remaining reason for ham radio to continue to exist (and it's a really important one) is for the utterly unique educational opportunities it provides. Where else can you, as an individual, design your own antennas, build your own radios, conduct propagation experiments, experiment with your own modulation schemes, or participate in the design, construction and operation of a spacecraft? Ham radio has launched many people into productive technical careers, and that has always been its biggest payoff.
That driver will, via the alternate entry point /dev/urandom, generate "practically" random bits at even higher speeds. In practice, these bits are just as good as the "truly random" hardware bits unless you can manage to invert the MD5 or SHA-1 one-way hash functions. The other threats to my system, such as software bugs or lack of perfect physical access controls, seem far more significant than this one.
The reason for my original comment is that this project, while cute, helps perpetuate the common misconception that elaborate, nonstandard hardware is needed to do strong encryption on a PC. That's just not the case. I'd hate for someone to say "I can't get that hardware, so I might as well not bother encrypting".
My point is simple: many modern commodity PCs already contain hardware that is specifically designed to produce a fast, high-quality stream of random bits for cryptographic purposes. Even if the Intel 810 random number generator is not available on your system, you still probably have a sound interface that you can use that will produce, through the /dev/[u]random driver, a stream of enough high quality random bits for all but perhaps a very high end secure server.
Nearly every PC also has a sound interface that could also be used as a rich source of random seed bits. You don't even need a microphone; just crank up the gain and digitize the analog noise in the microphone preamp.
The problem will occur in any shared multiple-access radio network when users are at different distances from the base station. Those far away from the base station use spectrum less efficiently than those close to the base station because they're forced to put more RF energy into each data bit to close the link.
The same thing happens in 1xEV-DO. As in 802.11, a wide range of data rates is available to adapt to varying channel conditions, and the lower data rates use the channel less efficiently.
Digital radio designers work hard to make their modulation, coding and multiple access techniques as efficient and adaptive as possible. But at some point, you have no alternative but to add more base stations so that each need serve only a reasonable number of users.
The same thing happens when photons strike a solar sail moving in a straight line. If the sail is held at rest with respect to the sun, then the reflected photons have the same energy (and wavelength) as those incident on the sail, and no energy is transferred from the photons to the sail. But if the sail is moving away from the sun, the reflected photons are red-shifted to reflect the work done on the sail.
This all comes from the definition of work: force through a distance. Applying a force to a stationary object doesn't do any work; force on a moving object does.
If the sail is moving away from the sun at a significant fraction of the speed of light, then the photons will be significantly red-shifted before they hit, and the power applied to the sail will be reduced by this factor. At the speed of light, the photons will be red-shifted to zero and no power will be transferred.
I suppose this means there is an optimal sail speed, greater than 0 and less than c, that maximizes the power transferred to it by photon pressure.
Atmospheric density drops off very quickly with altitude. Go over 1000km, and we're talking orbital lifetimes of many hundreds of years or more.
Tommy Gold and others quoted in the article about solar sails really should consult some real spacecraft engineers. For us, solar radiation pressure is an everyday reality. Solar radiation pressure is a major perturbing force on GPS satellite orbits, for example.
AMSAT, a group of radio hams that builds its own satellites, has for decades used radiation pressure to impart slow spins to its satellites with "blade turnstile" antennas. Paint one side of each blade black and the other white, and the spacecraft slowly spins like a Crooke radiometer -- but in the opposite direction, away from the white surface.
A Crooke radiometer is a very different beast. The glass bulb is not evactuated, so thermal heating on the black side of the vanes heats and expands air, pushing the vane away from the black surface. This force overwhelms the much smaller photon pressure, but in the vacuum of space only the radiation pressure exists.
Gold's thermodynamic argument is silly and wrong. A solar sail is not a heat engine, so the second law doesn't apply. The first law (energy conservation) does apply in a very simple way: the photons reflecting off the sail are red-shifted by the sail's motion, removing energy from the photons and imparting it to the sail by accelerating it.
This placed an enormous strain on the DSN's resources. The very low data rate required more tracking time to transfer a given amount of information, and multiple antennas at each site were often arrayed to increase the received signal. The end of Galileo frees these antennas for other missions.
I visited the Canberra DSN site in September 1997. While I was there, Jupiter rose and most of the antennas at the site were pointed at it. Very impressive to see them all moving together.
Also remember that Spirit and Opportunity are going to opposite sides of the planet, so generally only one will use the DSN at a time.
However, it can also tempt those involved to think that software is somehow less important than hardware, since the hardware has to be at the launch pad on time while the software can always be sent up later. Then, when the software is finally sent up after launch, it hasn't always undergone as much testing as it would have had it been written well before launch.
It takes time to properly test spacecraft software, not because the programs are CPU-intensive (they can't be) but because there are so many special situations for the human authors to consider. Take the Ariane 501 launch failure; the test that proved a software bug in the intertial reference platform took only a matter of seconds to execute, but no one thought to create and run that particular test until after the vehicle had already exploded.
No, it didn't "land" on the planet since that's impossible, but the project still had some real technical hurdles to overcome. It was the fastest atmospheric entry by any artificial object, and as we saw with Columbia this sort of thing is never completely routine.
There were also several successful landings on Venus by both Russia and the US, plus a very successful pair of Russian balloons deployed in the Venusian atmosphere. The landers didn't survive long, but that was expected given the extreme conditions on the surface. But they did make it, and I still consider that an incredible achievement.
Your comment about manned vs unmanned makes absolutely no sense. One could buy a hundred or a thousand unmanned planetary missions for what a single manned mission would cost, and there would still be no guarantee that the manned mission would succeed. Yet we could easily afford to have many of those unmanned missions fail.
I say that the manned space program is one of the major contributing factors to the poor Mars success rate. More specifically, the enormous sums of money that the Shuttle and ISS have siphoned from the far more productive unmanned planetary program and flushed down the drain.
I think one of the factors contributing to the poor Mars success rate is orbital mechanics. The launch window to Mars opens for only a month or so every two years. This is the longest interval between window openings for launches from Earth to any other planet; windows to the other planets open at roughly yearly intervals or less. Since missing the launch window means waiting another two years, this undoubtedly creates enormous schedule pressures on any team preparing a spacecraft for launch to Mars.
Thanks for the info. So if I load SIP into a Cisco phone, I can use it with open source servers, or with no servers at all? I don't have to buy any expensive boxes from Cisco? If so, that's a Very Good Thing.