Debug your Code, or Else! 486
Trevor Lovett writes "I ran across a collection of famous software bugs that have caused large scale disasters including the explosion of the Ariane 5 rocket due to integer overflow and the misfiring of a US Patriot missile that caused 28 deaths because of accumulated floating point error. "
but dont forget (Score:5, Funny)
Re:but dont forget (Score:2, Redundant)
Missing From The List (Score:5, Funny)
2) 2000 - Poorly coded garbage collection causes Word 97 to crash, lose last 2 hours of research paper. Class was in 30 minutes, paper was late. I lost my scholarship.
3) 2002 - IE Crashes while writing AWESOME first post for /., My karma never recovered.
Re:Missing From The List (Score:3, Funny)
Also Missing: (Score:2)
What other piece of buggy software in history ever caused as much widespread collective apoplexy? :)
Re:Missing From The List (Score:5, Funny)
Re:Missing From The List (Score:5, Funny)
Yes. It collects megabytes of garbage in files with the extension ".DOC".
Re:To shrink word files (Score:2)
1. Create your document.
2. Save as RTF.
3. Open the RTF in Wordpad and immediately save the file.
For some reason, Wordpad saves RTF files smaller than Word does. Go figure.
Looking over the list (Score:3, Interesting)
Re:Looking over the list (Score:2)
Re:Just a matter of time and growth (Score:2, Insightful)
You write a program that designs a building that suddenly collapses, but since you copyrighted your program, and patented the logic, I will make the same mistake, since I can't learn from your mistakes.
People will "learn from other's mistakes" less and less, as more and more become trade secrets, and suits get settled, etc.
Re:Just a matter of time and growth (Score:2, Funny)
NO! It is called responsibility. (Score:3, Interesting)
Half of it boils down to, We are not responsible for anything bad, even if we were warned about it and have a fix for it that we are holding on to sell as part of an upgrade.
Re:Looking over the list (Score:2)
Homer Simpson?
Millennium Bridge (Score:4, Interesting)
Re:Millennium Bridge (Score:2, Funny)
Pedestrians were also asked not to sway anymore.
Re:Millennium Bridge (Score:2)
Actually the phenomenon of resonance is well documented in science. Engineering involves disgarding the pieces of science that are unimportant. For example, most of quantum theory can be ignored when modelling a bridge, which simplifies things a bit. In the case of the millenium bridge, they oversimplified, and ignored the horizontal force exerted by people walking, which is what caused the swaying. So this is not science, not software, just an engineering error.
not_cub
Re:Millennium Bridge - Kansas City skywalk (Score:5, Interesting)
Armys break cadence when marching across bridges, at least as far back as Napoleon's time. Presumably they learned that the hard way.
On a more personal note, I have participated in the unintentional destruction of a gymnasium. 80 or so people crowded together in the middle, bouncing up and down, and then "down and down". We fractured the engineered wooden joists. Fortunately it failed gracefully. Just sagged down about 4 feet in the middle.
What I'm trying to say, not particularly directly, is "don't give the designers of the bridge a pass because this new phenomenon struct their bridge". Chastise them for risking people's lives and wasting resources by neglecting the loads placed on bridges.
Re:Millennium Bridge - Kansas City skywalk (Score:2, Informative)
They did take into account pedestrian movement on the bridge; they didnt take into account pedestrian motion on the bridge locking in to the motion of the bridge:
1) Pedestrians walk on bridge
2) Bridge wobbles slightly
3) Pedestrians adjust their walking to be in phase with bridge
4) Bridge wobbles more
This was a new phenomenon, due to the lightness of the construction of the bridge. It is now fixed, by the addition of dampers.
Re:Millennium Bridge - Kansas City skywalk (Score:5, Funny)
1) put project managers, lead architects and engineers under the bridge;
2) put heavy loaded trucks on the bridge.
That was real extreme testing.
Re:Millennium Bridge - Kansas City skywalk (Score:3)
2. They designed a failed bridge, and you want them to design the new one?
3. These are cheap when you have hundreds of millions of slaves.
Re:Millennium Bridge - Kansas City skywalk (Score:2, Informative)
The Hyatt's skywalk collapsed soley because of the change in design. The design change caused the walkway to fail to meet building code [unl.edu]. Some civil engineers who studied the disaster were surprised it could support its own weight, much less the weight of the pedestrians.
Quoting from a Kansas City Star article [kcstar.com].
The dancing people were by and large on the floor below the skywalk, participating in a dance contest.
The mistake that caused the Hyatt disaster was not one of failing to consider human motion in the design, but failing to consider the effects of seemingly minor changes in design.
Re:Millennium Bridge (Score:2)
This looks like it could turn into one of those really annoying semantic arguments. But what the hell.
I don't consider flaws in mathematical models to be bugs; models, after all, simulate reality; this is something they can never do perfectly. Therefore all models are flawed. Are they all buggy? I'd contend that they aren't. Any model is continually in a state of refinement. When something that never occured to you actually happens, you include it. Until that unanticipated phenomenon happens, it's unreasonable to expect its inclusion.
You could maintain that the model was buggy because it didn't predict the swaying. I don't think that this is the case, however; the model was complete as far as the state of the art at the time was concerned. That state of the art has since moved on; any models that now fail to take the new phenomenon into account may be described as buggy, but I still prefer 'incomplete'.
something bad from an unexpected input is a bug. (Score:2, Insightful)
Problems often come up in programing for input. Normally you have an expected range of input, and if your program works at all and the input is in the expected range you get the expected output. BUT what if the use enters the ABSOLUTE maximum value, is your variable size large enough? what about the absolute min, often zero, does it still work right. Your not going to try and divide by that zero or something that will fail. What if a negative number is entered.
Those are all basic unput checking questions...but its the general idea. Bullet proof your code, or at least try to make it so.
speaks more to TESTING (Score:5, Insightful)
Software engineers simply cannot be trusted to do more than small unit level testing! We get into a pattern of behavior, we know what to expect, and simply do not stress test the system.
Thats why I like hiring sales people and 2-year olds to test my code at the unit/integration level.
Re:speaks more to TESTING (Score:3, Informative)
Others would argue that testing alone may not suffice. Particularly for these kinds of mission critical applications, nothing short of formal methods of software engineering [sbu.ac.uk] will suffice. Formal as opposed to natural language specifications can reduce ambiguity. Safety conditions can then be derived and verified through rigourous mathematical proofs.
Of course none of this obviates the need for testing but it can lead to a more predictable system.
Re:speaks more to TESTING (Score:5, Funny)
Thats why I like hiring sales people and 2-year olds to test my code at the unit/integration level
You didn't need to repeat yourself
Re:speaks more to TESTING (Score:5, Funny)
Re:speaks more to TESTING (Score:4, Insightful)
Not in important fields like telecom. In those fields you live and die by testing, and you can be held accountable for bugs found in your code. If there are too many, you might be in for it.
What's shocking to me is that almost no open source authors or advocates give a hoot about automated testing of any kind. The only free software I've found with a test suite is gcc. As much as I hate to say it, there's a good chance that the relative inexperience of most open source authors is a factor here.
Lots of testing in source installs (Score:2)
I always run these.
I had a job writing regression tests. I have not looked into any of these install tests. I doubt they are as thorough as they could be, but they have failed once in a while, and I have always investigated the failures.
Re:speaks more to TESTING (Score:5, Informative)
What's shocking to me is that almost no open source authors or advocates give a hoot about automated testing of any kind. The only free software I've found with a test suite is gcc. As much as I hate to say it, there's a good chance that the relative inexperience of most open source authors is a factor here.
Perl is really good about this. The Test::Harness [uwinnipeg.ca] and Test::More [uwinnipeg.ca] modules make it very easy to write test suites, so CPAN modules have lots of automated tests. It might even be a requirement to get a module into CPAN; I'm not sure.
PostgreSQL has regression tests.
There's a really nice test environment for Java code called JUnit [junit.org]. Lots of stuff is using it. Lots of articles about how to write effective tests. There's a project [mockobjects.org] to develop mock versions of common objects (servlet requests, SQL queries) that fail in interesting, predefined ways. I'm using a C++ workalike called CppUnit [sourceforge.net] in one of my projects.
The Boost [boost.org] code has automated testing.
There's a project called qmtest [codesourcery.com].
The Wine people have recently started using regression tests.
Re:speaks more to TESTING (Score:3, Insightful)
Bullshit [junit.org]
another bug page (Score:5, Insightful)
Hi-tech toilet swallows woman (Score:5, Funny)
Pain & Suffering caused by fatal VxD errors an (Score:2, Redundant)
Pentium bug in perspective (Score:5, Informative)
The pentium bug is certainly famous because every idiot and its brother think it is rare for a CPU to be buggy. The second condition in the list is "caused a large scale disaster". This condition is, sadly, also met. It caused a large scale public relations disaster for Intel because once again said idiots thought that a CPU bug is rare.
Re:Pentium bug in perspective (Score:3, Informative)
What is exceptional is that instead of just announcing a new erratum (which is what Intel and most cpu makers normally do in such a case), Intel tried to bury the problem, initially denying that it existed and then denying that anyone would ever run into the problem. This really pissed off the numerical computing community and destroyed confidence in the accuracy of intel's floating point unit. That's why it was a public relations fiasco.
see:
One that we did - killing long distance nighty (Score:5, Interesting)
I wrote the algorithm that scheduled the dialins. It used a pseudo-random approach during the day, weighted by outstanding traffic.
But at night, there was period during which we had to unload all messages before the next day's processing. During this time, the pseudo-random algorithm was replaced by a deterministic one that assigned computers time slots.
The computers also had auto-rety in the case of failure, so each call could result in several if it were blocked.
Unfortunately, during coding I had put in the number of modems answering phones at 20 (as an arbitrary number for testing). During the hectic rollout, this never was changed to the actual number which was much smaller.
Once the system came on line, every night at 1AM portions of Omaha (which included lots of call centers) would lose all long distance service for a couple of hours, as all these computers called in and retried several times.
Eventually the phone company figured it out and contacted us, and we discovered and corrected the discrepancy.
Another issue was that we had a number of hotels that were using pulse dialing (this was a long time ago in a galaxy far far away). Sometimes these would be off by one due to the inherent unreliability of pulse dialing, and the result was a lot of calls to certain numbers related to the 800 number, all in the middle of the night.
BTW... as far as I know, this was the first large widely distributed commercial computing system to use switched telephone circuits for communications (but no doubt some other grey-haired slashdotter knows of another).
Re:One that we did - killing long distance nighty (Score:3, Interesting)
One night our system vanished from the web. Our clients couldn't connect, the website was gone, and we couldn't ssh in. Later on we found out what happened. As more and more clients auto-updated to the new version they began pinging the server to alert it to its presence. It in turn responded, and soon it was doing nothing but sending and receiving pings. To over 700 computers. As fast as it could.
Somewhere between 700-800 clients the router died, bringing with it the internet connection to the entire engineering school. Somehow we were never disciplined and everything was brought back online within the next day or so. Now that's something to put on a resume: Effectively launched a 700+ system DDoS on own university. Now remember kids, make sure you trust the company that makes your P2P software!
Re:One that we did - killing long distance nighty (Score:3, Informative)
links (Score:2)
Re:links (Score:3, Funny)
<officer> Don't worry, it's one of ours.
<private> But sir, it's still going to HIT us!
This not only sounds like something that belongs in a Dilbert strip, but also the basis for the logic that allows the spreading of all these e-mail viruses.
My prof at Georgia Tech stressed this a lot (Score:5, Informative)
In Fatal Defects: Chasing Killer Computer Bugs, Ivars Peterson describes dozens and dozens of hoary computer bugs and gives biographical sketches of the bug detectives who located and fixed them. This book, which reads like a novel, is both entertaining and informative. Many of the bugs that Peterson discusses are not in computer programs per se but in the human systems that run and operate the computers. Very often the operator fails to understand what the computer program requires as input and types in an incorrect command. The computer then executes the command, with potentially disastrous results. Fatal Defects has important lessons for both those who design computers and those who use them.
He also insisted that we not call them bugs. "They are ERRORS, calling them bugs makes it sound like they are cute little accidental things that pop up when actually they are programming mistakes."
Re:My prof at Georgia Tech stressed this a lot (Score:2)
Read comp.risks (Score:5, Informative)
--Jim
Happy to hear it... (Score:3, Insightful)
In electronics, if your hardware has ONE little problem, it's almost bankruptcy time. Remember the Pentium FP bug? And how it would have affected very little? Remember the hoopla, people wanted new processors, etc..
But software bugs? Who cares! It's NORMAL, it's EXPECTED. Well, geeks and nerds, time to get your asses in gear and live up to the same standards mechanical and electrical engineers have been living up to for decades.
I'm tired of being held to a standard of perfection that the software people (who make more money than me!) don't even KNOW about.
Re:Happy to hear it... (Score:5, Interesting)
With software, most programmers are writing code to run on systems (kernels, runtime libraries, and the like) that are usually proprietary. The inner details are not just neglected; the companies intentionally keep them secret and prosecute people who leak them.
As a result, software can't be made reliable, not even in principle.
We do have a few exceptions, e.g. linux and all the GNU stuff. If *everything* underneath your code is Open Source, then in principle you can examine it and find problems. (It ain't easy, but at least it's doable if your employer will permit the time that it takes).
But we're facing a major battle just getting Open Source software accepted by a tiny part of the market. In most jobs, you are required to write code for systems whose inner working you are not permitted to know.
The US government is even using proprietary, binary-only computer systems in secure and mission-critical situations. Anyone who expects the code in such situations to be reliable is either utterly ignorant or actively malicious.
Myself; I'd welcome rules that make me and other software developers responsible for bugs in our code. If there were such a legal requirement, I could point to it when someone denies me access to the information that I need, and say "I can't possibly write correct code when you are keeping vital information from me. Show me the inner details of these parts of the system, and I'll agree to write reliable code for it."
Of course, in a couple of cases, when I've gotten my hands on such details, I've proceeded to write a proof that certain things could not be done reliably on that system. "Fix that bug in that library, and I'll vouch for my code. Until then, here's my bug report describing exactly how it will fail."
Unfortunately, when I've done this, the usual result was that I was looking for another job soon thereafter.
(One such lost job was when I proved that certain sensors in a nuclear power plant could not be made to work reliably due to their software. But that was 20 years ago; maybe they've fixed it by now.
GPL (Score:2, Insightful)
See..none of its caused by Code written in VB (Score:2, Funny)
Damn, they never get to do fun stuff like this.
Re:See..none of its caused by Code written in VB (Score:3, Funny)
I can relate (Score:2, Funny)
Debugging (Score:2)
I personally see debugging is the art of making sure the code works and is fulfilling the logical expectations of the programmer.
These problems show that there is a need to go way beyond traditional debugging, and do aggressive testing outside the programmer's box. Debugging ain't enough. Those dregs toiling away in the testing department might be worth their skin afterall.
kd [slashdot.org]
Phoenix (Score:2, Interesting)
It delayed the re-opening of the airport for about seven months or so. After it did finally open the system wasn't working yet so the baggage system had to be operated manually for a couple of months.
Worst I've seen in my work (Score:2, Funny)
Slashdot bug (Score:2)
Does Slashdot want me to just waste more time at work or what?!
The buggs that didn't happen (Score:5, Funny)
"OK to delete database"
When I caught that one I had visions of a user who had his/her million dollar database deleted charging into our office with a shotgun and
Reminds me of mine... (Score:4, Funny)
---
All comments are not factual unless stated otherwise.
Many of these are NOT bugs... (Score:2, Interesting)
If I misestimate the mass of a planet, is that a software bug?
If my software sells stock when a certain threshold is hit and yours does the same, and that least do a financial industry meltdown, did my software not work as planned, or is the issue more the dynamics of the market being somewhat unpredictable?
The tacoma narrows and london milennium bridges are both listed here, yet neither one is a software issue - hell the tacoma bridge collapsed in 1940!
That said, it is a pretty interesting list, but calling it a list of software bugs and using it to underscore the importance of regression testing software is a bit of a stretch. If anything, it underscores the importance of editing and proofreading your content.
Software bugs...NOT! (Score:5, Insightful)
The bug that caused Airane explosion was a requirements analysis bug. The Pentium FP bug was a hardware bug.
A quick skim of the rest nets me at least 6 more non-software software bugs
After seeing that, I can't really trust the list on things I don't have a good knowledge about.
Here's a challenge for someone: Go through the list and find out how many (if any) of the listed software bugs are actually software bugs.
Software bugs...YES! (Score:2)
The Pentium bug, I'll agree with. Florida voting, I'll agree with. DDOS is software bug. Software run in an environment like the web has to accomodate malicious users. Wall Street Crash, software bug. There was a set of conditions in which the software did bad things.
Patriot and Scud (Score:3, Interesting)
Considering that even the military now admits that no Patriot *ever* intercepted an Iraqi scud, this inference is unfounded.
Re:Patriot and Scud (Score:2)
Whether is a direct consequence of the bug is debatable. But it would maybe have hit its target if that bug had not been present and not slammed into the ground on the wrong side of the front-line.
Re:Patriot and Scud (Score:2)
What was going on in this case was that the launching system had a minor but cumulative rounding error in its time measuring.
What's interesting is that this isn't a bug. The system in question was designed for a maximum duration of 48 hours between resets, and they ran it for a week.
Patriot time bug worse than represented. (Score:2)
But the bug was more fundamental: The missile and radar computers synchronized clocks when the system was booted, then drifted apart. After a hundred hours the drift from the roundoff was enough to make it lose a target.
But had the missile synchronized its clock upon launch (or better: target acquisition, to give it time to settle), the tiny roundoff error accumulated in flight wouldn't have mattered. Meanwhile, had the calculation been perfect, differential clock speeds still would have caused a drift.
Nice (Score:4, Insightful)
and goes on to say:
seven times the loss of human life, but less of a tragedy? I guess they are soldiers so fuck 'em, eh?
This story is over two years old, so they have had ample opportunity to correct it. The "comment" button on that page just takes me to the front page. Nice.
Also on that page, "The DoubleSpace automati hard disk comparision software included in Microsoft MS-DOS 6.0 [. .
Ironic that there are such glaring errors in an article about buggy software.
Well, I wasn't particularly a fan of Byte before, but now I'm convinced that they suck.
-Peter
We have a difficult battle ahead ... (Score:5, Informative)
Their result was that roughly 50% of the Fortran programs on the mainframe computer produced at least one number in the output that was wrong due to undetected integer overflow.
This itself would be bad enough. But a bunch of us followed this up by asking Fortran programmers about it. What we did specifically was to point out that, unlike floating point, where there's an interrupt, integer arithmetic required a separate instruction to test the overflow flag. So testing for integer overflow took extra cpu cycles. Then we asked them whether they thought that software should be modified to always test for integer overflow, as is done with floating point.
The answer was overwhelmingly that if it took extra cpu cycles, the software should not check for overflow.
When we pointed out that this introduced the risk of programs producing incorrect results, the Fortran programmers invariably said that didn't matter. Faster is better, even if some of the results are wrong.
I think of this whenever I read about computers used in medical, transportation, or other areas where malfunctioning software could put lives at risk.I don't believe that the "software culture" has changed significantly in this respect since then.
Re:We have a difficult battle ahead ... (Score:3, Informative)
That's precisely why people developing safety-critical apps should be (and quite often are) using Ada, rather than Fortran or C. Not only does the languge put in all the checks you mention (and more), but the "software culture" among Ada programmers is significantly better where bugs and safety are concerned.
Take a look at Praxis' SPARK [sparkada.com] for a look at how responsible people develop safety-critical software. The approach takes more effort than the typical "hack something together then bash it into shape with the debugger" approach. But in many cases, it is well worth the cost.
Bugs? Typos? (Score:2)
"Pentium Prozessor" and "Pentium Porcessors" in the writeup... [rant] This is the same kind of sloppy work that causes cars to explode, missiles to veer off course, and a busload of nuns to get blown up by a rogue robot (Nun Soup?) [/rant]
Oh well
Coupla Notes (Score:4, Informative)
So we have a specification problem and a system design problem. Neither is a pure "programming problem".
Software crashes are like airplane crashes -- blame the lowest guy on the totem pole. In air crashes, it's the pilot. In software, it's a coder.
Re:Coupla Notes (Score:2)
Any particular reason why? Is it just because the specs assume a reboot every 8-12 hours?
This one was deadly: (Score:2)
Iteration, Data Compression, 1986"
Caused wife 1.0 to go into panic and terminate all sex threads for the next three weeks.
dumbass, the patriot didnt kill anyone (Score:2)
Always works right on my system (Score:5, Funny)
I have no idea what the hell the users do to it to screw it up.
USS Vincennes Incident was NOT software related (Score:3, Informative)
Blaming a "cryptic display" is hardly a software bug if anyone is familiar with radar screens. That's why we train people to read them!
He forgot my favourite... (Score:2)
The Patriot Problem was well known (Score:2)
Computer-Related Risks by Peter G. Neumann (Score:3, Interesting)
Making Rupee!
Due to a bank error in the current exchange rate, an Australian man was able to purchase Sri Lankan rupees for (Australian) $104,500, and then to sell them to another bank the next day for $440,258. (The first banks' computer had displayed the Central Pacific franc rate in the rupee position.) Because of the circumstances surrounding the bank's error, a judge ruled that the man had acted without intended fraud, and could keep his windfall of $335,758.
Computer Related Risks - Peter G. Neumann - ACM Press - 1995
The bottom line here is "computing is, in a technical sense, a risk". Actually, technology - of any kind - is a risk. Which I suppose leads us to remember that life is a risk.
At which point, I'll just stop rambling and point you all to Amazon to buy the book [amazon.com].
CUI (Score:5, Insightful)
I think part of the problem is that writing software is a rather new handwork in comparison to e.g. metalworking. Programmers don't have a union, often they work under poorer confitions than workers at conveyor belts if you consider the higher responsibility they have.
more here (Score:3, Informative)
F15 equator bug (Score:2)
In any case, the SERIOUS problem was that when you flew over the equator, the computer would suddenly 'realize' that you were upside down from where you wanted to be and try to immediately turn the aircraft over to the 'proper' orientation. It was said that the aircraft would have survived the maneuver, but the pilot's neck would not.
Luckily this was found during simulations If it had happened during a real flight, it could have taken a long time (and lots of fatalities) to figure it out.
On a lighter note, there is apparently a subroutine -- phonetically referred to.. It was either wait_on_wheels() or weight_on_wheels(). In either case, it was added after some slap-happy test pilot tried retracting the landing gear while sitting on the runway (resulting in millions of dollars of repairs).
Yorktown and divide by zero errors (Score:2)
I wonder what experiences anyone else has had with divide by zero "glitches." Anybody else have a similar experience?
Re:especially important in healthcare.. (Score:3, Insightful)
To put things in perspective, fatalities caused by human errors (non programming related) outnumber those caused by software errors by orders of magnitude, in many fields (except, say in launching unmanned space vehicles).
S
32. Therac-25, X-ray (Score:3, Interesting)
Re:32. Therac-25, X-ray (Score:4, Informative)
Well, not exactly. It was used for cancer treatments, not x-ray imaging. And not all of the radiation overdoses were fatal.
It was a UI bug rather than a software bug.
Again, not exactly. The problems with the Therac-25 included hardware issues and some UI problems that lead operators to do some interesting things. They also included some race conditions that were definately software bugs.
You can check out a reprint of an IEEE article discussing it in depth here [vt.edu].
Just for some history: AECL, the Canadian government crown corporation who made the Therac-25, spun off its medical operations into private companies in the 1980s. The first was Nordion, where I worked for a summer as a co-op student, produces radioisotopes for medical use. Nordion was bought my MDS. The other company was Theratronics, which was responsable for devices like the Therac-25. It went without a purchaser for many years becuase of the stigma of Therac-25, but it was eventually (IIRC) bought my MDS as well.
Both companies are in my hometown, and the fallout from the Therac-25 (like the IEEE article) was front-page news when I worked at Nordion in the early 1990s. I just worked on sofware to measure how much of a given isotope to dispense to fill an order, but the whole Therac-25 incident was definately on everyone's mind.
Re:32. Therac-25, X-ray (Score:3, Funny)
X-RAY METER:
[Off--Low--Med--High--Glow--Kill--Mutate]
Remember the Therac-25? (Score:2, Interesting)
(A former Theratronics employee is standing right behind me, but he denies having worked on the Therac-25.)
Re:And no one will ever know... (Score:2, Funny)
I know a lot of people who threw out Windows when they got their Macs...
Michael-
It's Worse: The Patriot Never Worked (Score:5, Informative)
Don't take my word for it. Do a web search and see for yourself. Here are some references to get you started:
http://www.fas.org/spp/starwars/docops/rp911024.ht m
http://www.csmonitor.com/durable/1997/09/08/opin/l etters.1.html
GMD
Re:It's Worse: The Patriot Never Worked (Score:2)
The bizarre thing is that the fix is that a patriot installation literally has to re-boot on regular intervals in order to reset the internal timers. The bug is real, and it has to be dealt with.
Re:It's Worse: The Patriot Never Worked (Score:3, Insightful)
The second link is way low on content, I'm not sure how to judge it. All it says is "we looked at a bunch of videotapes and arrived at this conclusion". And then goes on to mention the bitter dispute between the U.S. and Israeli military over why the system didn't work so well in Israel.
I'm not sure I'm going to buy either argument. I know enough about flight characteristics to question the assertion that the scuds were so good at jinking and chaff the patriots (which were originally designed to hit jinking, chaff releasing aircraft) couldn't hit them.
If the scuds were dropping debris because extra fuel tanks made them unstable:
1) Why wasn't the wobble a pronounced problem at launch when the extra weight would have completely thrown off the trim characteristics of the missile?
2) Dropping "debris" is a bad thing, and it's only a matter of time before doing so results in an uncorrectable failure of the missiles flight aerodynamics. Why weren't most of them failing earlier?
3) Missiles don't fly in smooth trajectories nearly as often as you think. They jink to try and make anti missile systems (like say the Phalanx close-in weapons system) miss them or think they are dead and not worth any more attention.
Even if the patriots did fail, why would that have grave implications for our anti ballistic missile shield? SCUDs are cruise missiles, not ballistic missiles. Why do you think those big computers at Norad can accurately predict where the warheads will hit just after boost?
Re:It's Worse: The Patriot Never Worked (Score:2)
Re:It's Worse: The Patriot Never Worked (Score:5, Insightful)
I'm pretty sure the media has mentioned this, beyond those two media links you already posted, I mean. The issue has been debated since the first Patriot experiences during the Gulf War.
But I don't really see how this has "grave implications" for an anti-ballistic missile shield. The effectiveness of the Patriot missile used during the Gulf War era is in doubt, but a that does nothing to invalidate the general concept of destroying a ballistic missile with another interceptor missile. It certainly isn't easy to do, and there may be better ways to accomplish the same goal or things more worthy of our limited resources, but to claim that it's somehow physically impossible is both disingenuous and incorrect.
Re:It's Worse: The Patriot Never Worked (Score:2)
The spaces are due to the slashdot lameness filter. Yay perl.
OT: The Christian Science Monitor (Score:2, Informative)
-sk
Re:Much is very iffy to beaf up list (Score:3, Informative)
Re:Much is very iffy to beaf up list (Score:3, Informative)
The risks forum [google.com] is available as a moderated newsgroup, or you can subscribe to the e-mail version. See the Risks info [sri.com] page.
Re:Anyone remember this book? (Score:3, Funny)
Ah well you see, that's the problem of becoming overly dependent on paper-based systems for mission-critical applications.
Cheers,
Ian
Re:Patriot Scud Time Error (Score:5, Informative)
Kintanon
Re:The Ariane blowup was especially amusing (Score:4, Informative)
Not quite. The software was built for the Arianne 4. On the Arianne 4, it was physically impossible for that value to ever get high enough to overflow. So on the Arianne 4 the assumption that an overflow could only be due to a hardware failure was entirely correct.
If they had known that years later an Arianne 5 would come along, and those engineers would stupidly reuse the Arianne 4 code without testing it once, then perhaps they would have made a different decision. But I think the blame goes on entirely on the Arianne 5 guys, who were *not* the ones who wrote that code.
Re:Uranus (Score:3, Funny)
But I thought Uranus is a hole...
Any hole sufficiently big enough [goatse.cx] is bound to have some mass in there, somewhere.