Slashdot Mirror
Debug your Code, or Else!
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. "
Remember that time when that kid dialed into NORAD and used that security exploit to get into the Thermo-nuclear war simulator and everyone thought it was real until he and the inventor were able to trick the computer into playing Tic-Tac-Toe? I see a LOT of bugs in the software there but no one ever seems to care about that...
The ultimate network admin tool needs HELP!
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.
What, me worry?
The surprise isn't how many situations have cropped up because of software bugs, but rather how few. If you think of all the things that code is written for, and yet there hasn't been any major 'disaster'. Yes, the deaths and accidents are tragic, but on the grander scale of things, it's amazing that nothing truly catastrophic has happened.
sig--we don't need no goddamn sig
I'd take issue with the inclusion of the London Millennium Bridge; that wasn't so much a failure of software, but a flawed model, that failed to take into account the effects of swaying pedestrians. After it was rectified, there were new data - never used in any bridge model - incorporated into such models so that it won't happen again. That's science; not a bug.
It really amazing how many software project managers that don't fully understand what regression testing is all about.
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.
Old age and treachery almost always overcome youth and skill.
Software Horror Stories linked from the post's link
the BSOD. I still have nightmares.
"I don't think it's selfish, to eat defenseless shellfish." -NOFX
I believe more patients' lives are lost because of mistakes by doctors/hospitals/nurses, or sheer negligence. In some parts of India, for example, private hospitals are afraid to admit victims of accidents or crimes because the hospital itself might get into some trouble. Personally, I have seen doctors giving stupid advice, and people losing lives.
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
I seem to remember PowerBook 3500C was known to catch fire. Not a bug, per se, but it could have killed somebody. I know I almost threw mine out the Window and that could have caused serious damage.
I know a lot of people who threw out Windows when they got their Macs...
Michael-
You catch enchiladas by picking them up behind the head and holding them underwater until they don't kick anymore -VeGas
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.
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).
The only good weather is bad weather.
Click on the links, otherwise you don't get all the details. French-friendly exocet missile? Huh? Unless you click through you don't realize that the British radar thought the exocet missile was a friendly munition since the British arsenal included exocets. Any munition headed straight at you is probably not friendly.
[o]_O
He was considering making Fatal Defect required reading for the C programming course I took. From Amazon.com:
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."
-- Adam
Make reading the ACM's RISKS digest a part of your regular routine, and you'll hear about these kind of software-related problems and many others - usually shortly after they happen. The RISKS digest is available on Usenet as comp.risks, as a mailing list, and on the WWW at http://catless.ncl.ac.uk/Risks. A new issue is published on a semiregular basis, every one to two weeks. It's not only informative but interesting too.
--Jim
Sure, some people here gripe about this not being newsworthy. But as a hardware guy, I am happy to see that software guys are finally going to be held to some sort of standard.
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.
GPL raises this to new levels of concern. You can never know where your code will be used. It might just find itself in an cruise missile.
-twb
So much for poor Visual Basic Programmers :)
Damn, they never get to do fun stuff like this.
Rapid Nirvana
This one time I missed closing an /a tag on a post, and missed getting a wicked killer First Post.
It hurts when I pee.
I hope you don't mind a little nit-picking. The thread is titled "Debug Your Code." A lot of the problems listed in the article were for errors that occurred in situations outside the parameters that the programmers were expecting.
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
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.
I was a consultant at a major bank 3-4 years ago. An FTE made a one line error in a Cobol program for printing bank statements. Everyone in a small town of about 6000 got Their first page of statement and pages 2,3,4 etc. of someone else's statement.
What other piece of buggy software in history ever caused as much widespread collective apoplexy? :)
"Ask not what your country can do for you." --John F. Kennedy
The Therac-25 was an automated x-ray machine that overdosed patients. Fatally. It was a UI bug rather than a software bug. It's dissected in "Killer Defects" (IIRC) by Negroponte (again, IIRC).
Best Slashdot Co
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
watch this
Not in todays world.
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.
How about that horrid bug that extends the width of the window data by a factor of 8, making it impossible to read?
Does Slashdot want me to just waste more time at work or what?!
I'm sure we all have those bugs that we catch in bench testing. Mine was forgeting to add a cancel button to the following dialog box:
... well, you read the papers. Glad I caught that one before I released it to test.
"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
Go check out the Risks Forum, links are available from the ACM webpage. There is plenty of proof and explanation for hundreds of software related mishaps. You're obviously looking in the wrong places.
I'm the big fish in the big pond bitch.
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.
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.
Fight Spammers!
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.
The claim for this one is that a Patriot during the Gulf War failed to intercept a Scud missle and the Scud missile killed 26. Ergo, a software bug killed 26 people.
Considering that even the military now admits that no Patriot *ever* intercepted an Iraqi scud, this inference is unfounded.
Ah well you see, that's the problem of becoming overly dependent on paper-based systems for mission-critical applications.
Cheers,
Ian
That system just wasn't designed for that purpose. It was VERY well designed for its actual purpose, which was tracking AIRCRAFT going WAY slower than that missile. And it was only rated for 14 hours of continuous usage, not 100. So it wasn't a fault in the program per se, but a misapplication of a system designed for a different use.
Kintanon
Check out JoshJitsu.info for Brazilian Ji
(A former Theratronics employee is standing right behind me, but he denies having worked on the Therac-25.)
Blatant karma whoring...
The risks forum is available as a moderated newsgroup, or you can subscribe to the e-mail version. See the Risks info page.
The patriot missile failure was blamed on a roundoff error causing an accumulating time error, resulting in a miss.
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.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
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
Some years back, as a grad student, I saw a bunch of colleagues do a rather unnerving experiment. Much of the number crunching was, as usual, done in Fortran. So they instrumented the compiler to silently test for integer overflow, report when it happened, and also report whether the program tested for it.
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.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
Christian Science Monitor is usually a reputable paper, if only because they have their own reporters doing the work instead of tacking stuff onto ap/reuters stuff.
The spaces are due to the slashdot lameness filter. Yay perl.
[o]_O
So is it a webpage bug when you see:
:)
"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
"It's tough to be bilingual when you get hit in the head."
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.
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.
Welcome to the Turing Tarpit, where everything is possible but nothing interesting is easy.
"Wrong Starting Estimate of Uranus mass in
Iteration, Data Compression, 1986"
Caused wife 1.0 to go into panic and terminate all sex threads for the next three weeks.
a fucking scud did. The patriot bug prevented it from helping, but it didnt kill anyone. Sheesh.
My software always works perfectly on my system. Zero bugs.
I have no idea what the hell the users do to it to screw it up.
When after sitting down for 36 hours straight when I first learned to program in C, I wrote a small, but usefull, payroll program. By the end, during the function that would print out the check, I added "Press any key to continue, any other key to abort". Lucky for me I never released that program.
---
All comments are not factual unless stated otherwise.
There were many things that went wrong during the incident, but one of the FEW things that worked correctly was the AEGIS weapons system on board the guided missile cruiser. The error lay in the crew's mistaking the range information reported on the radar screen with altitude information. As a result, the CO thought that the incoming contact was flying straight towards his ship and decreasing in altitude (preparing to attack).
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!
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.
Believe nothing -- Buddha
We have to accomodate our users and unknown environments. When a reasonable user makes your program do something bad, that's either a user training problem or a software bug. You didn't check input data carefully enough, or you didn't provide a good user interface, or your requirements were bad, etc. All of those are software bugs.
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.
...the ice cream bug!
Your first link is a translation of a patriotic Israeli article cheerleading the competence of their military. It doesn't necessarily make what they're saying false, but does make it suspect.
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?
Education is a better safeguard of liberty than a standing army.
Edward Everett (1794 - 1865)
Human effects on bridges is hardly a surprise. Recall in 1981 when the Kansas City Hyatt's skywalk collapsed, killing 114, because the pedestrians were dancing (and the design was altered to ease construction). You'd think that would have been enough of a wake up call to the millenium designers to consider human motion. more info
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.
In one of my programming classes an instructor had a phrase that applies to this. "Bullet proof your code" Meaning whatever the user enters the program should work right.
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.
LinuxWorx
Spelling errors are intentional as are gramatical error
During live coverage of a Scud attack, one of the Patriots veered sharply to the left and hit an insurance office. The cause was said to be an error due to a time leak. The longer the Patriots were "online", the more leakage occured.
If you aren't part of the solution, there is good money to be made prolonging the problem
This IS the text on this very sort of thing. I love techno-"oops, that's not right, is it?"-horror stories and this book is filled with them. I REALLY recommend this book! Here's an example of the page after page of entries it contains:
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.
I swear by MacOS X. Although I use to swear *at* MacOS 9...
I think most of the bugs in software are the result of "Coding Under Influence". Wether it is a strict time-limit, ambiguous specifications, no sleep or other disturbances, it leads to blatant dumb assumptions or similar faults. Everyone knows that driving under influence is dangerous and can lead to accidents. Why do "software architects" think this is different when someone writes important programs?
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.
(don't mind the yellow)
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).
Sometimes boldness is in fashion. Sometimes only the brave will be bold.
-sk
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.
Infuriate left and right
Your assumption about the nature of pedestrian motion that caused the bridge wobble is incorrect:
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.
-BB
Uh oh. The SCUD is very much a ballistic missile. Therefore most of your points are moot as debris follows the same trajectory as the rest of the missile, disregarding air resistance of course.
I wonder what experiences anyone else has had with divide by zero "glitches." Anybody else have a similar experience?
In the old USSR (Stalin times), there was a standard bridge acceptance test:
1) put project managers, lead architects and engineers under the bridge;
2) put heavy loaded trucks on the bridge.
That was real extreme testing.
You'd better not -- I patented the logic behind those mistakes; if you even think about making the same mistakes, I'll see you in court!
Living better through chemicals
Actually, it's a three-step process:
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.
The Hyatt's skywalk collapsed soley because of the change in design. The design change caused the walkway to fail to meet building code. 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.
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.
But then again, I could be wrong.
As a former ADA (Air Defense Artillery) officer in the U.S. Army, I can tell you that the Patriot Missile system was designed primarily to shoot down enemy aircraft. It's ability to kill missiles is a secondary feature.
Robotiq.com is heavily tested on animals
In the early 1990s, before this part of the Eastern U.S. had ten digit dialing, our SCO server would dial out, at 1:00 am, to all the little Pep Boys stores in PA and New Jersey in an attempt to update their inventory tables. Alas, one programmer forgot about the New Jersey area codes, and of course there are some overlapping 7 digit numbers between the two states. Oh, and did I mention that the system was coded to KEEP TRYING every ten minutes minutes until it was successful? Heh, heh...at least it wasn't my phone they were ringing at one am...
Yikes. I'd call in sick that day.
Of course the bad side of this is that if it collapses, you've just lost
1) The bridge
2) People who were most familiar with the project, and could fix it
3) The heavy loaded trucks that could've been used for something else
But I guess the idea was to have this be scary enough so that it would never happen. Ever actually hear of a bridge failing this type of test?
Please subscribe to see the more insightful version of th
1. You'd have lost this anyway - that's the point of the test.
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.
What are you saying! The Corilois effect is one of the main causes of huricanes!
Coriolis-effect-causes-water-to-swirl-in-the-toile t myth that you find in so many physics textbooks (the Coriolis effect only works on planetary scales).
I know this is offtopic, but "planetary scales" ? Please... I certainly hope no one quotes you on that one. Man-sized pendulum is just a one example with what one can easily detect the coriolis effect. Long range cannons are another thing where the coriolis effect is also taken into account and there are many many others.
Just because the bath tub doesnt show the coriolis effect you shouldnt jump the gun and start talking about "planetary scales".
1 Earth is warming, 2 It's us, 3 it's royally bad, 4 we need to take action NOW
Yes, crashing planes and scuds hitting army barracks are funny, but patients losing their lives is not.
Be wary of any facts that confirm your opinion.
Given how the current trend in a lot of scientific fields is to borrow good ideas from mother nature, I'll betcha this is on somebody's drawing board somewhere.
"Do you expect me to talk?" "No, Mr. Bond. I expect you to die!"
Um, no. The SCUD is the theater ballistic missile not a cruise missle. It looks like a WWII German V2. See this page for more info.
Some software that works.
420,000 lines of code, and only one error found in each of the last three versions.
In the last eleven versions, 17 errors altogther were found.
Note how much money it costs to produce software of that quality, and you will see why software usually has bugs - especially when you add in the short development cycles that management wants today. Damn the testing, full release ahead!
> This small generator can be made pretty damn indestructable (blackbox anyone?)
This is a nice thought, but we're talking about spacefaring vehicles, not airliners. There isn't an airplane built that goes as high as these vehicles. The problem actually isn't a downrange crash from a failure within launch frame (the casing for the radioactives will withstand this sort of failure), but a reentry-style fall from a failure in the second/third stage. From that height, the generator is going to be falling very fast and very hot, and solid iron has trouble surviving these conditions (as would most black boxes, and anything else not specifically designed to withstand de-orbiting). So, while it's not a very big problem (from sub-orbit, it's hard to hit a populated area), it's still very possible to drop radioactive material in a populated area such that contamination is likely.
I agree that there has been a lot of fearmongering about using radioactives for spaceships, but we learned in AE classes that using the term "indestructable" in conjunction with anything that leaves the atmosphere is usually a mistake.
Virg
BRL has a test suite, as does Kawa. I don't think test suites in free software are so uncommon.
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.
> We, as programmers, should make sure that our software are comunicating properly.
Am I the only one who sees humor in saying, "...software are communicating properly" in a comment about communicating properly? Anyone?
OK, I'll shut up now.
Virg
Wrong Starting Estimate of Uranus mass
But I thought Uranus is a hole...
Any hole sufficiently big enough is bound to have some mass in there, somewhere.
"And like that
That may have more to do with the source of your facts than the situations themselves. My mistake though, you came across a little cavalier in your attitude toward potential damage due to bugs.
I'm the big fish in the big pond bitch.
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.
I guess I'll have to take your word for it but I think all the mass media has done is "mention" it. Pretty much everyone I tell about the failure of patriots is either in shock or replies with "That's not true! I know they work! I saw them destroying scuds on CNN!"
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.
I never said that it was physically impossible. Four minutes before your post I made a reply to another's comments. I realize that you probably didn't get to see my 2nd post before posting yours. So at the risk of being modded Redundant, here's my answer:
"My comment about the Patriot failure being a bad sign for our upcoming missle defense shield was to point out that if we can't hit relatively-slow-flying scuds, how are we possibly going to hit speedy ICBMs? We haven't even solved the theatre ballistic missle problem yet. So we're years away from being able to intercept WMD-bearing ICBMs."
GMD
watch this
A friend of mine implementing logic in a process control system, overseeing water control for an entire valley, repeatedly dumped over a million gallons of water doing a few test runs.
"the Coriolis effect only works on planetary scales"
actually if you take a round pan, put a plug in the center, fill it up with water, let it stand for about a 10 days, then pull the plug, you can see the Coriolis effect. Any still body of water that sits still long enough is subject to that force. However that force is pretty weak, so in vibration or motion will disturb it.
The Kruger Dunning explains most post on
How did it go? The system freezes up and posts a dialog that says something like "Unexpected system error: -72." And there's only an "OK" button...
"Biped! Good cranial development. Evidently considerable human ancestry."
Okay, let's consider I completely missed that the SCUD is a ballistic missile. I thought it wasn't because I thought SCUD stood for Subsonic Cruise Unarmed Decoy. Which apparently there is such an acronym, but it doesn't seem to represent these missiles. I concede that point.
So we're back to the SCUD being a ballistic missile. So if the missile is ballistic, following a ballistic trajectory, why was it wobbling in flight? The bulk of the missile, sans debris, should have been in a ballistic trajectory. The scud has controllable fins, so it does have some measure of cruise guidance, I would think if the missile were coming apart in flight, the control surfaces would be among the first to go, and then the missile would again be in a purely ballistic trajectory. Why was it wobbling? If it started tumbling end over end, I wouldn't expect it to survive more than 100 miles. Whatever destabilization occurred needed to start while the missile still had thrust, or the control surfaces were still intact.
Education is a better safeguard of liberty than a standing army.
Edward Everett (1794 - 1865)
For some reason, Wordpad saves RTF files smaller than Word does. Go figure.
;-)
Easy, wordpad was too small to get all the bloat in.
I'm sure they will have fixed that in the next version of windows
"First lesson," Jon said. "Stick them with the pointy end."
Well, lets hope they don't shoot during reboot then...
"First lesson," Jon said. "Stick them with the pointy end."
I think there are at least one country that is holding on to old (supposedly outdated) Surface To Sea missiles for this exact reason.
Test (where they were presumably used as target practice) showed that they were very difficult to hit due to their erratic flight.
This "feature" (and now we are talking eature in the MS sense, folks) was considered to compensate for their low accuracy.
Calculations indicated that they would have a higher kill ratio than a better missile would.
Wierd!
"First lesson," Jon said. "Stick them with the pointy end."
Trust me, when all involved know of this beforehand, the bridge won't collapse!
When you have to trust your work with your life, you do a good job.
No matter how wicked this sounds, it probably worked... I doubt many people was killed.
(Of cours Stalin more than compensated for the lack of bloodshed in other ways...)
"First lesson," Jon said. "Stick them with the pointy end."
I had a prof who was stressing someone else's opinion that we change from the word "bug" to the phrase "time bomb" so that people would get a better feeling for what they really were -- incorrect sections of code just waiting to mess you up.
I'd vote for Booby-Traps. There's lots of boobies waiting to be trapped.
Possibly, an accident looking for a place to happen.
But seriously folks, the problem with bugs is that they sometimes get together with other bugs and then produce spectacular results. I've even seen a triple. Three bugs. Any one of them absent, it would be impossible to find anything wrong.
GnuCash does.
Any sufficiently advanced technology is indistinguishable from a rigged demo
--Andy Finkel (J. Klass?)
http://sunnyday.mit.edu/therac-25.html
Which includes links to the author's other papers and publications.
Don't forget to mount a scratch monkey.
See here
.
Not in depth theory, but an excellent explanation . .
himi
My very own DeCSS mirror.
...undertaken there will be mistakes. But we learn from each one ...
Do we?
With Open Source and well publicized bug lists, maybe, some of the time.
With Closed Source, surely you jest.
the program should only do what it was designed to do, not more or less.
throw data at a program that it shouldn't get
Exactly. Otherwise it's like a boat that stays afloat only in a harbor on a calm day.
And a cracker's exploit of a buffer overflow is maybe the kindest way of experiencing the bug. If you don't think so, explore the consequences of a shipping clerk triggering the same bug on a production system. Horrible thought, but the "black hats" may be the only friends you've got in the business.
And for the life of me when will programmers realize
that just because the software works on their
box it may not work on another machine.
Just installing Visual Studio,Source Safe etc, makes
testing useless on your main machine.
Program on your main machine.
Test on a clean machine.
Something is horribly broken here.
If you must develop and test for such an environment, you must test on both a clean machine and a machine with all the "goodies" loaded. It doesn't really work to tell a customer that he needs to get rid of all his other software, reinstall Windows, and load your software.
And no its not easy, you need to test against all combinations of wierd stuff to ensure that it will actually run.
You can protect your program against simple input errors.
I know this as the monkey test:
Put someone behind the keyboard (just pull a sales from the other end of the building). Let hime type/click away. He(/she) shouldn't be able to do read damage.
Human effects on bridges is hardly a surprise. Recall in 1981 when the Kansas City Hyatt's skywalk collapsed, killing 114, because the pedestrians were dancing (and the design was altered to ease construction).
Actually this wasn't a "human effect" the walkways would have collapsed anyway, as built, simply due to the force of gravity. Since the bolts holding the upper walkway were taking the load of both. (Also the bolts were right through where two pieces of metal were welded together. Thw whole thing simply wasn't built as designed.)
The Millennium Bridge sway was due to people moving on it, it was, AFAIK, built according to the design. Just that the design was bad.
In the old USSR (Stalin times), there was a standard bridge acceptance test: 1) put project managers, lead architects and engineers under the bridge;
More recently a Moscow court sentanced an architect to live in a building he designed. Most likely this is a Russian, rather than Soviet, principle.
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.
It certainly wasn't the first case where an apparently minor change made in construction caused a structure to collapse. Nor is it likely to be the last.
I have to argue the usage here, because while your argument holds logical merit, his usage was incorrect in this context. His entire sentence readThis usage is not right, since in this context, if he wants to indicate plurality he should use the plural form "softwares" (which is awkward itself, but it the only grammatically correct choice for this construct). He could reword the sentence "...software communicates properly" but as he used it, it's not proper communication, hence my detection of irony.
Virg
I am not expert in aerodymnamisc but in general the turbulences above wings increases the lifting forces but also drag forces so you increase the fuel consumption (you can see that during plane landing where for lower velocities the wings are reshaped)/
The purposes of flaps (and leading edge slats) is to lower the stalling speed and increase lift at low speed. Otherwise you'd need much longer runways. (Though probably not quite as long as that at the KSC).
Works as designed is the excuse for a LARGE number of bugs. Just because it was desgined that way doesn't mean it isn't a bug, just that the bug goes deeper than software, into the design.
A man who wants nothing is invincible
hmmm.. it wasnt that the cable could support only half the tension, it was that the joints (those for the upper cable to upper walkway joint) had to take double the load.
:(
in original design joints for each level supported only the load of that level (only the roof joints supported entire weight). by splitting the rod and having 2 joints on the upper level, the upper cable to upper level joint had to support the weight of both the walkways - which it couldnt do.
I use Friend/Foe + mod-point modifiers as a karma/reputation system.
Well, this does depend on how you define "disperse". It's unlikely that the fuel would be thrown all that far when the reactor remains hit the ground, but since a good portion of the shielding would have been peeled off by the fall, the resulting lump of slag would be (both in a radioactive and thermal sense) quite hot, so nobody could stay within a quarter mile of it safely. In a remote location in the Sahara desert, it wouldn't pose much of a threat, but if it fell in a New Jersey suburb, it could displace quite a few people.
Virg