That links to http://www.thespacereview.com/article/2323/1 where one of the comments is:

> Like Russian vehicles, there is no flight termination system that receives ground commands onboard Chinese launch vehicles. Only US and ESA launch sites have such a system. Correction, Falcon 1 did not have such a system for launching on Kwaj.

All rockets launched in the US have to have one, though :-)

Indeed, all it does is break up the rocket. Depending on when it happens during the launch we might still end up with a fireball near the ground (unlikely to be near anything inhabited, though, as there's a lot of free space around launch sites) or with a quickly disintegrating rocket because it's already at high speeds.

There will still be debris, of course, but I guess the reasoning is that it's preferable to have relatively small debris, than one large piece of exploding debris.

Very often. Air Force range safety guidelines require a million dollar flight termination system and most of that cost is testing and quality control. I don't have an authoritative list of all flight terminations but it happens at least once every few years whenever a rocket fails to follow the set flight path.

There were no self-destruct systems on the shuttle orbiter, though there were on the solid rocket boosters and external fuel tank. They were used only once, on the Space Shuttle Challenger after the orbiter broke up, but the SRB's were still burning in an uncontrolled manner.

Don't worry, unlike the space shuttle, rockets have escape mechanisms. In that specific case, the astronauts would probably have survived as the emergency rocket thingies would have fired and evacuated them far from the explosion before it could reach the capsule.

"Over-reliance on unit testing"? I have a somewhat different read from the inquiry board report, which says it was a "systematic software design error." Yes, inadequate testing, and a belief the working code for Ariane 4 meant it was validated for Ariane 5 were certainly contributory, but I think it's unfair to single out an over-reliance on unit testing.

The board argues that there was a bias towards believing the software does not have an error. Thus, any out-of-range value is interpreted as a hardware error, which means the CPU should shut down.

There was a decision to not include Ariane 5 trajectory data in the SRI requirements and specification. Thus, while tests were rigorous at the equipment ("unit") level, and there were system tests, they didn't test that case. This is test design failure.

In addition, the board says "the review process was a contributory factor in the failure."

I can see how those can be aspects of "over-reliance on unit testing", but it doesn't explain, for example, how some of the variables from Ariane 4 were protected from overflow exceptions but others were not.

Oops, yeah I recalled that the subsystem that caused the problem didn't need to run after launch, so I was thinking it fed incorrect data to the auto-destruct system, not that it actually went off course.