History's Worst Software Bugs

bharatm writes "Wired has an article on the 10 worst sofware bugs.. From the article 'Coding errors have sparked explosions, crippled interplanetary probes -- even killed people. Here's our pick for the 10 worst bugs ever, but the judging wasn't easy.'"

Comments

Predictions are hard

[Teppy]

Wonderful article. Twenty years ago I believed that writing software would soon become a licensed profession. (Need a
license to own a compiler, for instance.) I thought that the event that would inevitably trigger this is when a software
bug caused a human death.

I still believe that programming will eventually require a license, but I now think that lobbying by the big media
companies will be the cause. Depressing, huh?

Re:Predictions are hard

[ZiakII]

Wonderful article. Twenty years ago I believed that writing software would soon become a licensed profession. (Need alicense to own a compiler, for instance.) I thought that the event that would inevitably trigger this is when a software bug caused a human death.

This is like saying you need a license to operate a Soda Vending Machine because some idiot decided tipping it over trying to get a free soda was a smart idea. You might have to put warnings on compliers like do not code if you have no clue what you are doing, etc but requiring a license won't ever happen. I am sure there will be lawsuits in the future regarding software bugs, but any software being used where an error could cause a human death is going to have a corporation behind it, that can be held responsible.

Re:Predictions are hard

[bunratty]

You might have to put warnings on compliers like do not code if you have no clue what you are doing

Unfortunately, in my experience the ones who have no clue about what they are doing seem to be the most confident that they are top experts.

Re:Predictions are hard

[AvitarX]

Actually more likly to be lobbying by a union. And it may be a reputation thing (like carpenters) or an enforced thing (like electricians). It just seems far more likly that programers would want the benifit of being a selective group than that the media companies want to do that to them.

Re:Predictions are hard

[pete6677]

Licensing for programmers would have to be done differently than it is for other professions, because the nature of the job changes much faster. If licensing were administered by a state board, they would probably still be asking exam questions about the proper way to compile punch card programs. The computer industry has a defacto licensing scheme already, with vendor certifications. I think this is about as close as we will ever get to having licensing, since there is no other way for a licensing program to realistically keep up with new technology. Liability for programming errors will always fall on a company anyway, since they have a lot more to sue for.

Re:Predictions are hard

[Mr. Gus]

License to own a compiler is a bit extreme, don't you think?

One of the items from the article included a medical product that killed five people due to an error written by an inexperienced programmer. In situations like this, yes, a license-to-program would be fantastic. The people who wrote the software for the Toyota Prius, that too. The guy who wrote "Finger"... maybe not.

Re:Predictions are hard

[basingwerk]

There's a Germanic streak in North American society. It's odd that in the land of the free, often we need a license for this and a permit for that and so on. It's getting bad in the UK now as well, thanks to a load of regulations from our friends in Europe. On the other hand, I guess all that permit stamping and inspection stuff makes work for somebody, somewhere. But does it do any good apart from that?

Re:Predictions are hard

[Jason Ford]

Several recent studies lend support to this observation. From an article at the American Pyschological Association:

We've all seen it: the employee who's convinced she's doing a great job and gets a mediocre performance appraisal, or the student who's sure he's aced an exam and winds up with a D.

The tendency that people have to overrate their abilities fascinates Cornell University social psychologist David Dunning, PhD. "People overestimate themselves," he says, "but more than that, they really seem to believe it. I've been trying to figure out where that certainty of belief comes from."

Dunning is doing that through a series of manipulated studies, mostly with students at Cornell. He's finding that the least competent performers inflate their abilities the most; that the reason for the overinflation seems to be ignorance, not arrogance; and that chronic self-beliefs, however inaccurate, underlie both people's over and underestimations of how well they're doing.

Re:Predictions are hard

[j-cloth]

What constitues programming is so blurry, though.
Does it count when someone puts some HTML in a blog? What about Javascript? a DIY PHP site? a batchfile or shell script? Excel function/macro?
Do you only want to licence compilers? How do I install my OSS? What about the power of interpereted or JIT languages? So much can be done with uncompiled code.

Re:Predictions are hard

[hipernoico]

Yep, wonderful. But I strongly believe that computing (especially programming) is so revolutionary to the point of being (actually) impossible to control WHAT people do with their machines. Look how P2P is absolutely "out of control". No way to stop people. I think coding is in the same line, no way to control programmers... I dont thing it's going to change in the near future.

Re:Predictions are hard

[cow-orker]

A license to sell software would probably be enough. Moreover, holding someone responsible for damage caused by software would do the trick. This would normally be the vendor, but if no vendor was paid, it might be an administrator.

A license to own a compiler would be a bad thing. We all know that Microsoft, Oracle, SAP would immediately buy... err... apply for licenses, and we also know how competent their coders are.

Re:Predictions are hard

[idontgno]

I can't cite any documentation, but I recall seeing studies which show that the number one critical attribute of persistently optimistic personalities is a chronic inability to clearly see reality. Is this the same phenomenon?

In the words of the old chestnut, "If you're calm and confident when everyone around you is running around in blind panic, you clearly don't understand the situation."

Re:Predictions are hard

[antifoidulus]

Is there a problem with under estimating your own abilities? I can't tell you how many times I was convinced that I failed a test only to find out I got an A or a B(conversely more often then not when I felt that I aced a test I actually ended up wiht a poor grade). What pyschological motivations are behind under estimators?

Re:Predictions are hard

[Anonymous Coward]

Clearly these individuals are not overrating their abilities but are in fact both victims of software bugs!

Re:Predictions are hard

[BenEnglishAtHome]

The tendency that people have to overrate their abilities fascinates Cornell University social psychologist David Dunning, PhD.

I'll bet the guy just LOVES the first few installments each season of American Idol.

Re:Predictions are hard

[kryten_nl]

They'll take my compiler when they pry it from my cold dead hands...

Re:Predictions are hard

[servicemaster]

Often I find it's a difference in personality type. Using the Keirsey temperment sorter you see where people are separated by how they perceive the world. One aspect of personality is how you perceive the world to be, either in concrete or possible terms. Objectively the two are not entirely opposite, it's just in how the world is organized. One views their surroundings as possibilities, the other as actualities. The actual view is the same, but the actions and course determined is different. ie. If you're calm and confident when everyone aroudn you is running around in a *BLIND* panic... it's just as likely you can see something they can't

Re:Predictions are hard

[TemporalBeing]

We've all seen it: the employee who's convinced she's doing a great job and gets a mediocre performance appraisal, or the student who's sure he's aced an exam and winds up with a D

In all reality, that is hardly a way to rate someone. Some people, despite how good they may be at the subject, just don't test well - they student could very well be a genius at the subject and still flunk.

As per performance reviews - you have to have an accurate representation on what you are going to be reviewed on order to be able to achieve the review. This is also flaws as many don't describe or tell how they will actually review someone until after the review has been done, so the person being reviewed has no concept of what they can do to get a good review. As a result, people will think they are going to be rated well, and end up rated poorly because the person rating did not clarify well enough how they were going to do the rating.

As I said, both of those are majorly flawed ways to evaluate someone. Hopefully, the guy from Cornell took that into account, but I wouldn't be surprised if he didn't. And even if he did, he would have to take it into account so many different ways that it would be too hard to really test its accuracy.

Re:Predictions are hard

[Knetzar]

under estimating your abilities leads to stress and more work.

Re:Predictions are hard

[Registered Coward v2]

You miss the real reason for licensing - it enables a profession to control the number of practioners by creating barriers to entry; thereby raising salaries.

Re:Predictions are hard

[sbenj]

Software is hard.

It may be my bad luck in the last few years, but a fair majority of the folks I've worked with have been terrible coders. And from others I've talked to, it seems, at least anecdotally, that incompetance is common, that many shops operate without basic standards or even basic source code control, that it's rare for people writing code to have a full understanding of the systems they're working on or the ramifications of the systems they build.

Really, I don't consider myself great at this, but I've worked with so many who really have little knowledge beyond syntax and how to accomplish basic tasks. The most lacking is usually any sense of structure. Maybe there just aren't enough people around who are good at this.

I think we can even talk about this without questions of ego. There's just such a higher demand for this sort of work than there was 20 years ago, and I think most people would agree that almost anyone can do it (sort of) and that it takes an aptitude (an aptitude that at the very least is not universal) to do it well. Under those circumstances there's just bound to be lots of stuff that doesn't quite work.

I'd like to see a slashdot poll- "Of your co-workers in the last few years, what percentage would you consider competent?". Follow up poll could be "How competent do you think you are?"

Re:Predictions are hard

[Marillion]

I think the real cause is a communication breakdown between users and programmers. The biggest problem with most software is that the users get an application that fits what they said, not what they wanted.

Many software engineering methodologists hold the Space Shuttle program as the example of how low a defect rate can be. I think what most neglect to consider is that their user community is 100% aerospace engineers. The specs that come out of that user group are as bug-free as anyone could hope for.

Re:Predictions are hard

[Stealth Potato]

I still believe that programming will eventually require a license, but I now think that lobbying by the big media companies will be the cause. Depressing, huh?

Oh, I very much doubt that. (Or at least, I hope I can safely doubt that...) Amateur / hobby coding is too well-established to let that happen - after all, much of what we have in the computing industry today had its seeds in the tinkering of geeks and hobbyists. Restricting the "Right to Code" to the licensed (and you'd better believe the larger corporations would be on top of it first) would stifle a very valuable source of innovation.

In closing, I leave you with this thought: My compiler is my tool, but if someone tries to take it away from me, it's my weapon. <evil grin>

Re:Predictions are hard

[Fulcrum of Evil]

In the words of the old chestnut, "If you're calm and confident when everyone around you is running around in blind panic, you clearly don't understand the situation."

Nah, I'm the only one likely to put the fire out. There's never a reason to panic.

Re:Predictions are hard

[Fulcrum of Evil]

Licensing for programmers would have to be done differently than it is for other professions, because the nature of the job changes much faster.

No it doesn't. 20 years per paradigm is reasonable considering the age of the profession.

The computer industry has a defacto licensing scheme already, with vendor certifications.

Vendor licenses are spotty and myopic, generally focusing on the vendor's products instead of practices and techniques.

Re:Predictions are hard

[Lars T.]

Unfortunately, in my experience the ones who have no clue about what they are doing seem to be the most confident that they are top experts.

And for some reason they still get licenses, so I doubt that would help much.

Re:Predictions are hard

[Armour Hotdog]

Interesting. I'd read one of Dunning's earlier papers (warning: PDF) a while back. I'm glad to see he's still at it.

One thing that bugs me though, is the last section of the article you linked, where it posits that a remedy is better feedback. While this makes sense, I wonder how people in need of such feedback are to judge the quality of the feedback they receive. Too often, a person is perceived as knowledgable and authoritative merely because he exudes confidence when he speaks. How is a neophyte in need of guidance to differentiate between feedback from a true expert and that from a clueless yet confident imposter?

Re:Predictions are hard

[0racle]

Over estimating your abilities leads to stress over no work. Damn, you just can't win.

Re:Predictions are hard

[mudbogger]

I would say the causation works in the opposite direction. If you are the type of person that often has that level of overestimation regarding your abilities, you are probably less prone to study to the point of perfecting something, and hence less likely to demonstrate a mastery during an exam.

Re:Predictions are hard

[(H)olyGeekboy]

You will sooner need a license to parent than a license to code.

Look at all the damage inflicted on the world by misparented children! /tongue in cheek :)

Re:Predictions are hard

[Urusai]

Sounds like a Dilbert cartoon. Are you sure you have a clue?

Re:Predictions are hard

[Kohath]

It's odd that in the land of the free, often we need a license for this and a permit for that and so on.

These restrictions are put in place so the "in" group (the group that gets licensed) doesn't have to compete for jobs with the unlicensed "out" group. The more licenses and permits you need to do a job, the fewer people you have to bid against and the higher your pay.

It's bad. Less work is available because the jobs cost more. Less gets done, there are fewer jobs, and fewer employers and customers. Overall, the guy with the license benefits unjustly at the expense of everyone else.

Barbers in my state have to get licensed. Because, well, think of the horrors that could occur otherwise.

Re:Predictions are hard

[Hoi Polloi]

In the words of the old chestnut, "If you're calm and confident when everyone around you is running around in blind panic, you clearly don't understand the situation."

But isn't that the quality we say we look for in our leaders?

Re:Predictions are hard

[Neoprofin]

What about people who recieve performance reviews based on the same standards every quarter, or multiple tests with the same format? What about epople who are told what their tests or reviews will be based on?

I think it's a bit off to say that people have no concept of what they'll be rated on. Anyone working in any profession should have some grasp of what's expected of them by their superiors and if they don't waiting until they get a poor performance review isn't the best idea.

There can certainly be flaws in these rating scales, but those exist regardless of the subjects expectations. If Student/Worker thinks that they did well, they should think they did well by the standards they're being judged on.

Re:Predictions are hard

[Neoprofin]

Seek other opinions. If a doctor confidently told you that chopping off your legg was the only way cure your baldness you'd probably be out the door before he finished his sentence. If Captain Cocky's (every workplace has one) doesn't sit well it's entirely possible he's making it up as he goes along. Or, worse case scenario you get your nuts in a vice and learn never to listen to that person again.

Re:Predictions are hard

[Garabito]

"If you're calm and confident when everyone around you is running around in blind panic, you clearly don't understand the situation."

or..

I already know which person I'm going to put the blame on

Re:Predictions are hard

[stg]

But isn't that the quality we say we look for in our leaders?

    Yes, just look at the latest US presidential elections. Could they have elected someone with less understanding of the situation (no matter what the current situation is)?

Re:Predictions are hard

[pete6677]

20 years per paradigm is reasonable
 
Umm, what? I don't know many people who are still coding the same way they did 20 years ago. Most IT jobs today deal with things that were either not invented or not commonly used 20 years ago. That time frame would be so long as to make the licensing useless. People would memorize answers to obsolete questions just to pass the test, and this would not reflect on their abilities to work with current technology.

Re:Predictions are hard

[Fulcrum of Evil]

Most IT jobs today deal with things that were either not invented or not commonly used 20 years ago.

And yet, most of the stuff from 20 eyars ago still applies. Amazing, huh?

People would memorize answers to obsolete questions just to pass the test, and this would not reflect on their abilities to work with current technology.

Whereas today, people memorize the answers to overly specific questions to pass a test. At least with certification you usually need to apprentice yourself.

Re:Predictions are hard

[bogado]

but I recall seeing studies which show that the number one critical attribute of persistently optimistic personalities is a chronic inability to clearly see reality.

I don't know about researchs but in my humble experience I can tell that 100% of pessimist people call them selves "neither optimist nor pessimist, just realist". Witch in my opinion just categorize them as "clearly pessimist".

What is reality anyway? Sure that block of cement that I kicked the other is real. But when you get as subtle to what people percieve of the reality it gets more and more complicated to measure it and atest that something is real or not. After all pessimist people tend to see that all is bad, even when things are not that bad and a optimistic person see as things not too bad when everything is lost already.

My personal phylosophy lately has been, if a problem does not have a solution it is solved already.

Re:Predictions are hard

[Old Wolf]

This is like saying you need a license to operate a Soda Vending Machine because some idiot decided tipping it over trying to get a free soda was a smart idea.

Terrible eh. Next thing, they will have to put warnings on hot drinks to say that they are hot.

Re:Predictions are hard

[Trogre]

Don't give Microsoft any ideas.

*shudder*

Re:Predictions are hard

[-brazil-]

The funny thing is, last year I had a friend from the UK over for a visit during Oktoberfest (the original one, in Munich) and we watched a wall-of-death motorcycle stunt show. He said they would never allow anything like that in the UK due to safety regulations. So it seems the British are more "Germanic" than the Germans in this regard. Actually he was wrong, and there are shows like that in the UK, so it's more of a perception thing. We Germans ourselves feel that we have the worst tendency towards bearocracy and rules, but what I've seen and heard from other countries is rarely much better and sometimes worse.

As for it doing any good, yes, it very obviously does. Do you REALLY want to allow people to drive cars without a license and potentially crash into you due to a mistake made from lack of experience or knowledge? Do you REALLY want your toaster to electrocute you because the maker cut corners with the safety checks in engineering or hired insufficiently qualified engineers? Lack of enforced safety regulations and accountability kills and ruins people - and often not those who are responsible or could have done anything to avoid the risk. Of course the beaurocracy needed to implement it all inhibits productivity and at some point the cure is worse than the illness, but it's a continuum and opinions vary on where the proper point of balance is.

Re:Predictions are hard

[basingwerk]

Do you REALLY want your toaster to electrocute you because the maker cut corners with the safety checks in engineering or hired insufficiently qualified engineers?

Fair enough, but many in Britain think that new regulations are strangling our innovative culture. In the trade-off between cost and risk, there is a lot of room for some people to exploit others using the politics of permits. I don't know who is worse - the greedy or the fearful. In any case, the British way is to accept that life is risky and always ends miserably, so let's have some fun without Euro-beamters poking their noses in all the time.

Re:Predictions are hard

[TemporalBeing]

What about people who recieve performance reviews based on the same standards every quarter, or multiple tests with the same format? What about epople who are told what their tests or reviews will be based on?

As I said, some people just don't test well. It doesn't matter what format the test is in, they just don't test well. Some test formats may be better for them than others, but testing just doesn't work the way its "suppose" to.

I think it's a bit off to say that people have no concept of what they'll be rated on. Anyone working in any profession should have some grasp of what's expected of them by their superiors and if they don't waiting until they get a poor performance review isn't the best idea.

Except when the Boss's idea doesn't get communicated, is communicated poorly, and/or doesn't line up with the industry. The scary thing about Dilbert, at times, is that there is a lot of truth behind it. Certainly if the employee waited until the last minute to figure out what they were going to be reviewed on, then there is some issue on their part; but it's also the supervisor's job to make sure the employee understands their job and how they can do well at it - that simply part of being a supervisor/manager.

There can certainly be flaws in these rating scales, but those exist regardless of the subjects expectations. If Student/Worker thinks that they did well, they should think they did well by the standards they're being judged on. But the standards have to (a) be communicated to them, (b) be understandable, and (c) be realistic. The problem is often that 'a', 'b', and 'c' aren't.

Re:Predictions are hard

[Neoprofin]

If people don't test well one would hope that at some point in their life they'd come to the realization that they don't test well and stop expecting that they did a great job on it. It's not about abilities vs abilities communicated by a test, it's about abilities communicated by a test vs how well you think your abilities are communicated by a test. I'm not saying people should always know the right answers, but I do think that they should be able to recognize when they don't know the answer. That's what I was trying to get at with my last comments. The topic is how well people think they do, and while that can be skewed by testing them on a completely broken scale, it's a flaw inherent in the scale, not in trying to test what difference there is between expectations and reality. When testing for that one would hope they looked at situations which were not broken when they reach their conclusion that people cannot accurately judge their own performance.

Re:Predictions are hard

[TemporalBeing]

The topic is how well people think they do, and while that can be skewed by testing them on a completely broken scale, it's a flaw inherent in the scale, not in trying to test what difference there is between expectations and reality. When testing for that one would hope they looked at situations which were not broken when they reach their conclusion that people cannot accurately judge their own performance.

The problem is that you run into it under both conditions.

Just because one doesn't test well does not mean that they can determine which tests it is that they don't test well on until they get the results back. It is misleading to think that someone will know they don't test well and be able to correct for or expect the failure.

Most people test well under most cases, but not under certain cases. It's not a matter of being prepared, but a matter of matching the mind to the test preparer, which is often out of the test takers control.

I was just trying to point out that I hope the professor took into account exactly what you just pointed out, because otherwise his data would be flawed and worthless.

Re:Predictions are hard

[zerofret]

He's finding that the least competent performers inflate their abilities the most

Of course the least competent exagerate the most. The higher your skill level, the less room there is to exagerate in. A lot less need to exagerate as well.

They are just very, VERY careful.

[Poromenos1]

When you are writing software for life-critical applications, there is various software and techniques that ensures bug-free code. Just look at all the airplanes, powerplants, car computers, etc. It's not very usual at all to see one fail critically.

Re:They are just very, VERY careful.

[Coryoth]

When you are writing software for life-critical applications, there is various software and techniques that ensures bug-free code. Just look at all the airplanes, powerplants, car computers, etc. It's not very usual at all to see one fail critically.

When you are writing software for life critical systems, there are methods you can follow that allow you much greater assurance of correct code and drastically reduce the testing burden (byt being abel to prove that certain classes of errors don't exist in the code). It's akin to static types, which allow you to statically catch a lot of type errors obviating reducing the need to spend time testing for possible type errors.

The languages and methods used are things like SPARK and B-method among others. The beauty of systems like SPARK is that they provide a degree of flexibility in how much work you go to depending on how much extra assurance you want. It is quite possible to simply specify critical portions of code with a little extra formality (basically extended static checks beyond what type checing alone can give you) through to fully specifying everything and doing formal proofs for the whole system. You can tailor the effort and assurance to the needs of the project.

Jedidiah.

Re:They are just very, VERY careful.

[Coryoth]

When you are writing software for life-critical applications, there is various software and techniques that ensures bug-free code. Just look at all the airplanes, powerplants, car computers, etc. It's not very usual at all to see one fail critically.

When you are writing software for life critical systems, there are methods you can follow that allow you much greater assurance of correct code and drastically reduce the testing burden (byt being abel to prove that certain classes of errors don't exist in the code). It's akin to static types, which allow you to statically catch a lot of type errors obviating reducing the need to spend time testing for possible type errors.

The languages and methods used are things like SPARK and B-method The beauty of systems like SPARK is that they provide a degree of flexibility in how much work you go to depending on how much extra assurance you want. It is quite possible to simply specify critical portions of code with a little extra formality (basically extended static checks beyond what type checing alone can give you) through to fully specifying everything and doing formal proofs for the whole system. You can tailor the effort and assurance to the needs of the project.

(This time without that dangling link - that'll teahc me not to preview)

Jedidiah

Re:They are just very, VERY careful.

[MarkGriz]

"(This time without that dangling link - that'll teahc me not to preview)"

DOH!

Re:They are just very, VERY careful.

[HotNeedleOfInquiry]

But your assumption is just as great. Obviously a simple endless loop can be written without bugs. How a about an endless loop with a couple input and output instructions? How about a couple of conditional branches? At some point the odds of a bug start to go up, but in *some cases* it is possible to write bugless code.

Re:They are just very, VERY careful.

[karnal]

that'll teahc me not to preview)

Yea, that'll teahc ya!

only 10?

[Lucan_UK]

I wouldnt say they are the 10 worst bugs ever... more like the 10 most widely known media announced bugs. Okay I have no examples of any others but I'm sure there must be worse bugs out there...

anyone think of any others?

Re:only 10?

[corngrower]

Besides that, there really were only 8 software bugs mentioned. One, the pentium floating point error is a hardware error. The other, the CIA messing with the software for the soviet pipeline was intentional.

Re:only 10?

[plover]

I don't think they should count the "pipeline bug."

That was a trojan. It was a deliberate attack on their system by an enemy. It didn't even arrive via the now classical "worm" or "virus" route, which would have implied that a "bug let it in the door." No, this one was deliberately planted carefully at the root. It's not a bug, it was an attack.

Re:only 10?

[ptomblin]

Not to mention the fact that neither the CIA nor the Soviets ever admitted that there was such a bug. Sounds like Tom Clancy-ish wishful thinking to me.

Re:only 10?

[c_fel]

I remember the Mars Polar Lander crash in 1999 [http://www.space.com/missionlaunches/mars_polar_l ander_031222.html%5D. At the time there was a rumor that said it was a human error : somebody had mixed a foot and a meter. Now we know that it was a software bug that was contained in a single line of code.

Re:only 10?

[arivanov]

Seconded.

Both radiation bugs in both cases have killed less people then the shiteware used in Patriot missile system. Ariane and Mariner get an honorable mentioning, Raytheon doen't. Why?

There also no mentioning of power grid system bugs. The recent US blackout was a good example.

Re:only 10?

[Anonymous Coward]

I think it would better be called terrorism. But I guess it is impossible by the definition of the word, at least as used today.

Re:only 10?

[ChodeMonkey]

The worst bug ever is the one that's there but you don't know about. Yet.

Re:only 10?

[tmbailey123]

Yea they missed a big one. Aug 14 2003 the worst power outage in years was due to a software bug in the controller relays produced by GE. The bug in the GE Energy's XA/21 did not alarm during the systems failure in Ohio. 50 million people lost power in 8 states. I would put this one pretty much at the top of the list.

But I would argue the bug that deserves to be at the top of the list would be the Y2k "bug". This bug was allowed to persist in industry for years.

Re:only 10?

[bhtooefr]

Actually, open the Flash stuff.

It's mentioned in the race condition animation and the timeline.

Re:only 10?

[ScentCone]

I think it would better be called terrorism.

Why? Because code that the Soviets stole from the US turned out to be (from their perspective) defective? I don't think it's terrorism if my car blows up while you, having stolen it, are driving it around.

More to the point, though, the CIA's objective was to cripple the cash flow of the Soviet Union, an entity that really was busy terrorizing much of the world. Their murderous, oppressive grip on Eastern Europe and attempts at foisting their cheerful utopia on South America and Africa wasn't going to get anywhere without the cash they were trying to raise by selling Siberian natural gas to the west. Making the Soviet government's cold cash sales operation less workable for them was part of what finished pulling the rug out from under that hellish government. That they so desperately needed western cash was a sign of how hollow that regime actually was, and that event just added clarity to the picture. I doubt the CIA expected that exact outcome, but you never really know what someone's going to do with the stuff they steal from you. Makes you wonder what's ticking under the hood in North Korea's squalid little IT universe, doesn't it? No doubt our team, and China's as well, have planted similar things in case they're needed. Tactics like that are going to be more subtle now, probably.

Re:only 10?

[slackmaster2000]

I was thinking of the Y2K bug myself. I can't think of any other "bug" that impacted as many people worldwide. Everyone from children to grandparents knew about the Y2K bug, even if they didn't understand it. I certainly remember my "Y2K Plan"...doing software/hardware inventories and tests, doing paper audits of suppliers, etc. What a pain. Only had issues with a couple systems. The hype factor of this bug alone should have gotten it on the list.

HOWEVER, the Y2K bug wasn't necessarily a bug, it was a known limitation and a lack of forward thinking. Well, I guess that could be considered a bug...just not a specific bug in a specific piece of software.

Re:only 10?

[Daniel_Staal]

It is quite possible that it was both: Someone had mixed up a foot (or more likely a yard) and a meter in the code...

Re:only 10?

[Simon Lyngshede]

I agree, that software did was it was designed to do.

The same can really be said about the Ariane 5 accident, that is if I understood it correctly. As I remember the story, the software loaded into the Ariane 501 rocket was designed for the Ariane 4 series rockets and failed done to the design differences in the two rockets. This was a human error, the wrong software was installed in the rocket, it was not buggy, just designed for at different rocket, that is if I remember correctly. The point is that you can claim that the software i faulty, if you place it in an environment, for which it wasn't designed.

Re:only 10?

[tmbailey123]

true true ... it is a matter of semantics after all.

Strictly applied to today's definition of what is a bug, the original "bug" was not a bug at all ! 8-)

I might not have remembered the power outage of Aug 14 if were not for the fact that it was my 1st day on a new contract as a sys admin. I had been on the job barely six hours when the lights went out literally. While the servers did stay up because they were on generators we had our own local "bug" in the fact that someone had not considered wiring in the environmentals into the generators. We went from 68 degrees F in the raised floor area to 102 in a little over an hour.

Re:only 10?

[maxwell demon]

Why? Because code that the Soviets stole from the US turned out to be (from their perspective) defective?

From the article (emphasis added by me):
Operatives working for the U.S. Central Intelligence Agency allegedly (.pdf) plant a bug in a Canadian computer system purchased to control the trans-Siberian gas pipeline.
So this was a part of the system which was not stolen.

I don't think it's terrorism if my car blows up while you, having stolen it, are driving it around.

I'm pretty sure that if you made a car which deliberately blew up if someone steals it, and a thief died due to this, you'd be convicted for murder.

Re:only 10?

[maxwell demon]

At the time there was a rumor that said it was a human error

Bugs in programs are always human error. Don't forget that the programs are written by humans.

Re:only 10?

[chillmost]

It's not a bug, it was an attack.

In the view of the US government this was probably a feature.

Re:only 10?

[JFitzsimmons]

I was going to mod you up but that comma splice just killed your chances. Just letting you know.

Re:only 10?

[drinkypoo]

You mean, bugs in programs are always due to human error. I hope. Even if software is responsible for a problem (the IDE does something wrong for example) well, it was written by a person. Until computers become sentient, all of the blame must rest on the programmers and the hardware engineers if something unexpected happens.

Re:only 10?

[ScentCone]

I'm pretty sure that if you made a car which deliberately blew up if someone steals it, and a thief died due to this, you'd be convicted for murder

Oddly, there are a lot of hit-or-miss laws on the books that speak to the issue of making your house dangerous to trespassers. It's always struck me as a little odd that there are jurisdictions where someone trespassing can be shot (dead!) without any crime having been committed... but if the trespasser shows up when you're not around, picks your front door lock, and a 100-pound safe falls on his head and kills him, then that's a crime. This usually revolves around the lack of any personal immediate threat being perceived. But how about the guy that steals your car and then dies when he finds out the hard way that the breaks are no good? Given our cultural litigiousness, I'd be surprised if the dead thief's family didn't press a wrongful death suit against the person who had his car stolen.

Re:only 10?

[Timothy Brownawell]

I think it would better be called terrorism.

No, that's when you try to scare people. Here, they were just trying to break things.

Tim

Re:only 10?

[mihalis]

With all due respect, Garfinkel is just wrong about Ariane 5. I read the report on the disaster at the time, and the software worked entirely according to spec. The spec was written for Ariane 4, but the software was reused for Ariane 5 without review. If a review had been undertaken it might have spotted that the potential velocity of Ariane 5 vastly exceeded that of Ariane 4. That was their first mistake. This is software related, but it is not a software bug.

The second problem is that the system which generated the floating point exception and therefore shut down was only needed before launch, but "crashed" after launch. The second mistake was not to shut down systems when they are no longer needed and which, if they fail, can terminate the flight. Not a software bug, more of a basic design flaw.

Stating this was a bug is very common, but is unsupported by the facts. Some commentators have gone further and blamed the language being used (Ada) as causing the rocket to fail, normally followed by a broad hint that some other language (C, Eiffel) would have done better.

This is much worse than simply calling it a bug. The spec for the system that failed said that out of range errors cause exceptions. Exceptions cause the system to shut down. The system shutting down mandates auto-self-destruct of the rocket. This is a matter of public record. Whether this was a good design, even for Ariane 4, is a separate question.

The only way some other programming language might have avoided the disaster is if the programmer violated the spec : in this condition, I am required to shut down, but hey that might be expensive, so I'll do something else instead. That might have been great, or it might have meant the rocket flew right into the ground and killed hundreds of people, we'll simply never know for sure.

Re:only 10?

[glesga_kiss]

It's always struck me as a little odd that there are jurisdictions where someone trespassing can be shot (dead!) without any crime having been committed... but if the trespasser shows up when you're not around, picks your front door lock, and a 100-pound safe falls on his head and kills him, then that's a crime.

Look at the article you just read (or probably didn't ;-). Absorb it. Consider that systems engineered by humans can contain flaws. A human won't shoot the postman or a paramedic ariving unannounced at your door, but the 100-pound safe doesn't differentiate between legitimate and non-legitimate visitors. So, when you kill the eight year old asking for his ball back from your garden, you go to jail.

OK, so you are now thinking, "what if the trap was indoors, behind lock & key?". Then I say, "what if you had dialed 911, were laying with a broken back and the paramedics have to break down your door?".

Makes perfect sense to me.

Re:only 10?

[jmak]

there was also the (in)famous Patriot rounding bug, involving 28 dead and 100 injured people: http://www.ima.umn.edu/~arnold/disasters/patriot.h tml/

Re:only 10?

[glesga_kiss]

This is software related, but it is not a software bug.

If anything, it's process-related, as are the metric/imperial snafus. As someone in the industry, I'd say that an incredibly large number of "bugs" would be avoided if the people producing the software followed decent standards and software development processes.

Re:only 10?

[mattOzan]

Why? Because code that the Soviets stole from the US turned out to be (from their perspective) defective? I don't think it's terrorism if my car blows up while you, having stolen it, are driving it around.

Actually, they didn't steal it--they bought it. From the Canadians. After we refused to sell it ourselves.

These days, the Soviets could probably just have filed an unfair restraint of trade complaint with the WTO!

Seriously, though, culpability here is convoluted. The Soviets had a legitimate need for this technology, and we said, "No, you can't have it." So they went to someone else to buy it, and we sabatoged it. And the only justification is that the Soviet Union was the "evil empire," which had to be destroyed no matter what.

Yeah, yeah, it was a "tense time," and "they wanted to bury us, too." But everytime we talk about how capitalism beat communism because it is inherently better, we should remember all of these incidents which were expressly designed to choke out the Soviet State. Did it wither away because it was inefficient and inferior? Or because we had the strength at the time to hound it into oblivion?

Re:only 10?

[ScentCone]

Did it wither away because it was inefficient and inferior? Or because we had the strength at the time to hound it into oblivion?

I think that, unchecked, they could have kept it appearing alive by continuing to grind satellite countries into the ground - at least for a while. But the huge toll in human misery, and the genuine fear (before we really saw how empty they were) that they'd just keep steamrolling their way across Europe and down into Asia meant that acting sooner was going to prevent a lot of grief. So we did, and it did. The sooner it died, the better for millions and millions of people.

Re:only 10?

[ScentCone]

If you cause anything to blow up in a public place with the intent to injure or kill people, it sure as hell is terrorism.

If the "public place" is something like a school that has been converted into an insurgent weapons dump and mortar launching ground, then causing it to be turned into dust is not terrorism. It's the opposite.

idiot

Try to make the distinction between a rather abstract rhetorical example and the practicalities. The issue is whether or not you're on the hook for what happens when someone misues your stuff, or uses it without our permission.

Re:only 10?

[hunterx11]

The purpose of terrorism is to use terror (hence the word) to achieve some greater political objective. It is not possible to commit terrorist acts covertly, because it is then not possible make any demands. The CIA in this case was not trying to weaken the Soviet Union's resolve, but actually to disrupt their pipeline. You can argue over whether or not it was a bad thing to do, but calling it terrorism is like saying that if a person murders another person he hates, that it makes him a terrorist.

Re:only 10?

[flyinwhitey]

"But everytime we talk about how capitalism beat communism because it is inherently better, we should remember all of these incidents which were expressly designed to choke out the Soviet State."

No, we shouldn't remember them, because the game was being played on both sides.

Please stop making it appear as though this was unique to the US. You know very well the Soviets did far worse, and are only let off because their system failed, and they were forgotten.

Re:only 10?

[flyinwhitey]

"If you cause anything to blow up in a public place with the intent to injure or kill people, it sure as hell is terrorism.

Idiot"

At least you signed your name, that's better than most AC's.

Re:only 10?

[claes]

Because when people blow up pipelines in Iraq today it is called terrorism. Why should it be called something different when someone else did it (note: in peacetime) 30 years ago?

Re:only 10?

[plover]

Oh, absolutely they'll pursue a lawsuit in that case. Any lawyer worth his fee would be all over that like flies on poop.

My father in law was sued because he had removed the guards on his own table saw, and while he was on vacation a trespasser cut off a couple of fingers with it. This wasn't even a case of "setting a booby trap" because he wasn't trying to physically harm anyone.

Doesn't matter if you think it's right or wrong -- our legal system is set up such that it's easy to file a suit.

Re:only 10?

[plover]

Actually, they're not forgotten. For anyone interested in Cold War history, I highly recommend The Sword and the Shield: The Mitrokhin Archive and the Secret History of the KGB. Vasily Mitrokhin was an archivist for the KGB, and was dismayed that much of their history was being destroyed as a part of the routine workings of the KGB. So he made copies of many of the secret cases that he was responsible for storing. Once the iron curtain fell, he dug up his archive and delivered it to the Brits.

The most interesting part (to me) was that it completely validated the claims of various dissidents (such as Solzhenitsyn) as well as the Western governments regarding KGB coverups and lies. After hearing so much propaganda of this sort: "Soviets only steal technology, but the U.S.A. invents it", I was really curious to know what the truth was: exactly how unbalanced was the equation? Were the Soviets really that evil? To read his book and discover that the Western propaganda was almost completely factual was quite a revelation.

Re:only 10?

[Chapter80]

I think the ComAir software bug that ruined people's Christmas Holiday - 2004 (humbug?) was better than the intentional trojan pipeline bug.

But there are other ones, I'm sure, that caused loss of life. I just can't think of any.

Re:only 10?

[edxwelch]

Wasn't that big black out in America a few years back caused by a software bug?

Re:only 10?

[Lars T.]

Yeah, I'm sure all the people killed by American covert operations like this appreciate that they died for a good cause.

Re:only 10?

[Lars T.]

While the secret operations of the Western agencies mostly stay secret for a couple more decades. Not that those that come out aren't bad enough.

Re:only 10?

[Kohath]

Did it wither away because it was inefficient and inferior?

The fact that the Soviets are gone and we're still here, stronger than ever, is a pretty clear (though not 100% conclusive) indication that the Soviets were inferior.

That's why you play the game.

Re:only 10?

[Lars T.]

Nor is anybody able to confirm this "largest non-nuclear explosion in the planet's history".

Re:only 10?

[dbIII]

that they'd just keep steamrolling their way across Europe and down into Asia

I suggest you read some history instead of old propaganda from either side, things are more complex. For one thing, the USSR was really an empire of disparate states (like Austria-Hungary was) and not a distict country.

The previous argument distills down to "we don't like them so we hurt them". At the time both sides were stealing technology - even from allies, and involved in torture and funding obvious terrorist groups (eg. Iran-contra and Bin Laden) so only slippery politics can be used to justify a deliberate act of sabotage like this.

Reagan didn't stop the cold war, he tried to escalate it and was eventually talked down by Thatcher of all people.

Re:only 10?

[smithmc]

  Not to mention the fact that neither the CIA nor the Soviets ever admitted that there was such a bug.

Would you expect them to?

Re:only 10?

[MouseR]

Poloar Lander landing code should be in that list.

Re:only 10?

[Ikester8]

But everytime we talk about how capitalism beat communism because it is inherently better, we should remember all of these incidents which were expressly designed to choke out the Soviet State. Did it wither away because it was inefficient and inferior? Or because we had the strength at the time to hound it into oblivion?

Socialist nations are always and everywhere more inefficient than free-market-oriented nations. The Soviet Union would have withered and died with no interference from the West whatsoever, it may have just taken a little longer. But that is no reason to murder innocents who happen to live there, which, if it was true, seems to have been the point of the software sabotage mentioned above.

Re:only 10?

[YoungHack]

I don't think they should count the "pipeline bug."

That was a trojan. It was a deliberate attack on their system by an enemy. It didn't even arrive via the now classical "worm" or "virus" route, which would have implied that a "bug let it in the door." No, this one was deliberately planted carefully at the root. It's not a bug, it was an attack.

What amazes me is how people are so proud of that attack. If any country sabatoged materials used in a pipeline in the States, it would be all terrorism and the horrors of ecological damage caused my those evil foreigners.

For some reason when we do it, it is cool.

Re:only 10?

[quadrocerebra]

anyone think of any others?
How about Windows 95?

Re:Microsoft's striking absence

[jzeejunk]

That's because it's quality vs. quantity.

Well, that makes me feel better

[PIPBoy3000]

Bringing down the company's intranet countless times over the years almost seems like an amusing little distraction. No one died, nothing blew up, and I've even managed to keep my job. It must be that people are getting used to these "software bug" excuses for the various problems that pop up with computers. I'll have to remember that for next time.

Caller: "My computer exploded and I'm bleeding profusely!"
911 Operator: "Must be a software bug."

Worst Bug #1

[phase_9]

The fact the site appears to be buggered... :|

Re:Worst Bug #1

[richy freeway]

Getting that problem here. Site renders fine in IE but not Firefox.

Re:Worst Bug #1

[richy freeway]

For those having the same problem, the "printable" link works fine in Firefox.

http://wired.com/news/print/0,1294,69355,00.html

Re:Worst Bug #1

[stephend]

Remove the parameter, the bit after ".html," and it works fine.

hey, we're all still here

[Colin Smith]

So nobody's hit on the really big one yet.

Re:hey, we're all still here

[meringuoid]

So nobody's hit on the really big one yet.

Um, what really big bug?

FROM: it_director@norad.mil
TO: president@whitehouse.gov
SUBJECT: New systems

Mr President, I'm pleased to report that the new national radar systems are fully tested and operational.

FROM: r.q.hacker@norad.mil
TO: it_director@norad.mil
SUBJECT: possible bug in calendar module
UNREAD

Hey, we may have a problem in the calendar system. I suspect there's a memory allocation issue here, we've been seeing occasional bugs in testing. Might be worth delaying rollout.

FROM: president@whitehouse.gov
TO: SACEUR@nato.int
SUBJECT: Re: Your plans

Please find attached confirmation that your proposed military exercises to be held on Feb 29th have been authorised. I look forward to evaluating the performance of our strategic defences in a full-scale battle simulation.

Re:hey, we're all still here

[freaktheclown]

Please find attached confirmation that your proposed military exercises to be held on Feb 29th have been authorised. I look forward to evaluating the performance of our strategic defences in a full-scale battle simulation.

Apparently, George Bush is now British.

TEH MOST RETARDED IDEA EVAR

[Anonymous Coward]

Not everyone with a video camera can go out and film a network TV series. Does that mean we should require them to become licensed before they can operate their cameras?

No.

There will always be a difference between professional and amateur grade. You'll never need a license to run a compiler.

Re:TEH MOST RETARDED IDEA EVAR

[Anonymous Coward]

There will always be a difference between professional and amateur grade.

That's why I only drive professional grade. http://www.gmc.com/

Moth.

[Poromenos1]

The moth was trapped, removed and taped into the computer's logbook with the words: "first actual case of a bug being found."

Why would they say that, if the term "bug" didn't exist? I mean, you wouldn't find a rat in your car and say "First actual case of a car 'rat' being found" if you didn't use it as a term to indicate something. You'd just say "this bug caused computing errors". I smell a car rat.

Re:Moth.

[sprouty76]

Sounds to me like the engineers thought problems may have been caused by physical bugs without having actually seen one, at least up until this point.

Re:Moth.

[eserteric]

I guess that they figured there was the possibility that a bug could get in there and screw things up. And so once it happened, it moved from theory to reality and hence the "first actual case".

Re:Moth.

[BridgeBum]

The term predates computers. In the original usage, any sort of mechanical device or system could have bugs.

http://www.silicon.com/software/webservices/0,3902 4657,10005407,00.htm

Re:Moth.

[DeadVulcan]

Why would they say that, if the term "bug" didn't exist?

The term "bug" has been around since long before that incident. I think the comment was just a joke.

Re:Moth.

[wcrowe]

Not a lot of people know that.

That's because it's not true. The term "bug" originated in the nineteenth century to mean a mechanical defect, and predates electricity.

Re:Moth.

[Goaway]

Thank you, Captain Obvious, for re-stating the original poster's point as if it was your own insight.

Re:Moth.

[Shaper_pmp]

I thought every Slashdotter would know this wasn't the correct etymology of the word "bug" - that's why it was "the first occurrance of an actual bug" being found. IIRC the word "bug" (in the sense of a problem or glitch) has been in use since Newton's time...

Re:Moth.

[Kunta Kinte]

The term predates computers. In the original usage, any sort of mechanical device or system could have bugs.

The thing is the term 'bug' predates even that definition. Bug was simply slang for problem,

Eg. Saying "You always seem to have a bug!" to a person that complains a lot. That example is from a short story written in the 1920's. The original usage probably came from the fact that bugs are probably a major annoyance back then.

Re:Moth.

[zoeblade]

The moth was trapped, removed and taped into the computer's logbook with the words: "first actual case of a bug being found."

Why would they say that, if the term "bug" didn't exist? I mean, you wouldn't find a rat in your car and say "First actual case of a car 'rat' being found" if you didn't use it as a term to indicate something. You'd just say "this bug caused computing errors". I smell a car rat.

That's right, the term bug has been used before the first literal case of one being found in a computer. That famous anecdote is just a case of people being excited about a pun coming true. Wikipedia has some information on the etymology of the word, as does the Jargon file.

Re:Moth.

[fm6]

People love etymological folklore. Very often you see stories repeated over and over that not only don't have any documentation, but don't make any sense when you examine them closely. They're like urban legends — they persist just because they appeal to people on some obscure level.

My favorite is "starboard". I can show you a ton of books, including some authoritative-looking nautical dictionaries, that insist that this is an old term for "steering oar", from before the invention of the rudder, when ships were steered by an oar on the right side. But if you look at nautical terminology like "aboard", "overboard", etc., you soon realize that "board" doesn't mean a piece of wood, it means the side of a vessel. So the smarter lexicographers say that "starboard" used to mean the side of the ship where the steering oar was. Which makes sense to me — except it's not well-documented either, and I've seen even more obscure explanations for the word.

Re:Moth.

[Frazbin]

I hear tell bugs are still a major annoyance in the "out-side", if only for those foolish enough to venture there without their Hostile Enviornment Suits. Moe-skeet-ohs, I've heard, can be particularly annoying to those unequipped with personal force fields. Of course, I couldn't tell you first hand. I'm neither an anthropologist nor a historian-- the concerns of our primitive forefathers are not my domain, and I'm not about to test it for myself.

Re:Moth.

[wcrowe]

That may be true, however it doesn't explain why the term is associated with computing.

Er, yes, it does.

Re:Moth.

[Blakey Rat]

The word "bug" did exist. They wrote that there as a *JOKE*.

I don't think anybody's claimed that the word "bug" didn't exist before computers. People have been "working the bugs out" for probably a hundred years or more. You could reasonably claim that was the first use of the term "computer bug" possibly, but adding the word "computer" doesn't change the word "bug."

From answers.com:

http://www.answers.com/bug&r=67

A persistent error in software or hardware. If the bug is in software, it can be corrected by changing the program. If the bug is in hardware, new circuits have to be designed.

Although the derivation of bug is generally attributed to the moth that was found squashed between the points of an electromechanical relay in a computer in the 1940s, the term goes back to the 1800s to refer to flaws in mechanical systems. See buggy, bug fix, software bug, broken and Web bug. Contrast with glitch.

A Note from the Author
On October 19, 1992, I found my first "real bug." When I fired up my laser printer, it printed blotchy pages. Upon inspection, I found a bug lying belly up in the trough below the corona wire. The printer worked fine after removing it!

Re:Moth.

[Joe the Lesser]

Actually, the grandparent's link agrees with you:

The term 'bug', used to mean an irritant or unpleasant thing, has been part of the English language since the sixteenth century.

Re:Moth.

[fm6]

Pity you're an AC. Otherwise, I could ask you what "bord" beans in Danish. That's the crucial term, since the confusion is over whether "board" means "piece of wood" (its most usual meaning in English) or "side of the vessel".

Re:Moth.

[wcrowe]

Another quality argument. Jesus.

It's generally a waste of time to argue with fools. In his book, "Why Things Bite Back: Technology and the Revenge of Unintended Consequences," Random House,1996, Dr. Edward Tenner quotes Thomas Edison as using the term "bugs" as early as 1878, for flaws in a system. Tenner states the word was already a common "shop" term in Edison's time for unexpected systems faults. The carryover to computers (certainly complex systems) is almost unavoidable.

Of course, I'm sure you prefer your urban legend version to true etymological research.

Please try to pay attention

[mister_llah]

1995/1996 -- The Ping of Death. A lack of sanity checks and error handling in the IP fragmentation reassembly code makes it possible to crash a wide variety of operating systems by sending a malformed "ping" packet from anywhere on the internet. Most obviously affected are computers running Windows, which lock up and display the so-called "blue screen of death" when they receive these packets. But the attack also affects many Macintosh and Unix systems as well.

===

WinNuke made it...

Re:Please try to pay attention

[Emrikol]

I'm sorry, but that's not WinNuke.

WinNuke worked via NetBIOS problems. Check the wikipedia article for more info.

Re:Please try to pay attention

[mingot]

Winnuke didn't have anything to do with NetBIOS (other than the fact that netbios left a port open that the attacker could connect to).

Connecting to any open port and sending OOB data would have the same results.

Bug or User error?

[Lucan_UK]

The last one on the list is this

"Multidata's software allows a radiation therapist to draw on a computer screen the placement of metal shields called "blocks" designed to protect healthy tissue from the radiation. But the software will only allow technicians to use four shielding blocks, and the Panamanian doctors wish to use five.

The doctors discover that they can trick the software by drawing all five blocks as a single large block with a hole in the middle. What the doctors don't realize is that the Multidata software gives different answers in this configuration depending on how the hole is drawn: draw it in one direction and the correct dose is calculated, draw in another direction and the software recommends twice the necessary exposure.

At least eight patients die, while another 20 receive overdoses likely to cause significant health problems. The physicians, who were legally required to double-check the computer's calculations by hand, are indicted for murder. " ... to me that sounds like a user not using the software correctly..

Re:Bug or User error?

[Thud457]

Sounds like a design flaw (or limitation) coupled with user error. They probably replace blown fuses with pennies, too.

Re:Bug or User error?

[Alizarin Erythrosin]

What the doctors don't realize is that the Multidata software gives different answers in this configuration depending on how the hole is drawn: draw it in one direction and the correct dose is calculated, draw in another direction and the software recommends twice the necessary exposure.

Emphasis mine... but that sounds like a software bug to me. Doesn't matter that only 4 shielding blocks were allowed. That's a limitation. The argument of whether or not a "work-around" as used by the doctors should have been allowed by the software in the first place is not the issue here. The issue is that drawing the same thing in 2 different directions causes 2 different results.

Re:Bug or User error?

[14erCleaner]

There are a lot of other "bugs" like this one in the records; for example, one of the Airbus crashes happened because the crew confused descent rate with descent angle in their autopilot settings. Another crash was attributed to pilots fighting the autopilot for control (again, a bad interface).

If you enjoy reading about other people's software screwups, checkout Risks Digest, which contains decades worth of this sort of stuff.

Re:Microsoft's striking absence

[IdleTime]

Yes, I saw that too and I guess they have forgotten the most devastating MS bug which is present in all releases from NT 3.1 and at least up to 2k. I haven't tested XP.
I couldn't find the description right now, but I'm sure others know the bug. The one were you can basically type a special textfile using type-command or similar and will basically BSOD the machine. The file consists of tabs, spaces and newline/carriage return pairs and nothing else. MS never fixed the bug.

I liked the last one

[Spy der Mann]

The doctors wanted to trick the software. But then the software didn't work as intended. A really unexpected outcome, really :P

Re:I liked the last one

[Doctor Memory]

As every wise developer knows: If you lie to the computer, it will take its revenge.

Worst _software_ bugs, huh ?

[Ihlosi]

I didn't know that the Pentium FP bug was a software bug.

Oh wait, it wasn't ...

Re:Worst _software_ bugs, huh ?

[rtaylor]

[quote]I didn't know that the Pentium FP bug was a software bug.[/quote]
Indeed it was. Microcode in the CPU is software just as much as the assemby used for your Bios is software or the embedded code running in the microcontroller of your microwave is software.

Re:Worst _software_ bugs, huh ?

[squiggleslash]

The bug was about missing data in a lookup table. Intel said the problem was caused by a bug in the script designed to populate that table when the CPU was being designed, though legend has it that someone erronously "proved" that the data wasn't needed. So, I guess, either way you look at it, be it the script, the table, or the alleged logic flaw, it's a software, not a hardware bug (or at least, it's a bug caused by software.)

All hail the mighty Soviet engineering

[snowwrestler]

Engineers so good they had to steal their pipeline control software. And, apparently, a ton of other Western engineering too.

Re:All hail the mighty Soviet engineering

[z0idberg]

yeah its funny how superpowers tend to bend the rules when it comes to the subject of oil.

some steal software, others "liberate" countries.

Re:All hail the mighty Soviet engineering

[Golias]

... when it comes to the subject of oil.

some steal software, others "liberate" countries.

Iraq has free elections and a Constitution, while I'm still paying damn near three bucks a gallon for gas.

If the "liberation" of Iraq was a sham for the sake of stealing oil, then the plan went horribly wrong, because they really have been liberated and we haven't managed to steal a single barrel.

Re:All hail the mighty Soviet engineering

[djdavetrouble]

Silly Citizen, the plan was to make all of Bush's texas oil cronies richer than ever,
from an artificial shortage....
at the expense of the regular guy, of course.

Re:All hail the mighty Soviet engineering

[drinkypoo]

I had a really hard time trying to explain this to one of the mindless conservative types I know from irc. He's a Neal Boortz fan, that should tell you all you need to know... OPEC prices rise, American oil prices rise. He was unable to grasp this simple concept. Fuel prices are at [well, right now, just below] record highs, and oil companies have posted record profits. I'm thinking there has to be a connection.

Re:All hail the mighty Soviet engineering

[F_Scentura]

Yes, the Soviets have always been well known for their freedoms.

Re:All hail the mighty Soviet engineering

[Golias]

Silly Citizen, the plan was to make all of Bush's texas oil cronies richer than ever,
from an artificial shortage....

Nice of Venzuela to disrupt their oil exports for Bush like that.
Oh, and the people who called down hurricane Katrina need credit for their part in this, too.
Not to mention all those Democrats who have limited our refinery capacity in key parts fo the country out of "environmental" concerns.

Looks like Bush the Younger has foreign governments, the Democrats, and even GOD HIMSELF working to make his oil buddies richer. Wow, talk about a well-connected politician!

Re:All hail the mighty Soviet engineering

[djdavetrouble]

Now you are thinking along the right lines! You get a gold anodized tin foil hat for that !

Intel FP divide is -not- a software bug

[RootsLINUX]

Why do they have the Intel Pentium floating point divide error listed as a bug? That was a hardware design error in the circuit, it was not a software bug. Of course it caused software to behave unexpectedly, but still I'm surprised that Wired put that one in there.

Re:Intel FP divide is -not- a software bug

[briansmith]

Today's microprocessors have software embedded inside them. The floating-point divide error was caused by a bad lookup table in the microcode that runs on the chip.

Re:Intel FP divide is -not- a software bug

[stephend]

Where does hardware stop and software start? The Pentium converts x86 instructions into lower level, RISC-like insructions internally. It was an error in this micro-code that caused the error. So yes it was burned onto a chip rather than read from a disc but I'd still say it was software.

Re:Intel FP divide is -not- a software bug

[wcrowe]

I'm surprised that Wired put that one in there.

I'm not. Some of those people at Wired think computers work on magic crystals.

Re:Intel FP divide is -not- a software bug

[ameline]

That is correct -- Modern processors perform divides by having a reciprocal estimate lookup table.
This table produces an estimate with 12 or so good bits of precision. Iterative refinement (typically microcoded) then produces the rest of the bits. After that the reciprocal is multiplied in, and you get the result.

More recently this has been somewhat exposed, as most all modern processors have a reciprocal estimate instruction which executed in a single cycle. This is very useful if, for example, you want to normalize a bunch of normal vectors before passing them into the graphics pipeline. 12 bits is almost always enough for this purpose, and the reciprocal sqrt instruction is very much your friend here. So something that was dominated by the ~60 cycles of 1.0f/sqrt(sum_of_squares) becomes 1 cycle. Total speedup is about 10x -- and it's vectorizable -- the SSE unit will do a vector rsqrte.

My understanding of the pentium fdiv bug is that a section of the reciprocal estimate table had bad data in it.

This, in my opinion, counts as software, as would the microcode. If the bug had been in the multiplier, adder, or logic circuitry of the lookup table, then it would count as hardware.

Many, if not all the complex ciscy instructions are implemented in microcode -- so I believe that a bug in them would count as a software bug.

Re:Intel FP divide is -not- a software bug

[g!sys1]

This is a debatable issue. The look-up table itself is hardware, but the masks for the table have been created with a perl script. Someone apparently just wanted to `clean up a minor bug' in that script after validation, without re-testing it. Turns out this minor bug caused the whole fdiv-bug issue. So you could equally well argue that it was a software bug causing a hardware bug.

Gunnar

Re:Intel FP divide is -not- a software bug

[DrJimbo]

AC said:

Why would I want to normalize normal vectors?

I think you may already know the answer, but just in case you don't ...

The word normal is used in two senses in the original sentence. A normal vector is a vector that is perpendicular to (or normal to) a surface. To normalize a vector is to set its length to one by dividing by its length.

Mathworld explains it here where they say:

... unit norm vectors might be called "normalized normal vectors" without redundancy.

Look everyone, someone didn't RTFA!

[tgd]

Since that WAS one of the ten.

The meat of the article...

[cytoman]

July 28, 1962 -- Mariner I space probe. A bug in the flight software for the Mariner 1 causes the rocket to divert from its intended path on launch. Mission control destroys the rocket over the Atlantic Ocean. The investigation into the accident discovers that a formula written on paper in pencil was improperly transcribed into computer code, causing the computer to miscalculate the rocket's trajectory.

1982 -- Soviet gas pipeline. Operatives working for the U.S. Central Intelligence Agency allegedly (.pdf) plant a bug in a Canadian computer system purchased to control the trans-Siberian gas pipeline. The Soviets had obtained the system as part of a wide-ranging effort to covertly purchase or steal sensitive U.S. technology. The CIA reportedly found out about the program and decided to make it backfire with equipment that would pass Soviet inspection and then fail once in operation. The resulting event is reportedly the largest non-nuclear explosion in the planet's history.

1985-1987 -- Therac-25 medical accelerator. A radiation therapy device malfunctions and delivers lethal radiation doses at several medical facilities. Based upon a previous design, the Therac-25 was an "improved" therapy system that could deliver two different kinds of radiation: either a low-power electron beam (beta particles) or X-rays. The Therac-25's X-rays were generated by smashing high-power electrons into a metal target positioned between the electron gun and the patient. A second "improvement" was the replacement of the older Therac-20's electromechanical safety interlocks with software control, a decision made because software was perceived to be more reliable.

What engineers didn't know was that both the 20 and the 25 were built upon an operating system that had been kludged together by a programmer with no formal training. Because of a subtle bug called a "race condition," a quick-fingered typist could accidentally configure the Therac-25 so the electron beam would fire in high-power mode but with the metal X-ray target out of position. At least five patients die; others are seriously injured.

1988 -- Buffer overflow in Berkeley Unix finger daemon. The first internet worm (the so-called Morris Worm) infects between 2,000 and 6,000 computers in less than a day by taking advantage of a buffer overflow. The specific code is a function in the standard input/output library routine called gets() designed to get a line of text over the network. Unfortunately, gets() has no provision to limit its input, and an overly large input allows the worm to take over any machine to which it can connect.

Programmers respond by attempting to stamp out the gets() function in working code, but they refuse to remove it from the C programming language's standard input/output library, where it remains to this day.

1988-1996 -- Kerberos Random Number Generator. The authors of the Kerberos security system neglect to properly "seed" the program's random number generator with a truly random seed. As a result, for eight years it is possible to trivially break into any computer that relies on Kerberos for authentication. It is unknown if this bug was ever actually exploited.

January 15, 1990 -- ATT Network Outage. A bug in a new release of the software that controls ATT's #4ESS long distance switches causes these mammoth computers to crash when they receive a specif

Re:The meat of the article...

[meringuoid]

The resulting event is reportedly the largest non-nuclear explosion in the planet's history.

The former dinosaurian population of the Yucatan Peninsula might disagree...

Re:The meat of the article...

[arrow014]

I actually did a research report on the Therac-25 incident while I was in Software Engineering class a few semesters ago (I was also in Technical Writing at the time, so I could kill two assignments with one report!) ;-) The details of the incident(s) are actually quite fascinating and sometimes spine-chilling.

Here's the report in PDF if anyone's interested: reportfinal.pdf

And in HTML for those of you who prefer it: link

Re:The meat of the article...

[josu]

That's during the planet's pre-history, not history.

Re:The meat of the article...

[endersdouble]

Not to mention anyone at Tunguska.

Re:The meat of the article...

[glesga_kiss]

This _is_ the article -- it should be modded "informative", not "funny."

"funny" gives no karma to the poster, hence it's use here. It would probably make sense for a new moderation type to cover this sort of post, that perhaps even gives negative karma.

Re:The meat of the article...

[pe1chl]

The error is in the article.

The actual linked item says: "The result was the most monumental non-nuclear explosion and fire ever seen from space," he recalls, adding that U.S. satellites picked up the explosion.

This is of course something completely different.

Whatever happened to the US Navy?

[Lead Butthead]

Something about their latest toy... ahm, ship that had to be towed back to port because Windows NT they used to run everything on the ship keep blue screening.

Re:Whatever happened to the US Navy?

[Anonymous Coward]

Incorrect on a couple of points:

First, the ship did not need to be towed back into port, though it did sit dead in the water for a bit (if I recall correctly). The story was bandied about the UNIX support group I was part of at one of the shipyards that built Aegis class cruisers. The ship this happened to was an Aegis.

Second, the problem was in the software running on top of Windows; it failed to properly bounds check operator input and allowed a division by zero error, which in turn caused a cascade failure of almost all the critical systems on the ship.

The Navy still decided to switch to Windows instead of HP/UX for the fleet. :P

Re:Whatever happened to the US Navy?

[Phanatic1a]

There are no "Aegis class" cruisers. Aegis is a ship combat system, specifically an AN/SPY-1 radar system, a computer based command-and-control system, and one of a number of missile systems either in current-tech VLS cells or older cylindrical magazines and launchers.

The Aegis system can be found on Ticonderoga-class cruisers and Arleigh Burke-class destroyers in the USN, Kongo-class destroyers in the IJN, and some Spanish frigate whose designation I forget.

The ship we're talking about is the USS Yorktown, CG-48, and the problem was pretty much as you describe. A user input an erroneous zero value for some quantitity (fuel pressure, I think), and the system ate itself and took the engines offline.

The Yorktown was decommissioned last year. Shame that the practice of using Windows in ship-critical systems wasn't.

Re:Whatever happened to the US Navy?

[OldManAndTheC]

That wasn't a bug, it was a feature. Windows NT was the Soviet response to the "gas pipeline" bug.

We may have one the Cold War, but whenever a Windows system boots up, ex-KGB agents laugh derisively and toast each other with tiny glasses of vodka.

Re:Whatever happened to the US Navy?

[Anonymous Coward]

> First, the ship did not need to be towed back into port, though it did sit dead in the water for a bit ..

"The ship had to be towed into the Naval base at Norfolk, Va., because a database overflow caused its propulsion system to fail, according to Anthony DiGiorgio, a civilian engineer with the Atlantic Fleet Technical Support Center in Norfolk."

"Using Windows NT, which is known to have some failure modes, on a warship is similar to hoping that luck will be in our favor," DiGiorgio said

Curiously enough DiGiorgio later wrote a retraction and 'resigned` from the Navy as did Vice Adm. Henry Giffin.

"DiGiorgio denies reported statements"

"I did not say that the Yorktown was towed into Norfolk"

http://www.gcn.com/17_20/news/33292-1.html

"Ron Redman, deputy technical director of the Fleet Introduction Division of the Aegis Program Executive Office, said there have been numerous software failures associated with NT aboard the Yorktown."

"Refining that is an ongoing process," Redman said. "Unix is a better system for control of equipment and machinery, whereas NT is a better system for the transfer of information and data. NT has never been fully refined and there are times when we have had shutdowns that resulted from NT."

"The Yorktown has been towed into port several times because of the systems failures" [Ron Redman - Aegis]

"This is the only time this casualty has occurred and the only propulsion casualty involved with the control system since May 2, 1997, when software configuration was frozen," Vice Adm. Henry Giffin

> Second, the problem was in the software running on top of Windows

But the software made a call to Windows to divide by zero and Windows made a call to the fpu which did just that.

http://www.slothmud.org/~hayward/mic_humor/nt_navy .html

http://www.jerrypournelle.com/reports/jerryp/yorkt own.html

Re:Whatever happened to the US Navy?

[rabtech]

As has already been pointed out this was NOT a Windows bug of any kind:

http://www.gcn.com/17_32/news/33639-1.html

I'm sure the fact that it was a test/proof-of-concept ship put out to sea without ANY formal software testing or even basic data safety checks isn't part of your "haha Windoze sux" fable but we can't let the truth get in the way of Microsoft-bashing now can we?

Re:Whatever happened to the US Navy?

[Phanatic1a]

From the very article you link to:

"It still boggles the mind that any divide by zero error on NT would cause a system to crash, let alone" 27 end-user terminals, said Gil Young, corporate network engineer for a systems integration firm in Orlando, Fla. "I don't care what operating system, computer or application I'm using, I should be able to type in a zero and expect the computer not to crash, especially if that zero is to represent a closed valve."

Re:Whatever happened to the US Navy?

[TheRealSlimShady]

Heard of an unhandled exception? i.e. a divide by 0 error should get trapped by the application. If the application doesn't handle it, the OS has to. I believe the default behaviour of NT in this situation is to blue screen. If the application had proper error handling (or input validation) it would have been fine...

Re:Whatever happened to the US Navy?

[uxo]

That reminds me: in 1988 the U.S.S. Vincennes Aegis cruiser accidently shot down an Iranian passenger jet. The incident was at least partially due to the electronics used to identify hostile aircraft.

Re:Whatever happened to the US Navy?

[guet]

I believe the default behaviour of NT in this situation is to blue screen. If the application had proper error handling (or input validation) it would have been fine...

The same could be said for the OS.

Re:Whatever happened to the US Navy?

[CComMack]

s/IJN/JMSDF/ in your second paragraph, there.

As for who else is using Aegis, I refer you to http://en.wikipedia.org/wiki/Aegis_combat_system

Re:Whatever happened to the US Navy?

[49152]

>Heard of an unhandled exception? i.e. a divide by 0 error should get trapped by the
>application. If the application doesn't handle it, the OS has to. I believe the
>default behaviour of NT in this situation is to blue screen.

Oh, please...

NT might be a bug ridden piece of shit, but it was not designed *that* bad.

The default behaviour of NT (and also the NT derivates 2000, 2003 and XP) is to terminate the application and show a dialog box with a warning.

The only way to get NT to blue screen because of an unhandled exception, would be if the bug was in code running in kernel mode, this usually means the core parts of the OS itself and the device drivers.

You get what you pay for

[cryptoguy]

Consider how much software is written by people with five years or less of professional experience, on short schedules, with no time allocated for continuing education. If software projects weren't always rush jobs, and on relative shoestring budgets, the quality would be better. If continuing education for programmers was a priority, quality would be better. If a couple of decades of experience was properly appreciated, quality would be better.

Re:You get what you pay for

[jurt1235]

If continuing education for programmers was a priority, quality would be better.

This also requires more than the current courses which are pretty much level starter course. It is sad that after a few days being busy with a language before a course, you will already find mistakes/bugs or just better ways to do it than what is promoted in the course.

For example after a 3 day crash course (I missed day 1, else it would have been 4 days), I became a certified Stellent developer. So a "real" test at the end to determine if you are worth it or not.

Re:You get what you pay for

[PakProtector]

If continuing education for programmers was a priority, quality would be better.

This also requires more than the current courses which are pretty much level starter course. It is sad that after a few days being busy with a language before a course, you will already find mistakes/bugs or just better ways to do it than what is promoted in the course.

Amen to this. I have not started college yet, but I plan to enroll for Computer Science and Engineering at UF. My roommate (who happens to be my 24 year old uncle) is in the Computer Science course, and informs me that my knowledge is about on par with being in my Junior Year (I need the higher level math and stuff like Operating Systems, which I am actually purchasing a copy of Modern Operating Systems to learn, and Discrete Electronics, and a few other course that you don't get till your Fourth Year) in the program. And this is just from being a lazy git who wanted to write a MUD. From what I have been told, the Intro to Computer Science Class, a Weedout class, at UF, has a 60 to 70 percent failure rate, because a majority of the persons who opt to take Computer Science have the mindset "I can use AIM and Word, so Mom thinks I should do Computers!", or worse yet, "Wow, I can make how much right out of school to sit on my ass all day?"

And don't even get me started on the fact that until you get to something 'Higher Level' they teach you with Java instead of something good and mid-level, like C. You won't even touch Machine Code till your third or fourth year, depending on which order you take certain classes.

I've got one

[distantbody]

Probably more a case of bad design than a coding error, but in sure many of us have experienced the crippling pain of resolution changes in games etc. that do now defualt back to the original working one, leaving you with an unintelligible smear of a display, forcing you to have to fumble around blindly, vainly hoping that the menu sounds will help you restore the resolution. That last happened to me with NFSU2, and it is f***ing unacceptable for any non-amature software maker to cause this type of rage.....!

This bug reminds me of a Dilbert comic

[technoextreme]

1988-1996 -- Kerberos Random Number Generator. The authors of the Kerberos security system neglect to properly "seed" the program's random number generator with a truly random seed. As a result, for eight years it is possible to trivially break into any computer that relies on Kerberos for authentication. It is unknown if this bug was ever actually exploited.

Hehehe.... This reminds me of a Dilbert cartoon. Here is what I can remember:
Some guy: And here is our random number generator.
Another guy: 2 2 2 2 2 2 2 2 2 2 2 2.
Dilbert: That isn't very random though.
Some guy: He is randomly getting the same number.
Anyone actually know which comic I am thinking of.

Re:This bug reminds me of a Dilbert comic

[Yahweh Doesn't Exist]

if you subscribe (I don't any more) you can probably find it by searching for "random".

I think the last line is actually something like
Dilbert: That isn't very random though.
Some guy: That's the trouble with randomness - you can never tell.

Re:This bug reminds me of a Dilbert comic

[Lucan_UK]

Here is the Dilbert Strip... Enjoy
http://www.geocities.com/raptorred42/Dilbert0001.j pg

Re:This bug reminds me of a Dilbert comic

[BigZaphod]

I love that one. It's actually hanging on my fridge at home. :-)

Re:This bug reminds me of a Dilbert comic

[dcam]

Yeah. That is one of my favourite cartoons.

1995/1996 -- The Ping of Death

[alexhs]

Aah! I see you have the machine that goes 'ping'.
This is my favourite.

:)

Why not both?

[brouski]

I've read about this instance before, and I think it's attributable to ignorance on both the user and the developer. The software developer in this case knows the life of a human being is resting on his code, so it should have been nigh impossible to "trick" the software into allowing anything other than what the specs said it could do.

Re:Why not both?

[Lucan_UK]

I agree... to a certain extent. I think this instance shouldnt be blamed on the developer but on on the testing team... Im sure that a piece of software like this had to have been tested... so why was it not found?

A developer is really only as good as the testing team telling him its wrong!

Re:Why not both?

[6031769]

You are assuming tight, correct specs - a genuine rarity.

Re:Why not both?

[Coryoth]

You are assuming tight, correct specs - a genuine rarity.

Which is, in a sense, the problem. If you are developing a life critical application, then spending a few iterative design rounds tightening up and testing the specification are more than going to pay off in terms of potential errors caught. There are formal languages for specifications (so you can be precise and not rely on an English language "description" of what is required), and those formal languages are amenable to analysis. In practice just sitting down and formalising requirements into this language goes a very long way toward determining where ambiguities lie, and which parts need to be checked with the client to be certain you've captured the requirement correctly. It's, in a sense, similar to doing iterative design by coding up a quick prototype and using the need to formalise your ideas into code to get a better idea of where the issues lie. If people took specification a little more seriously, at least as far as being a little bit more rigorous and formal, I think projects in general for which safety or security is important would be far better off.

Jedidiah.

Re:Why not both?

[QuestorTapes]

>> You are assuming tight, correct specs - a genuine rarity.

> There are formal languages for specifications (so you can be precise and not
> rely on an English language "description" of what is required), and those
> formal languages are amenable to analysis. In practice just sitting down and
> formalising requirements into this language goes a very long way toward
> determining where ambiguities lie, and which parts need to be checked with
> the client to be certain you've captured the requirement correctly.

Exactly correct. But the fact that this does not happen is in part driven by how businesses create these kinds of products. I've been offered -many- opportunities to design similar, life-in-the-balance medical software. The only reason I didn't take any of them was because -I- knew the kind of qualifications a designer of this kind of thing should have, and I don't have them. But many of these firms just turn around and hire someone who is not even qualified to -know- he isn't qualified.

Businesses offer it not to professional developers of medical software, but to people who have used a cool programming language or tool that one of their engineers read about in an article in a vendor magazine.

Re:Why not both?

[Coryoth]

Come now, this was a mistake on the part of the specification and design team. Unless you have a specification that says "you cannot do X" then how is the testing team to know
(1) To try and do X to check if it is prevented
(2) That X is incorrect if they do manage to do it
And of course had the specification covered this, then the programmers, assuming they were any good, would have to account for it in their code, and the condition would be included in the test process and checked in testing.

If the correctness of your system is important (like with a life critical system) then expending effort trying to get your specification as complete as possible is going to help a lot. That means that your specification probably ought to be a formal one so you can adjust it if required and analyse the effects of those adjustments.

Jedidiah.

Re:Why not both?

[Vellmont]

Well, in this case I'd put the blame soley on the doctors. Whenever you design something you have to make assuptions about how it's going to be used and by whom. This isn't a device to be used to untrained joe sixpack. Think of it like any dangerous piece of equipment.

Let's say you design a paper cutter that is rated to cut 500 sheets of paper with a guard around it to prevent people from accidentally cutting off their fingers. Then someone removes the guard because it gets in the way when they want to cut 1000 sheets of paper. This same person then cuts off his fingers because the guard was removed. Who's to blame, the guy who designed the guard to be removable, or the guy who used the device like it was never intended to be used? My blame goes to the guy who removed the guard.

Trying to "trick" the software into doing what you want (and were told it wouldn't do) is just a bad bad bad idea when you're using it to calculate something as important as radiation dosages. Anyone who's good at writing software wants to make it perfect, i.e. every possibility is accounted for. Software is flexible enough for us to think this is possible. But what else in the world is designed in such a way that it's not possible to injure someone if used by someone in a wrong way?

Time for stressing more on formal specifications

[ashtophoenix]

I found it a hard subject in school and have never used it practically, but it seems to be the only SURE way of proving the correctness of a program. Shouldn't we be using it, at least in real-time mission-critical applications now. I think it needs to be stressed a lot more in school from the start, as compared to topics like web development and java and all other pragmatic things that can be learned more easily.

Re:Microsoft's striking absence

[Shaper_pmp]

Jeuss Christ. I'd somehow never heard of this bug, and I've been developing for Windows machines for years.

How on earth was such a basic and low-level bug ignored for so long? It doesn't seem like rocket-science to fix it with a small bounds-checking if statement!

Oops! PoD ! WinNuke

[mister_llah]

Ahh, it sounded like WinNuke, apparantely it is different, thanks for the info :)

I decided to look up Ping of Death, too... it pretty much cleared up any confusion, between the 2 articles...

Re:Oops! PoD ! WinNuke

[Emrikol]

Well, you were half right. I guess nuke is used as a term for the PoD. My half-mistake too.

Invisible, frictionless machinery

[snowwrestler]

But machinery nonetheless, designed and built by humans. As such it is not necessarily any more reliable than physical engineering--and its harder to verify.

I voted this morning on an electronic machine that did not produce a paper ballot. You better believe software security and reliability are on my mind.

WOW.

[CDPatten]

Since MS wasn't on the list, I'm sure we are going to see allot of flames!

Re:WOW.

[vertinox]

Since MS wasn't on the list, I'm sure we are going to see allot of flames!

Well, what OS do you think they put on the Soviet Pipeline? ;)

Re:WOW.

[CDPatten]

LOL. I thought back in 82 MS wasn't evil yet?

Re:WOW.

[RedNovember]

I would have thought Windows XP would be on there...
Wait, that was SOFTWARE? I thought it was a bug...

Re:WOW.

[vertinox]

Remember what MS did to the Q-Dos author? ;)

Re:Microsoft's striking absence

[mattyohe]

Do people just open an article, do a Ctrl+F and type microsoft to find something 'juciy'? If you would have RTFA you would have seen that the 'Ping Of Death' was mentioned which did impact Windows machines.

Criteria for "worst" bugs

[QADirector]

I think this is an interesting concept, but I would question the criteria of the worst bugs being those that create fatalities that moment. I'd argue that bugs that affect a function's effeciency, or a bug that allows a vulnerability could impact many (millions?) people, for perhaps minutes, or hours.

That impact could result in lots of people losing their jobs, losing their minds, and losing their families and lives through suicide or abuse to compensate.

Think about what a virus (maybe exposed through a bug or vulnerability) could do to a small company.

Think about what a bug could do to a computer science student :)

===
"This is a really small fix..." -said by all developers

Re:omg

[PhilHibbs]

Its intent was not to cause terror, but to inflict economic damage. I heard about a similar incident where a Japanese shipbuilder was stealing blueprints from a UK shipyard tendering for a contract and undercutting them. The UK shipbuilder deliberately designed a ship that would capsize on launch, which the Japanese duly stole, built, and launched. I don't know if anyone was killed, but ethically it's a tricky one.

Yes it was a software bug

[gorim]

Because it was implemented as microcode into the processor.

Suuuuure

[kcurtis]

Indeed. Causing a *NON FATAL* explosion in a country that imprisoned as many as 2.5 million political prisoners in Gulags at one time, and is estimated to have murdered upwards of 60 MILLION of its own citizens. Terrorism?

Terrorism is an act of mayhem designed to terrorize. This did not.

Sabotage? Yes.
Act of war? Probably.
Terrorism? Not even close.

Your statement is just a display of anti-American rhetoric with no basis in reality.

Re:Suuuuure

[LordCrumb]

Actually, this incident falls very neatly into the category of terrorism. Fatalities are not required; past actions of the victim-state are not relevant. The action has neither to inspire terror nor be designed to inspire terror.

American Heritage:

"The unlawful use or threatened use of force or violence by a person or an organized group against people or property with the intention of intimidating or coercing societies or governments, often for ideological or political reasons."

Merriam-Webster:

"the unlawful use or threat of violence esp. against the state or the public as a politically motivated means of attack or coercion"

You're wrong, America engages in terrorist activity on a fairly regular basis and Bender is great. Deal with it.

Re:Suuuuure

[Kupek]

Dictionary.com definition of terrorism:

terrorism
n.

The unlawful use or threatened use of force or violence by a person or an organized group against people or property with the intention of intimidating or coercing societies or governments, often for ideological or political reasons.

I think something like this qualifies. It was probably illegal by international law (there was no declared war, so I don't see how it can be considered an act of war), it's not a stretch to call it violent (and I think it's easily a show of force), and it was likely meant to disrupt the Soviet's infrastructure, and consequently, the Soviet government and society itself.

Terrorism is not limited to the "bad guys."

Re:Suuuuure

[aug24]

Causing a *NON FATAL* explosion

You missed a word: "...Causing a luckily *NON FATAL* explostion... would have been more accurate.

Not sure what the relevence of the other stuff is, as I don't believe the CIA gave a shit about political prisoners.

I do agree it's not terrorism though.

J.

Re:Suuuuure

[shutdown -p now]

Indeed. Causing a *NON FATAL* explosion

That's where you have a clue. Was it specifically intended to be non-fatal, though, or was it just blind luck?

in a country that imprisoned as many as 2.5 million political prisoners in Gulags at one time, and is estimated to have murdered upwards of 60 MILLION of its own citizens.

I don't see how this is relevant, though. Terrorism is terrorism all the same, be it directed against the USA, Russia, Saudi Arabia or North Korea.

Re:Suuuuure

[Aceticon]

Indeed. Causing a *NON FATAL* explosion in a country that imprisoned as many as 2.5 million political prisoners in Gulags at one time, and is estimated to have murdered upwards of 60 MILLION of its own citizens. Terrorism?

Terrorism is an act of mayhem designed to terrorize. This did not.

Sabotage? Yes.
Act of war? Probably.
Terrorism? Not even close.

Your statement is just a display of anti-American rhetoric with no basis in reality.

So how would you feel if it was the other way around, if the Soviet Union had caused such an explosion in US soil?

I reckon the original poster just reacted in a strong way due to the way he feels when people are killed for no reason. The nationality of said people (or indeed the behavious of the government on the country in question) do not make it less of a shamefull act.

By the way, were did you get the NON FATAL information from?

Re:Suuuuure

[daniil]

-1, Dictionarist. You Fail It.

Re:Suuuuure

[dascandy]

Do you have a freestanding definition of terrorism too? One that doesn't directly or indirectly include "terror", "terrorist" or "terrorize" or something like it?

Re:Suuuuure

[maggern]

You can't (on a general basis) defend the killing of some people in one area with the fact that other people has been murdered elsewhere in that country. It just leads to even more dead people, which is worse!

Re:Suuuuure

[Perl-Pusher]

Oh and you guys murdered most of your native population and then enslaved another.

Can you name one major empire that didn't ever in there history do the same? The Greeks, The Roman's, Ancient Egypt, The Byzantine's, the Moors, The Crusades, Napolean, Genghis Kahn, Japan's invasion of Korea & Manchuria etc. Nazi germany, the USSR, and the US genocide of the Indian's to name a few. Black slave's were a commodity worldwide. Thanks in no small part to the Arabs, the Spanish and the Dutch who entered the slave market and in a short time exported more slaves than all the previous put together. All have had histories of murder & genocide. Mankind pretty much has a history of doing the most dreadful things imaginable. Facist,Communist,Islamist,Capitalist, pretty much any order with an 'ist' at the end becomes a reason to kill.

Re:Suuuuure

[Alizarin Erythrosin]

I had to pick which of the GP responses to reply to, so I picked yours.

So how would you feel if it was the other way around, if the Soviet Union had caused such an explosion in US soil?

It was even reported in the article that the CIA kept the fact that this particular incident was caused by them a secret for many years. To all outside observers, it was an accident of some sort. Something went wrong, stuff blew up. Intentional software bug or not.

<bad analogy>
Its like if your car caught fire while you were driving down the street. You might think "Piece of crap <car brand>", but if some random guy ("Steve") had put a tiny pin-hole in your gas line that sprayed the exhaust manifold and set the car on fire, and never told you, and you never found out Steve did it, how would that cause terror?

Re:Suuuuure

[blamanj]

Actually, by the American Heritage definition, I'd say the parent is correct. Sabotage is a better term. Terrorism includes the intent to intimidate. The pipeline incident was intended to cause economic damamge, but it has done in a way that the Soviets would have not suspected any outside force, but assumed a construction error on their part.

What? No Windows ME?

[Guysmiley777]

Yeah, I'm fairly certain that Windows ME (or Windows: MoneyGrab) was one of the largest software bugs ever written.

Re:What? No Windows ME?

[Anne Thwacks]

YOu obviously never used DOS 4.0. This used 16 bits for sector addresses when reading, but only 12 when writing! Result: after your disk was reasonably full of valuable data, it got irretrievably corrupted!

Re:What? No Windows ME?

[Guysmiley777]

You're right. I skipped from DOS 3.3 to 5.0.

Why?? Licenses are not farfetched.

[technoextreme]

This is like saying you need a license to operate a Soda Vending Machine because some idiot decided tipping it over trying to get a free soda was a smart idea. You might have to put warnings on compliers like do not code if you have no clue what you are doing, etc but requiring a license won't ever happen. I am sure there will be lawsuits in the future regarding software bugs, but any software being used where an error could cause a human death is going to have a corporation behind it, that can be held responsible. Actually, engineers obtain licenses so why not software programers. You are not even allowed to call yourself an engineer without getting that license. Basically, if this system was in place for programmers the programmer would have to take legal responsibility for his code.

Re:Why?? Licenses are not farfetched.

[Phisbut]

You are not even allowed to call yourself an engineer without getting that license. Basically, if this system was in place for programmers the programmer would have to take legal responsibility for his code.

I am a software engineer. I have an engineering degree in software engineering, and I have an engineering license in order to say I am a software engineer. Under law and deontology, I am responsible for the quality of the work I deliver to my customer. However, the definition of customer is somewhat vague, and it goes like "the one who pays me for the work I do". Basically, *my* customer is my boss. If I were to be a simple non-engineer programmer, I would still be responsible for the work I do for my boss, and he could just as well fire me, so "having a license" doesn't change anything.

Airbus Crash

[CruddyBuddy]

Here is video of an Airbus crashing into the trees because the autopilot didn't like the landing conditions. IIRC (remember), the pilot's pull-up was ignored because the flight conditions weren't optimum despite an obvious life threatening situation. If this isn't a software bug, what would you call it? (Maybe the software considered crash modes and this configuration allowed the black box to survive intact.)

http://www.alexisparkinn.com/photogallery/Videos/A irbus320_trees.mpg/

(Let the slashdotting begin! (poor servers))

All things considered, I don't know if the pilots survived.

Re:Airbus Crash

[Skiron]

No, this wasn't 'auto-pilot' - this was the 'fly-by'wire' technology that stopped a pilot doing something (that it thought was) outside the flight envelope of the aircraft.

Here the pilot had to try evasive action to pull the aircraft out of the predicament - as these exceeded the flight envelope the software deduced it was detrimental to the aircraft, therefore wouldn't let the pilot do it (or basically re-corrected his actions).

After this happened, I believe it was changed so a pilot could flick a switch that allowed him to override the software and fly the aircraft from the stick.

Re:Airbus Crash

[be-fan]

I actually know why this happened. We learned about it in our flight dynamics class. The problem was the result in a mistmatch between what the pilot thought the airplane was doing, and what it was actually doing. The A320 had software that prevented the pilot from stalling the airplane during flight. However, the protection only kicked in above 90', because the software assumed that if you were below that, you wanted to land (which involves a stall right at touchdown). The pilot was trying to do a flyby, and was supposed to be above 100', but for whatever reason he came in at around 30'. Now, the reasons he didn't pull up and ramp up the engines are debatable, but the equitable explanations suggest that he assumed that the airplane's stall protection would kick in, while the airplane had disabled them because it thought it was about to land.

Re:Airbus Crash

[UnknowingFool]

I wouldn't call this so much as a bug as bad design. Airbus thought that their computer control system was so infallible that it could always override the pilot. As we all know, there are some real world circumstances where the pilot needs to override the computer because the computer can't anticipate every situation. After this, Airbus put in an override in case the pilot needed it.

Re:Airbus Crash

[omnifunctional]

I'm afraid that is not entirely correct either. While the feature you mentioned was a factor, there were others one of which was a software bug that allowed the Airbus flight control computers to reach a indeterminate state. On an Airbus, the Flight Control Computer and the Autopilot are the same computer. While there is (and was at the time of the crash) an autopilot disconnect switch on the aircraft, it did not work as intended. In this incident, the autopilot failed to relinquish control of the aircraft to the pilot due to a software bug. Instead the pilots control inputs were completely ignored. The pilot did apply the correct control inputs, but the flight control computers, which busy were trying to calculate the airspeed velocity of an unladed African swallow, ignored him. Definitely a software bug. Killed most of the occupants of the aircraft, including many members of the press and a few VIP's.

Re:Airbus Crash

[be-fan]

I don't think we're remembering the same incident. The A320 crash at the Habsheim airshow only killed only 3 of 136 people onboard.

Re:Airbus Crash

[C0vardeAn0nim0]

the investigation concluded he was using the barometric altimeter instead of the radio altimeter to measure altitude. and it apears the device wasn't calibrated correctly deu to manufacturing errors (http://www.airdisaster.com/investigations/af296/a f296.shtml#oeb)

he also had an engine stall when he tried to ramp the power up. due to the long delays (again, manufacturing errors) in delivering power at low altitude, the pilot thought it was a short circuit in the controls, so he pulled the lever all the way down, then up. this caused one of the engines to stall. this conclusion came after survivors said they heard two loud bangs coming from one ot he engines, also, the trees chopped by the wings were chopped lower at one side of the plane, indicating that one of the engines was producing more power than the other.

Re:Airbus Crash

[Tim Browse]

Just to add yet another explanation, when I worked for Rediffusion (UK flight simulator manufacturer), this air show crash was discussed during our induction. If I remember correctly, the pilot span down the engines to lower the aircraft, and then tried to power them up again to lift the aircraft out of the descent and fly over the trees. The pilot claimed the system over-rode his desire to power up the engines, causing the crash. (I believe he had already over-ridden some safety mechanism to allow him to perform this descent in the first place.)

However the actual problem was that airliner engines aren't like some awesome fighter jet with afterburner. They take time to spin up - from examining the black box, they determined that at the point the pilot wanted to ascend, even if the engines span up at the maxiumum rate, it was still nowhere near enough to pull the plane out of the descent. Hence, pilot error.

Re:Airbus Crash

[Glendale2x]

Now, the reasons he didn't pull up and ramp up the engines are debatable, but the equitable explanations suggest that he assumed that the airplane's stall protection would kick in, while the airplane had disabled them because it thought it was about to land.

You can hear the engines spool up after it disappears into the trees. A bit late, however.

Re:Airbus Crash

[legirons]

This was the crash where the Flight Data Recorder mysterously went missing after someone gave it to the manufacturers (who stood to make huge losses if anyone thought there was a problem with their aircraft) and when the (Swiss?) judge finally demanded that the Flight Data Recorders be handed over to the court (and independant evaluation), they turned out to have been tampered with.

"Pilot error".

Yes, pilot error. Of course. Just like that Chinook was pilot error.

The worrying thing was that it wasn't even a convincing coverup. Take the FDR, open it up, remove 3 seconds of incriminating footage (so the voice and data are 3 seconds out-of-sync), and give it back to the judge still unsealed and with different stickers on to when it was removed from the aircraft. They even left in the data showing that the altimeter was lying to the pilot.

Re:Airbus Crash

[darkmeridian]

The pilot claimed that the engine did not spool up to power in time. Of course, the official investigation said that the engines did spool up and it was pure pilot error. Not that the government has any incentive to benefit AirBus, of course.

MOD PARENT BACK DOWN IT WAS A SOFTWARE BUG

[gorim]

Because it was actually implemented as microcode and stored into the CPU, whether as mask rom or some other means of storing, but it was indeed software either way you look at it.

Re:MOD PARENT BACK DOWN IT WAS A SOFTWARE BUG

[wild_berry]

Like I said elsewhere today: the Wikipedia links http://en.wikipedia.org/wiki/Pentium_FDIV_bug to http://www.cs.earlham.edu/~dusko/cs63/fdiv.html which indicates that it's the microcode at fault.

Same old tiresome error: "BUG" was old then

[SysKoll]

The Wired article perpetuates the same old tiresome mistake, that is, that the term "bug" originated from a moth found in a 1947 computer.

That is wrong. This is a myth that has been disproved several times. See for example the "IEEE Annals of Computer History" where Adm. Grace Hopper said that that the term "bug" was used at least since the 30s, and maybe earlier, to describe an electrical problem in a system. See also here.

In interview, Hopper confirmed that the notebook moth's caption, "First actual case of bug being found", clearly shows that it was a joke referring to a term that was already in use at the time.

Any idiot researching this anecdote for five minutes could have found about it. I guess Wired couldn't be bothered. At this level of laziness and incompetence, one wonders why they just don't start publishing printouts of slashdot laced with ads. At least, this place contains occasional nudgets of truth.

Once again, Wired blew it. Nice jobs, guys.

Re:Same old tiresome error: "BUG" was old then

[east coast]

Once again, Wired blew it. Nice jobs, guys.

Indeed, these losers need to be lined up against a wall and shot for their lack of research. Damn them! My life's work is now meaningless in the face of such an atrocity.

Re:Same old tiresome error: "BUG" was old then

[drinkypoo]

Wired is not about providing information. It's about selling magazines. This is why their original layouts included shit like blue text on orange backgrounds - it was "edgy" or "inventive" or something like that. It's also why they finally went to black on white [most of the time] - lots of people cancelled their subscriptions because they were losing their eyesight :)

Re:Same old tiresome error: "BUG" was old then

[ScottForbes]

I hate to interrupt your rant, but... the Wired article doesn't say that the term "bug" originated in 1947. It merely notes that the first widely known "buggy computer" was the Harvard Mark I:

With that recall, the Pruis joined the ranks of the buggy computer -- a club that began in 1947 when engineers found a moth in Panel F, Relay #70 of the Harvard Mark 1 system. The computer was running a test of its multiplier and adder when the engineers noticed something was wrong. The moth was trapped, removed and taped into the computer's logbook with the words: "first actual case of a bug being found."

Unless you demand that anyone retelling the 1947 anecdote immediately prove their street cred -- "Of course the term 'bug' did not originate with this incident, blah blah blah, I mention this to prove that I'm smarter than you are" -- then the Harvard Mark I's moth is the earliest example of a computer glitch that the public might have heard about. Since the rest of the article is about other bugs the public might have heard about, and since the article repeated Hopper's exact words about finding an "actual bug" (which, as you note, implies that they'd been calling them "bugs" long before they found a genuine moth), how about you easing up a little and giving writer Simson Garfinkel some slack?

Re:Same old tiresome error: "BUG" was old then

[elgatozorbas]

Indeed, wired was wrong. I knew this too, as probably many geeks around here did. But to hold it against them is going a bit too: this is not the kind of vital information that they will start doublechecking immediately. This is no article about debunking urban legends, it is about famous bugs.

Re:Same old tiresome error: "BUG" was old then

[chris_eineke]

The Wired article perpetuates the same old tiresome mistake, that is, that the term "bug" originated from a moth found in a 1947 computer.

Are we reading the same article?

It says that the Toyoya Prius joins the club of buggy computers, "a club that began in 1947 when engineers found a moth in Panel F, Relay #70 of the Harvard Mark 1 system" and "the moth was trapped, removed and taped into the computer's logbook with the words: "first actual case of a bug being found."".

The article doesn't say that this was the first occurance ever of a bug (i.e. hardware failure because of an animal). You cheeky slashdotter :)

No causualties

[PIPBoy3000]

According to this article the damage was purely economic. Of course, I'm sure there was significant environmental damage.

As far as I can figure, people go crazy in times of war, even cold wars.

Case of the Miscounting VAX 11/750

[G4from128k]

I once wrote a simple finite difference routine in FORTRAN on a VAX 11/750 for an engineering class in college. The code used a nested DO loop to do 100 iterations, check for convergence, do another 100 iterations, check for convergence, etc. The inner loop was a dead simple DO 100 iterations using an integer counter, had absolutely no exit code inside the loop, no use of random numbers, nothing squirrelly. The outer loop had a simple test for convergence. A PRINT statement on the outer loop kept me apprised of the progress of the run. Everything is going fine until a do a run and get:

I: .....
100 .....
200 .....
300 .....
399 .....
499 .....

How this VAX decided that 99 times through a i = 1 to 100 loop was OK, I'll never know. I re-ran code with the identical inputs and it never did this again.

Re:Case of the Miscounting VAX 11/750

[GigsVT]

I've got some similar weirdness. We have an SGI Origin 2000 with IRIX, and randomly the "tr" command stops working. Not just the native tr either, gnu tr and irix tr.

Here's what it sometimes does:
>echo usuck | tr [a-z] [A-Z]
AsAck

It was coincedence we picked the string "usuck" to test it. I tell all new employees about the "you suck a sack" bug.

The weird thing is if you log in as another user, it's fine. If you then su to the problem user, it happens again. Recreating their account with all the same dotfiles... and the problem's gone, for a while.

I blame cosmic rays. :)

Re:Case of the Miscounting VAX 11/750

[Maximum Prophet]

I remember when I was a student consultant at Purdue. We would constantly have people telling us, "I ran my program, it worked, I didn't change anything, now it doesn't." Usually, "didn't change anything" meant they had gone back and added comments, and commented out critical code.
Then, one day, multiple people started coming to us saying the same thing. I went over to a terminal and verified that the same simple fortran program would give different answers when run over and over. Turns out, Purdue's Computing Center used dual CPU Vaxen. On one machine, one of the FPU's was broken. Depending on which CPU your program ran on, you'd get a right or wrong answer.

Re:Case of the Miscounting VAX 11/750

[petabyte]

Depending on which CPU your program ran on, you'd get a right or wrong answer.

Hmm, my university apparently used that same setup for the program grading our bubblesheets ...

Re:Case of the Miscounting VAX 11/750

[pe1chl]

This could well be because the user has something called tr in his path.
It reminds me of the many times I saw that new programmers on our Unix system in those days wrote their first program, called it test.c, compiled it to "test" and then saw very misterious problems occurring that no other user saw.
In those days, the current directory was often first in the PATH, and many scripts used the "test" program /bin/test instead of its alias name '[' that was later invented.
Those scripts would run the user's test program instead of /bin/test.

Re:Case of the Miscounting VAX 11/750

[pe1chl]

Remember: Nothing sucks like a VAX

Re:Case of the Miscounting VAX 11/750

[psergiu]

Loser !!! use double quotes !!!

echo usuck | tr "[a-z]" "[A-Z]"

you had some files in that dir named "u" and "A" and the [a-z] and [A-Z] are also SHELL WILDCARDS !!!

$ ls
A u
$ echo usuck | tr [a-z] [A-Z]
AsAck
$ echo usuck | tr "[a-z]" "[A-Z]"
USUCK

Re:Case of the Miscounting VAX 11/750

[GigsVT]

Interesting. My love/hate relationship with bash/sh continues. :)

I'll keep an eye out for missing quotes in the scripts if it happens again.

Eh, perhaps in use already.

[Grendel Drago]

According to the caption, "the term "bug" had been in use for many years previously by engineers to indicate an indefinite problem".

Re:omg

[Jason Hood]

And i suppose if I had a "broken" gun in my basement and you broke in and stole it, then tried to use it and injured yourself, you could sue me right?

Sorry, i am having a hard time seeing the correlation to Terrorism here. It seems that you have a predisposition to the US's stance on terror and are desparately trying to make a connection for a political statement. Unfortunately, typical slashdot readers will agree with you =)

This would be very different if the US broke in to USSR and altered their software to malfunction. That definitely would be a criminal act, but more perhaps importantly and act of War. I doubt the Soviets ever figured out what happened until they were told.

Can't read article in the fox

[PhilHibbs]

Is it just me, or does the page fail to load in Firefox? I don't see the article text, but I do see "href='http://mediauk.247realmedia.com/..." where the article should be. Could be Flashblock or Adblock gumming it up.

Re:Can't read article in the fox

[6031769]

No, it's not just you. In a superbly postmodern way, the page has a bug.

Turn javascript off or use another browser to get to the text.

Re:Can't read article in the fox

[slavemowgli]

Here's the gist of it: http://it.slashdot.org/comments.pl?sid=167665&cid= 13978914

Re:omg

[Yahweh Doesn't Exist]

I don't think you can justify the largest non-nuclear explosion ever just because it was a "side-effect" of economic damage. otherwise it becomes very easy to justify 9/11 since all the targets were economic/military.

on a much smaller scale, I think it's illegal here in UK to set "traps", for example a landmine in your house in case of thieves breaking in. I believe the reasoning is the indiscriminate nature - it could kill a fireman trying to save the house from burning down.

similarly, even in war, indiscriminate killing is ethically wrong and I doubt the gas workers were wearing military uniforms (and I guess the US still pretended to care about the Geneva convention back then)

Re:Microsoft's striking absence

[varmittang]

Remember when the LA air traffic control tower crashed, due to a bug in MS software after 49 days. I would think that this would make it up there. http://www.itgarage.com/node/459

Did you actually read the article?

[Grendel Drago]

1982 -- Soviet gas pipeline. Operatives working for the U.S. Central Intelligence Agency allegedly (.pdf) plant a bug in a Canadian computer system purchased to control the trans-Siberian gas pipeline. The Soviets had obtained the system as part of a wide-ranging effort to covertly purchase or steal sensitive U.S. technology. The CIA reportedly found out about the program and decided to make it backfire with equipment that would pass Soviet inspection and then fail once in operation. The resulting event is reportedly the largest non-nuclear explosion in the planet's history.

I didn't know what it was called, though. Thanks for the link!

Your right it is that line.

[technoextreme]

I think the last line is actually something like Dilbert: That isn't very random though. Some guy: That's the trouble with randomness - you can never tell. Yes that is it. Thank you.

Stupid question about the gets() problem...

[Richard Steiner]

Instead of removing all references to gets() in existing code and keeping the faulty gets() in the standard C library, why not just improve gets() to make it secure and proprgate the new version?

Or has that also been done?

I don't write a lot of C code, so I really don't know...

Re:Stupid question about the gets() problem...

[allanc]

Backwards compatibility. The fixed version of gets() (fgets()) requires a second argument to say how big the buffer it's reading into is. So any code that was written for gets() would stop compiling if they just redefined it.

--AC

Re:Stupid question about the gets() problem...

[andawyr]

Yup, it's been done:

char *fgets(char *s, int size, FILE *stream);

Instead of just reading from a stream, you specify the buffer, and the size of the buffer. This prevents overflow.

Re:Stupid question about the gets() problem...

[FooAtWFU]

gets() is insecure by definition. From the manpage:

char *gets(char *s);

gets() reads a line from stdin into the buffer
pointed to by s until either a terminating newline
or EOF, which it replaces with '\0'.

BUGS
Never use gets(). Because it is impossible to tell
without knowing the data in advance how many characters
gets() will read, and because gets() will continue to
store characters past the end of the buffer, it is
extremely dangerous to use. It has been used to break
computer security. Use fgets() instead.

The thing is, gets() does not know how long the buffer is. It just knows where the buffer is. (Where is it? at s.) So, it will start at s (the beginning of the buffer), and if the input is long enough, keep on barreling through past the proper end of the buffer and into whatever's after s: other data, sometimes involving return addresses (which are basically 'bookmarks' which tell the computer where it left off to pursue a subroutine). If you can change the return address, you can point it somewhere else, and you have the computer doing what you want it to do.

Re:Stupid question about the gets() problem...

[SnarfQuest]

It is inherently broken by design. You pass it a buffer of indeterminate size (selecting one large enough for your purposes), but you don't have any way of telling the function how big the buffer is. If you read more data than the buffer can handle, bad things happen.

No, the size of the buffer cannot reliably be determined from inside the function. Not even if you make it a macro.

Why do they retain it? Because dropping it would break a LOT of existing code. So they have been modifying the compilers to generate warning messages when it sees them.

Re:Stupid question about the gets() problem...

[schnipschnap]

It is not the implementation of gets(), it is the concept. The function reads data until EOF, and if there is no EOF, and the buffer is too short (which it must be as there is no such thing as an infinite buffer), stuff gets (pun not intended) overwritten.

Re:Stupid question about the gets() problem...

[CUViper]

The problem is that the gets() API itself is flawed, not the implementation. The API is basically "Here's my buffer, please fill it with a line of input." There is no parameter to specify how big the buffer is, so the gets() implementation has no way of knowing when it has written too much.

The only way to fix it would be to change the API to add a size parameter. Changing an API that is already in use is just asking for trouble. If you changed it without recompiling EVERY program that uses it, then the old programs would effectively be passing a bogus size parameter on the stack, which is worse than no size at all. So changing the API would require everyone to rewrite their code, and at that point, you might as well rewrite the code to use fgets() instead, which already has a size parameter.

So the solution in practice is to leave gets() the way it is, so that existing users don't have to change their code. For many programs this may be OK if there is little or no risk of an oversized input line. But for any new code, or when touching old code, the recommendation is to use fgets() instead.

Re:Stupid question about the gets() problem...

[corngrower]

Good post. I first started using C back in the mid 80's and the first time I saw the definition of 'gets()' I could see that it was essentially a worthless function because it fails to account for the buffer size. I've never used it in production code. For a quick and dirty program that only I use, I might have considered it. scanf() is another one of those essentially worthless functions.

Re:Stupid question about the gets() problem...

[MarkGriz]

"Instead of removing all references to gets() in existing code and keeping the faulty gets() in the standard C library, why not just improve gets() to make it secure and proprgate the new version?"

It isn't that gets() is necessarily faulty, but it provides no mechanism to limit the amount of data accepted. To do that requires passing an additional "size" parameter to the replacement gets() function, when means all calls to gets() need to be modified to include the size parameter. You couldn't simply replace gets() with better_gets().

You can see an example here

Re:Stupid question about the gets() problem...

[spitzak]

Although it could not really be fixed, couldn't it be changed so that it acts like fgets with a fixed buffer length? This could be very small (256? 1024? 80?) so it is smaller than the buffers most programs use, and will not prevent reading of the typical small text files the function is begin called for. It could also be controlled with a static variable so a programmer could set it larger.

Re:omg

[garcia]

Its intent was not to cause terror, but to inflict economic damage.

In a country that was already rife with the underpinnings of civil war due to economic issues, don't you think that its intent was EXACTLY that? If those people had any more economic problems to face, a lot of people were going to die fighting.

I'd say that its intent was to INDIRECTLY cause terror.

Re:Time for stressing more on formal specification

[Anonymous Coward]

That's easier said than done. After all, buggy software is usually better than no software. But who's to say that it will even prevent the problem.

Mariner I software was correct, but failed because the software was incorrectly typed into the computer. The Ariane 5 software was correct when it was written for Ariane 4. The only way to find that bug is with simulation of the whole system. The Therac software was correct because it was part of a system of hardware interlocks. Later machines took half the system without replacing the other half and people expected it to work the same way.

Formal specs won't help you if your software is not being used as designed or if the designer can't know all possible inputs (such as fly-by-wire software for aircraft).

dom

If Engineers built buildings

[ColdWetDog]

The way computer programmers wrote programs, the first woodpecker that came along would destroy civilization.

Re:If Engineers built buildings

[legirons]

"If Engineers built buildings the way computer programmers wrote programs, the first woodpecker that came along would destroy civilization."

If engineers built buildings the way computer programmers wrote programs, an average engineer would be able to build an array of radio telescopes by himself in one evening. A team of 30 engineers would be able to build a ringworld in 3 months.

i.e. it would be nice if software were like designing an office, where there were 3 architects, 5 engineers, a building inspector, and 50 professional workmen to examine a system containing just a few hundred variables, and almost identical to the last 20 buildings they'd constructed.

And in case that didn't start a flamewar, how about...

"Just one unexpected input (of an aeroplane) caused the failure of two of New York's biggest civil engineering projects -- imagine how they'd cope with being attacked every 3 seconds like some internet software"

Medical Systems

[koehn]

I designed and build a diagnostic radiology workstation (in 1997, in Java 1.1, 4x5 megapixel monitors, still in use today). During the development effort we were regaled with stories of software glitches in medical systems resulting in disaster. It really keeps you focused.

In one case, a radiation treatment system had a bug where if you used the backspace key when entering the dose a patient received, the display would show you deleted the last digit, but internally you hadn't. So the patient would recieve 10^backspace times the intended dose of radiation. Not a big deal normally, since the techs would typically shut the machine off between treatments. Until one day when they had two patients needing treatment back to back. The tech knew something was wrong when the machine was running for an unusually long time. The patient knew something was wrong when he died.

On our team a defect that crashed the system was considered severity 2. Severity 1 was reserved for defects that could result in a mis-diagnosis, which most patients agree is worse than a crash.

Re:Medical Systems

[grahamsz]

Would it not be really simple to have a failsafe along the lines over "never nuke the patient for more than X seconds" where X is some value that wont kill them.

I know these machines are often used in different situations, but it doesn't seem like it would be that hard to put in a limiter that would catch the worst problems.

Re:Medical Systems

[mabraham]

Well if it were a diagnostic process, then that might make some sense.

The problem with radiation therapy is that you are trying to hurt the patient. In the case of a cancer treatment, you are just trying to kill the cancer faster than you kill the patient.

Additionally, there is no such thing as a uniformly non-lethal dose. It's critically dependent on the age of the patient, type of tissue involved, type of (for example) cancer and the type of radiation involved. Making this type of judgement is one reason doctors get the big bucks. It's similar to the reason anestheologists get bigger bucks... they are pretending to kill you for a bit!

How about this one?

[phorm]

This article was ones of the ones on the sidebar when I viewed the main wired article. Just an isolated incident, but certainly if it were a symptom of a more widespread "bug" it could be serious enough to make the books (not that anyone would ever know)

Spell-checker Bug?

[caffeined]

Does bharatm perhaps have a bug in his/her spell-checker? "sofware" bugs?

No - "software bugs".

Re:Whoops forgot to hit preview

[CastrTroy]

There are software engineers in Canada now. They can legally sign off on a software project. The problem is, is that you don't want to have every one of your programmers be licensed software engineers, all signing off on their own code. It would be too expensive to try and hire that many engineers, and managing all the signatures for all the code, when different people work on the same piece of code would be a nightmare to manage. Basically you'd have to have one engineer, or team thereof, overseeing the entire project to be sure that proper methods are being followed to ensure that there aren't any bugs. What you're asking for is more like saying that everyone who in building a bridge be licensed, and that they should all have to sign off on every rivet they put in.

The problem is, is that most companies producing software do not want to pay for an engineer to oversee their project. Also, the way most software operations are run, you wouldn't see an engineer, signing off on the projects. The engineer would force things to be much more tested in order to be ensure that things were actually worthy to be signed off on. There is lots of this kind of software being built for planes, and other situations where it really matters if there is bugs. I don't think this kind of situation will ever happen with off the shelf software. For one thing, software would cost too much, and most people aren't willing to pay $2000 to run an operating system on their home computer, and also because most engineers wouldn't sign off on a system, in which they didn't know the computer their software would run under. There's too many variables on a home computer to be able to garauntee, at that level, that your software will operate completely as expected.

Peer review for software?

[jeffs72]

It's interesting to think of how software has slowly gained more and more control over our lives. I mean, cell phones used to come in a satchel case, now they play videos. The more complex, the more risk in our tech it seems. It really paves the way for open source inititives (I can see how that code slapped together by a guru would have been fixed by open source).

It almost seems like peer review should be required in critical software like phone switches, medical equipment, etc. I mean, scientists need peer review for their work, how about some practical real world peer review going on? Maybe some sort of non-profit gets setup, or an international body formed like the IEEE or something, to review this sort of thing.

I also wanted to throw in my 2 cents and say that this was a great article. Lots of stuff on slashdot you have to wonder what they were thinking, but this was pretty interesting.

Re:Peer review for software?

[tree_frog]

And what makes you think that phone network software isn't peer reviewed?

regards,
treefrog

Re:Peer review for software?

[jeffs72]

Do you have some sort of inside track that Siemens, Motorola, Nortel, Samsung, etc are all doing open source peer review?

I think this one should have made the list

[Phanatic1a]

For potential severity, this one's worse than a few they listed.

Basically, the Navy was running critical ship systems on a Windows NT platform, and a divide-by-zero in a database caused a buffer overrun that resulted in a shutdown of the engines, leaving the ship dead in the water for 2.5 hours.

Fortunately, it was on maneuvers off of Cape Charles, and not at war off the coast of Yemen or something. Scratch a billion-dollar destroyer and most of her crew because of an NT bug, in that case.

Re:I think this one should have made the list

[YrWrstNtmr]

Mostly incorrect. An application bug, not an NT bug. The exact same situation could have occurred no matter what the platform. Poor development, minimal training, and pretty much zero testing, was the cause.

"NT played no role in the Yorktown's LAN crash, Baker said."
"The Yorktown is unique because it was a proof-of-concept [ship] put out to sea without formal testing and software certification, which our products normally go through," Baker said.

Re:I think this one should have made the list

[Tim Browse]

Not any more. They kicked our ass, apparently. Something about not being able to steer a ship or something.

Re:I think this one should have made the list

[Chaoticmass]

I got to take a tour of the submarine my brother is on in the Navy. Looking around I saw several computer terminals around. I got to see the sonar terminals where my brother works and he said they ran Linux (I dont know if it was linux or some *nix). I only saw one computer with an NT password screen, it was used for communication and plotting I think. Other than that one the rest of the systems did not appear to be windows machines.

Was interesting.

It's a subjective list, of course

[mblase]

I wouldnt say they are the 10 worst bugs ever... more like the 10 most widely known media announced bugs

Well, several of them result in the death of medical patients or the destruction of a multi-billion-dollar rocket or spacecraft. I found this one near the top of the list a curious addition, though:

1993 -- Intel Pentium floating point divide. A silicon error causes Intel's highly-promoted Pentium chip to make mistakes when dividing floating-point numbers that occur within a specific range.... Although the bug affects few users, it becomes a public relations nightmare.... The bug ultimately costs Intel $475 million.

Now, yeah, that's bad in the amount of money it costs Intel. But being a non-destructive, non-lethal bug that almost everyone's forgotten about by now, I think it pales in comparison to the Y2K bug, which cost the entire worldwide software industry far more money over a far greater length of time and still crippled credit card readers, financial software, and other computer software that cost real lost productivity for plain ol' consumers.

Re:It's a subjective list, of course

[jonadab]

> Now, yeah, that's bad in the amount of money it costs Intel. But
> being a non-destructive, non-lethal bug that almost everyone's
> forgotten about by now, I think it pales in comparison to the Y2K bug

The Pentium floating-point divide bug is more deserving on the list than the Y2K bug in one very important way: it was a real, actual, extant instance, a specific mistake in a specific piece of code that caused a specific problem.

The Y2K bug was an abstract (and much exaggerated) generality, not a specific instance of a coding mistake, not a problem with a specific piece of software, and did not cause a specific problem, unless you count "widespread panic" as a specific problem, and in that case the bug was in the stupid media hype, not any computer software.

> which cost the entire worldwide software industry far more money

Misplaced general paranoia caused those costs, not a programming mistake.

Vanishingly close to 100% of the *actual* (non-imagined) software problems that resulted from Y2K were minor user interface glitches, resulting in things like the year being printed as "19100" or the user being unable to correctly enter dates (if the software only accepted two digits) until an update was installed. Very little was "crippled" or "shut down", and *none* of it was the kind of important infrastructure (power plants and phone-line routing equipment) that the mindless paranoid were so concerned about.

> other computer software that cost real lost productivity for ... consumers

I am not aware of a single instance of anyone being unable to work or be productive because of a Y2K-related issue.

Granted, the Pentium FPDIV error also was not as big a deal as most of the other things on the list. But Y2K isn't even a specific bug, so listing it wouldn't even make sense if it *were* as major a problem as the other listed items, which it wasn't.

I would have put the Outlook "feature" of automatically launching binary attachments at the top of the list, but that's arguable, because it was done deliberately, due to grossly misaligned priorities, not out of ignorance or oversight.

Re:Whoops forgot to hit preview

[Balthisar]

You are not even allowed to call yourself an engineer without getting that license. That person is actually held legally responsible for the projects he signs off on.

Actually, you're confusing the title "P.E." (professional engineer) with the generally accepted term "engineer." One (the P.E.) is a licensed engineer, and others are used traditionally and arbitrarily with no legal recourse. For example, I and my co-workers are bona fide engineers, and most of us have engineering or engineering technology degrees. None of what we do requires a P.E. to sign off on anything, although there are other aspects of our business (and many other businesses) that do require a P.E.

Of course, there are all kinds of "engineers" that have that title but don't truly merit it -- customer service engineer; field service engineer; applications engineer; and so on. Most of these don't hold engineering degrees. For many of them, I don't begrudge them their title, either. But we also know that they're not P.E.'s.

Soviet Pipeline problem not a bug!

[CheddarHead]

The problem on the Soviet pipeline wasn't a bug. It was deliberate sabotage. I think that there's a slight difference.

Re:Soviet Pipeline problem not a bug!

[daniil]

It was a bug until they found out it was actually sabotage.

Re:Microsoft's striking absence

[IdleTime]

Yes, that is the one.... But it was publicly known way before that. I tested it back in the late 90's.

Only if you're doing string comparisons...

[CrazedWalrus]

Sure they are. Re-read the section on the Ping of Death.

From TFA:

Most obviously affected are computers running Windows, which lock up and display the so-called "blue screen of death" when they receive these packets.

The string "Microsoft"? No. The string "Windows", yes.

Re:Microsoft's striking absence

[diegocgteleline.es]

1995/1996 -- The Ping of Death. A lack of sanity checks and error handling in the IP fragmentation reassembly code makes it possible to crash a wide variety of operating systems by sending a malformed "ping" packet from anywhere on the internet. Most obviously affected are computers running Windows, which lock up and display the so-called "blue screen of death" when they receive these packets. But the attack also affects many Macintosh and Unix systems as well.

Guidelines for avoiding common mistakes

[derek_farn]

The importance of coding guidelines (not the ones that specify trivial, cosmetic, issues) is starting to be appreciated. It is a fact of life that much code is written by relatively inexperienced developers. Guidelines, at least well thought out ones, are essentially tips on what to look out for/avoid, based on the know-how of more experienced people. Coding guidelines can operate at a number of levels, the language level (ie, what language constructs to avoid or be careful when using) is now the stubject of an international study group.

Couple of Bugs I thought of

[randomErr]

2004 Luxembourg blackout
Patriot Missle - Missles had to be shut down once a day because targeting system would cycle every minute and change the internal cordinating system a fraction of a degree. Over the course of a few days the targeting system would be completely useless.
PS/2 shutdown bug - Analog copiers at the time fuser componants worked athe same frequency as the processor's shutdown signal.
Minus World - Super Mario Brother - A hidden water glitch
ErMac - Mortal Combat

Obligatory

[octaene]

What about the program called 'Microsoft Windows'?

End of story. I don't care about home computers

[technoextreme]

The problem is, is that most companies producing software do not want to pay for an engineer to oversee their project. Also, the way most software operations are run, you wouldn't see an engineer, signing off on the projects. The engineer would force things to be much more tested in order to be ensure that things were actually worthy to be signed off on. There is lots of this kind of software being built for planes, and other situations where it really matters if there is bugs. I don't think this kind of situation will ever happen with off the shelf software. For one thing, software would cost too much, and most people aren't willing to pay $2000 to run an operating system on their home computer, and also because most engineers wouldn't sign off on a system, in which they didn't know the computer their software would run under. There's too many variables on a home computer to be able to garauntee, at that level, that your software will operate completely as expected.

Whoops. I don't care about home computers. I only care about devices that may kill me if the program has bugs. (IE Medical Devices)

Wired doesn't work in Firefox

[manarth]

Wired includes an advert through JavaScript. In this case, the script inserts malformed html, which cause FF to render incorrectly.

SOLUTION: turn off JavaScript, or fire up IE.

Re:Wired doesn't work in Firefox

[manarth]

it's a rotating ad - if it worked for you, they're not serving you the offending ad.

(incidentally, i'm on FF1.5b2).

the offending ad is a tourism ad for "St Petersburg Clearwater"

What? No Outlook Express?

[edunbar93]

Why isn't Outlook Express in here? Early versions basically changed unopened e-mail viruses from a hoax to reality, when Microsoft decided it was a *good* idea to automatically run any VB script that was recieved. That's cluelessness like trusting everyone to be good and decent human beings while you walk through a prison shower with "Please rape me" painted on your back.

Later versions tried to fix the problem while keeping the functionality, as if somehow the bad guys would intentionally include the Evil Bit in their code.

Re:What? No Outlook Express?

[corngrower]

I wholeheartedly agree with you. This was definitely one of the worst software bugs ever. A really, really, stupid idea it was to automatically execute VB scripts in Outlook.

Re:What? No Outlook Express?

[Scoria]

Later versions tried to fix the problem while keeping the functionality, as if somehow the bad guys would intentionally include the Evil Bit in their code.

If the newer build didn't contain the same functionality, then nobody would upgrade their software. Outlook Express has also served to reinforce the idea that this functionality should exist and be activated by default in all modern e-mail clients. If you were to install a different e-mail client -- Thunderbird, for instance -- on a computer belonging to an individual that had become accustomed to Outlook Express, you would receive complaints due to the more secure behavior.

Good security is transparent to an end-user. The problem is that functionality is not, and end-users often prefer functionality at any cost.

Re:What? No Outlook Express?

[pe1chl]

The big problem is that Microsoft has (several times) designed software with functionality that anyone who thinks a second about security would never have included, just for the reason of its insecurity.
They only thought about how sexy it would look and how much the users would appreciate it, and they never considered how badly they could have been hurt.

They should not have designed it that way in the first place. Nobody would miss the functionality.
In (many) other industries, those that design new products first think about possible consequences. Also, there are often laws and governmental validation institutes that validate the product before it is being put on the market. Things like medicine and cars have to be type-approved before they can even be sold, and other goods like food or electrical equipment have to comply to standards and are taken off the market when they fail to do so.

For some reason, software has been exempt from all this. Considering the dependency of the world and individuals on software, this is a bad situation.
Even worse is the fact that software manufacturers can easily sign away all their responsibility in a simple EULA. Companies like Microsoft should be accountable for the design decisions they make. That would make them a lot more careful.

Re:What? No Outlook Express?

[sjames]

If the newer build didn't contain the same functionality, then nobody would upgrade their software.

True enough. The problem was in ever implementing the feature in the first place. It didn't take very much thinking to realize the 'feature' would not only expose users to a huge security hole, but that the hole would likely not be closable without removing the feature. The ensuing problems were readily predicted by nearly everyone but MS.

I wouldn't be surprised to learn that they knew that too, but chose to do it anyway knowing users would credit them for 'innovation' and that smaller players would be forced to either lack the 'all important bullet point', or implement it and go down in flames anyway because it takes a behemouth like MS to ignore the heat that results from such a horrible feature.

Different version of the Mariner I story

[slapout]

According to Wired:

"A bug in the flight software for the Mariner 1 causes the rocket to divert from its intended path on launch. Mission control destroys the rocket over the Atlantic Ocean. The investigation into the accident discovers that a formula written on paper in pencil was improperly transcribed into computer code, causing the computer to miscalculate the rocket's trajectory."

I heard a different version of the story. In the one I heard, the formula written on the paper was put into the computer properly -- but it was written on the paper wrong. Who's right?

And don't forget your roots...

[HotNeedleOfInquiry]

The very first "engineers" ran steam engines.

Re:And don't forget your roots...

[drinkypoo]

Right, but back then you had to know how they worked to operate them. In fact I've never seen a modernized steam engine that ran itself. You couldn't even crest a hill too fast, or you'd have a flash in the boiler and blow the thing up, potentially killing people who weren't even in or near the engine at the time since there's a lot of energy involved in phase change and the boiler parts are all heavy. Thus steam engineers actually knew something, or they (and many people around them) were in a lot of trouble.

Re:And don't forget your roots...

[mrisaacs]

Actually engineers existed long before the steam engine. The title of Civil Engineer was created to differentiate the practioners from the Military Engineers - the most common and probably the oldest usage of the title of engineer.

Re:And don't forget your roots...

[big tex]

Now we have Operating Engineers, which is the union responsible for operating equipment and mechanics on construction sites.

Re:And don't forget your roots...

[HotNeedleOfInquiry]

Got a cite? I'm not being a smartass, but this is the first I've heard of engineers before there was engines. Could it be a case of forward referencing the translation of some ancient word incorrectly?

Re:And don't forget your roots...

[Anonymous Coward]

Engines have existed for centuries. Roman engineers, for example, built siege engines (ballistas, and the like).

Dictionary.com
Engineer
[Middle English enginour, from Old French engigneor, from Medieval Latin ingenitor, contriver, from ingenire, to contrive, from Latin ingenium, ability. See engine.]

Engine
n. 1.1. A machine that converts energy into mechanical force or motion.
      2.1. A mechanical appliance, instrument, or tool: engines of war.

[Middle English engin, skill, machine, from Old French, innate ability, from Latin ingenium. See gen- in Indo-European Roots.]

Re:And don't forget your roots...

[AtomicRobotMonster]

What about Siege Engines (towers, trebuchets and the like)?

Re:Missed a big one.

[$RANDOMLUSER]

It can't be a feature, it was never documented.

Link to proof?

[wild_berry]

The slashthink holds that this event was the impetus for softcode in processors; I'm not convinced because the Pentium begun the muddling of RISC and CISC architectures with CISC words and RISC internals through microcode. The detailed explanation of the FDIV bug at http://www.cs.earlham.edu/~dusko/cs63/fdiv.html seems to indicate that the flaw was in the microcde (without explicitly stating so, and I don't know enough about the core behaviour of Pentiums to say).

Goose and gander

[A nonymous Coward]

[the USSR's] murderous, oppressive grip on Eastern Europe and attempts at foisting their cheerful utopia on South America and Africa

As opposed to the US's murderous, oppressive grip on third world countries generally and attempts at foisting their cheerful utopia on the rest of the world.

It's fair to say the US's grip wasn't as thorough, but it sure was oppressive, and it encompassed more of the world than the USSR for more years. How many legitimate governments did the US overthrow because they didn't like them?

Terrorism is terrorism. Justifying the largest non-nuclear explosion in the name of fighting terrorism belongs in George Orwell's literature.

Re:Goose and gander

[OzPeter]

Care to study up on Iran in the '50s ???

Re:Goose and gander

[iceperson]

surely you can do better than that.

Re:Goose and gander

[Hatta]

Hm, how about the overthrow of Chile's democraticaly elected gov't and institution of Augusto Pinochet?

Or, can I "do better than that" too?

How about Haiti?

Re:Goose and gander

[gowen]

Chile. Nicaragua. The Phillippines. El Salvador.
And of course, propping up the South African Apartheid regime.

Essentially, anywhere is Central America with the gall to elect a socialist.

Re:Goose and gander

[corngrower]

How many were elected? oh wait, elected govenment is something the americans pushed.

Ever hear of a little country called VietNam? Yes, the U.S was fighting against a democratically elected communist leader.

Re:Goose and gander

[Jherek Carnelian]

Chile
Colin Powell's statement: "With respect to your earlier comments about Chile in the 1970s and what happened with Mr. Allende, it is not a part of American history that we're proud of."

Iran

Guatemala

Greece

There's lots more where those came from -- all democratically elected too. I hope you survive the cognitive dissonance.

Re:Goose and gander

[Kohath]

As opposed to the US's murderous, oppressive grip on third world countries generally and attempts at foisting their cheerful utopia on the rest of the world.

That's a strange way to say "winning the cold war". I'm glad the US won. Are you?

Re:Goose and gander

[Haelyn]

Salvador Allende - Chile 1973
María Estela Martínez de Perón - Argentina - 1976

should I keep listing?

Re:Goose and gander

[Chosen Reject]

Firsly, if you are going to capitalize the 'n' in Vietnam then the correct way is to write Viet Nam.

You are ignorant of what was going on in Vietnam. The north was being supported by the China, a big enemy and threat, since they were supported by Russia as well. The south, while not a nice government, was much more desireable than a communist one, and so the US supported them to balance out China's support. Also they were only supposed to be two seperate countries for a short time after they defeated the French, and then the North and the South were to hold an election to unite the countries under one government. They never held that election. Instead the North decided to just use military force to make the South communist. At first the US's involvement was to protect the South. As the conflict wore on though, the US decided to go all the way and defeat the North.

There are many more subtle details in this, just like a lot of conflicts. Just up and saying that one country are jerks because they did such and such is a very simple minded view and is a major problem with news and views now-a-days. Everyone wants to simplify into sound bites and clever witty sayings rather than talk at length about details.

I'm interested to know however, who was that democratically elected leader. Ho Chi Minh started the Viet Minh to war against Japan, and France and with that army decided that he would be the leader of the Democratic Republic of Vietnam. Because he was communist the Chinese helped him and the Viet Minh defeat France. The treaty took France out, divided the country and gave the North to China, which then gave it to Ho Chi Minh, because of his affiliations. If that's democracy, I want nothing to do with it.

Re:Goose and gander

[ScentCone]

That's a strange way to say "winning the cold war". I'm glad the US won. Are you?

See, now, your tone suggests that you're making rhetorical point that presupposing that everyone is glad the Soviets lost the Cold War conflict. But it's plain that a lot of readers/contributors here actually think it's bad that the Soviets and their puppets lost ground. It's amazing, but they're out there. They're busy typing away on computers, hooked up to networks, freely expressing ideas in a setting that the Soviets would never have developed or allowed, and they think that the US was evil for having worked to shut them down. Oh well.

Re:Goose and gander

[minus_273]

well saddam got 99% of the vote as do many dictators. My point is who are you to say a government is legitimate.

Re:Goose and gander

[Goldarn]

See, now, your tone suggests that you're making rhetorical point that presupposing that everyone is glad the Soviets lost the Cold War conflict.

Yes, because even the stupidest people know that, if one side of a conflict is evil, then the other side much be totally and completely good.

The stupidest people know that, because the smart people know that evil fights other evil all the time.

Re:Goose and gander

[flyinwhitey]

It doesn't matter how extensively you seem to research your points, gross exaggeration and hiding behind the AC ruin any credibility you might have had.

"Overthrow and murder of Salvador Allende"

From wikipedia

"Shortly afterwards, Allende was dead, having shot himself with a machine gun, most probably the gun that bore a golden plate with the words "To my good friend Salvador Allende from Fidel Castro" engraved on it."

Care to provide some evidence of this so called "murder"? (and yes, I'm aware of the background)

See, if you ever wonder why people ignore the so called evil of the US government, it's because of people like you. After hearing so many similar lies from individuals like yourself, is it any wonder we stop listening?

Perhaps if you adopted the policy of not making incredible, unsubstantiated, unprovable, and most likely false claims, then your points would be taken seriously.

Re:Goose and gander

[Jherek Carnelian]

well saddam got 99% of the vote as do many dictators. My point is who are you to say a government is legitimate.

Dude, focus here - democractically elected - not sham elections. Ok? They were at least as legit as any US government has ever been. Dissonance can be hard to deal with, but please try to apply a little critical thinking first.

Re:Goose and gander

[Kohath]

See, now, your tone suggests that you're making rhetorical point that presupposing that everyone is glad the Soviets lost the Cold War conflict.

No, I know a lot of people wish the Soviets had won. It would be nice if they'd just tell the truth and be up front about it.

Re:Goose and gander

[Lars T.]

Many would rather see it go on, because the US is a bad winner.

Re:Goose and gander

[Lars T.]

Ahh, yes. North Viet Nam was supported by both China and Russia - who didn't like each other that much. But because there wasn't much happening, somebody had to come up with a reason for engaging in war - make that "a police action". And later Nixon decided to get out of that non-war, and started bombing the hell out of Nam and the surrounding countries first.

And talking about dividing up a country after war - why exactly did the US agree that the USSR was allowed to keep the part of Poland they conquered in the joint invasion of that country with Nazi Germany?

Re:Goose and gander

[Anonymous Coward]

You are wasting your time. US is perfect, everyone else sux. Get it, ok! Now go vote for some NeoCons.

Re:Goose and gander

[Derling Whirvish]

And talking about dividing up a country after war - why exactly did the US agree that the USSR was allowed to keep the part of Poland they conquered in the joint invasion of that country with Nazi Germany?

Because there was nothing the US could do about it.

Re:Goose and gander

[minus_273]

"Dude, focus here - democractically elected - not sham election"

Right, and you verified the elections of these people how? let me give you an example, Hugo chavez led a military coup to take over his country and then later was "democratically eleced" according to Jimmy carter. I am going to assume you consider his government legitimate.

I can tell you one thing, if the US hadn't intervened in many of those countries, the wouldn't have free democratic govenments today. It is far easier to remove a dictator who is just a man than it is to eliminate an entrenched political party/idea like communism. Compare N. korea to S. korea or taiwan to china... etc etc.

Re:Goose and gander

[Lars T.]

And I thought that it was the US alone that won the war, and the USSR was only a bit player.

Re:Goose and gander

[Jherek Carnelian]

Right, and you verified the elections of these people how?

You are so far in denial of the truth it is ridiculous. There is plenty of historical documentation of the fairness of those elections. Yet you waive your hands and with no proof whatsoever claim they were rigged. Stop lying to yourself.

Hugo chavez led a military coup to take over his country and then later was "democratically eleced" according to Jimmy carter. I am going to assume you consider his government legitimate.

You mean the FAILED coup of 1992 and his election, SIX YEARS LATER? In what bizarro world does a failed coup give one the power to rig elections over half a decade later?

As for the Carter Center's endorsement of the election, you cite that as if it is somehow a bad thing. Maybe in your bizarro Pat Roberston world it is, but in the real world there are few organizations with more credibility on election fairness than the Carter center. They aren't perfect, but at least he doesn't own gold and diamond mines in the countries that they monitor the elections of.

I can tell you one thing, if the US hadn't intervened in many of those countries, the wouldn't have free democratic govenments today.

Well, since they already had free and democratic governments when the US intervened to install non-free and non-democratic dictators I don't think you can really claim the eventual overthrow of those dictators as something that the US had anything to do with

As for your citations of n/s korea and taiwan/china - you REALLY need to learn some history. Freedom and democracy in both of those countries is only a recent phenomenon. Both of them suffered military dictatorships up until the mid-80s at least. Dictatorships that the US actively supported.

The fact that you marked me as a foe is just proof that you can't handle the truth and would prefer not to hear it at all - classic reaction to cognitive dissonance. Good luck with being an ostrich and all.

Re:Goose and gander

[minus_273]

"You mean the FAILED coup of 1992 and his election, SIX YEARS LATER? In what bizarro world does a failed coup give one the power to rig elections over half a decade later?"

maybe in the same world where you spend a few years in jail are pardoned, released from jail and then go on to openly re-form your old millitary coup group and then a couple of years later "win" an election. Look at when he reformed his military clique and when he won, there isn't much of a time difference don't count the time he spent in jail.

"As for the Carter Center's endorsement of the election, you cite that as if it is somehow a bad thing."

Yes, Carter is a leftwing leader and he obviously has his biases. I said that his verification of an election hardly carries any weight. Would you agree that if george bush verified a hosni mubarak landslide in Egypt that it would not be credible? same logic.

"As for your citations of n/s korea and taiwan/china - you REALLY need to learn some history. Freedom and democracy in both of those countries is only a recent phenomenon. Both of them suffered military dictatorships up until the mid-80s at least. Dictatorships that the US actively supported."

Did you even read what i wrote? they both became full democracies after the cold war ended. It was much easier to remove the military dictator in s. korea that it is to remove the communist in N. Korea. While i don't endorse military dictators, i can see where they may be "useful idiots".

Secondly, ad-hominem attacks are the mark of a person who has lost a debate. I marked you as a foe not because i dont like what you said ( could care less), but because of the way you said it. The fact that you can't argue a point without peppering your post with insults shows that you are immature and don't really have a point. Therefore, I don't need to see what you say. Don't bother replying to this. I'm not going to waste my time. Come back when you pass puberty.

Re:Goose and gander

[minus_273]

sir, you've been trolled. I doubt this guy knows what he is talking about.

Re:Goose and gander

[Jherek Carnelian]

Look at when he reformed his military clique and when he won, there isn't much of a time difference don't count the time he spent in jail.

Again, how does this in any way show that the election was rigged? Failed coup plus jail time somehow equals increased power? Could we get at least one shred of evidence from you to support your claims?

Yes, Carter is a leftwing leader and he obviously has his biases. I said that his verification of an election hardly carries any weight.

And I say baloney. The Carter Center has shown no bias in certifying elections won by leftist parties versus those won by rightest parties. Support your claims with evidence.

Would you agree that if george bush verified a hosni mubarak landslide in Egypt that it would not be credible? same logic.

Not at all logical. George Bush does not run a world-renowned organization that ceritifies elections. If he did, and the group actually had the credentials that the Carter Center does, then his certification of an election in Egypt would have actual meaning. But he doesn't so all this is more hand-waving on your part because you have zero, zilch evidence.

Did you even read what i wrote? they both became full democracies after the cold war ended. It was much easier to remove the military dictator in s. korea that it is to remove the communist in N. Korea.

Yes, I read what you wrote, it was historically ignorant nonsense and I said so. Do you know how S Korea got rid of the military dictator President Park Chung Hee in 1979? He was assasinated in a coup attempt. There were no democratic elections until 1987. That is not in anyway an endorsement of some sort of nascent S Korean democracy - heck mainland China was more democractic than S Korea was then. So, once again you provide no evidence to support your claims, and when faced with evidence to the contrary you simply deny it.

Secondly, ad-hominem attacks are the mark of a person who has lost a debate.

And constantly making up stuff without a single shred of supporting evidence is the mark of a crazy man. You've illustrated a profound ignorance of world history and when faced with the truth you just make up non-facts to support your claims. Ain't nothing ad-hominem about calling you out for that.

I'm sure that in your bizarro world everything you've claimed is obviously true, requiring no proof, which is why you never offered any. But in the real world, your behaviour in the face of actual facts is clearly illogical.

Not a bug

[stlhawkeye]

In a series of accidents, therapy planning software created by Multidata Systems International, a U.S. firm, miscalculates the proper dosage of radiation for patients undergoing radiation therapy.

I used to work with the lead programmer on this software package from Multidata. We worked together at two different companies for a total of about four years.

Multidata's software allows a radiation therapist to draw on a computer screen the placement of metal shields called "blocks" designed to protect healthy tissue from the radiation. But the software will only allow technicians to use four shielding blocks, and the Panamanian doctors wish to use five.

This is also made very clear in the documentation. This isn't a bug at all, the dosimitrists misused the software.

The doctors discover that they can trick the software by drawing all five blocks as a single large block with a hole in the middle. What the doctors don't realize is that the Multidata software gives different answers in this configuration depending on how the hole is drawn: draw it in one direction and the correct dose is calculated, draw in another direction and the software recommends twice the necessary exposure.

Exactly. They tried to create a feature that the software did not support, and they did so in a manner that broke the software.

At least eight patients die, while another 20 receive overdoses likely to cause significant health problems. The physicians, who were legally required to double-check the computer's calculations by hand, are indicted for murder.

It's not a software bug, it's a user error. This isn't a bug any more than it's a "bug" that your Linux box stops working properly if you do sudo rm -rf /. The users of the product knew better.

To be fair, Multidata was not a great shop from a procedural standpoint - the guy who ran it was insane, but the software was rock solid. I actually worked with a number of former Multidata employees who jumped ship and went to a rival shop that builds similar software, and they were all fairly competant and intelligent.

Re:Not a bug

[QuestorTapes]

> They tried to create a feature that the software did not support,
> and they did so in a manner that broke the software.

> It's not a software bug, it's a user error. This isn't a bug any more than
> it's a "bug" that your Linux box stops working properly if you do sudo rm
> -rf /. The users of the product knew better.

True. The problem is more that the software spec allowed this misuse and that it triggered a quietly lethal failure. It's a bad failure mode for medical device control software.

> ...the guy who ran [Multidata] was insane...

That's interesting. Any details?

Re:Not a bug

[drinkypoo]

I actually worked with a number of former Multidata employees who jumped ship and went to a rival shop that builds similar software, and they were all fairly competant and intelligent.

If they were so competant(sic) and intelligent, why didn't they make it impossible to create invalid configurations of the blocks?

Re:Not a bug

[JMan1]

Exactly. They tried to create a feature that the software did not support, and they did so in a manner that broke the software.

Except that the software didn't break well. It should have either reported that the action wasn't allowed or calculated correctly. It shouldn't look like it's working but give erroneous results. If a single block with a hole isn't supported, why are you allowed to select it?

Re:Not a bug

[bit01]

It's not a software bug, it's a user error.

It's both. The program should not have accepted easily recognised invalid input and the user should not have entered it.

I don't care if it's not in the spec, it's commonly accepted programming practice that all input should be bounds checked and any program that doesn't do that is crap.

Your rm example is not equivalent as command line programs are by design flexible; in unusual circumstances it may be exactly what the operator wants to do.

---

Keep your options open!

Re:Not a bug

[frankie]

It's not a software bug, it's a user error.

No. When you design software that is explicitly intended to perform potentially lethal actions on human beings, you absolutely make sure it's foolproof. You do input validation at every freaking step, then double-check the result before you pull the trigger.

If I go in for LASIK and get my retina burned off because some technician turned the wrong dial up to 11, you bet your ass I'm suing the manufacturer right along side the clinic. It should not be possible for the user to screw up the software when life is on the line.

Re:Not a bug

[barole]

I develop medical software for a living and this is the scariest thing I have ever read.

Your example is incomplete. Imagine that you type "rm -rf / junk" and the system responds "Delete /junk?", so you answer "Y" and it then deletes the whole filesystem.

It is most certainly a bug. First, there is a mismatch between what is shown on the screen and what the system is doing. That is a bug by any definition. Second, the system obviously had gaps in its validation of input. This makes it no less of a bug than many of the others listed (eg fingerd bug).

Furthermore, it is the responsibility of designers and developers of medical software to ensure that potential hazards are identified and mitigated. A hazard of "calculated dose does not match image shown on screen" is not some obscure hazard that no one would have thought of - it is the first that comes to mind!

Please tell me that these people are not involved in medical software anymore.

Re:Not a bug

[TheHawke]

To be fair to all, it was a glitch allowing the software to be flexable enough allowing the docs to program it in the manner that they did. Checkpoints and safety interlocks in the software would have stop-punched it right then and there.

Open-ended software allow folks to use it in ways that the original design didn't have in mind. This is good for it allows for upgrades without major recoding and patching. But as the example shows, it can also be very bad if a inexperienced user gets his/hers claws in it and tries to make it run their way.

Re:Not a bug

[Fat Cow]

From lessons learned from therac-25...here we see error #4 being repeated :)

Re:Not a bug

[stlhawkeye]

If they were so competant(sic) and intelligent, why didn't they make it impossible to create invalid configurations of the blocks?

They did. The configuration that the doctors in Panama laid out was valid, and the dose was calculated correctly. What happened was that they misunderstood the result.

Re:Not a bug

[stlhawkeye]

Except that the software didn't break well. It should have either reported that the action wasn't allowed or calculated correctly. It shouldn't look like it's working but give erroneous results. If a single block with a hole isn't supported, why are you allowed to select it?

The write-up is inaccurate. What they did was specify a block shape. This is a common feature of RTP software. YOu enter coordinates for the block and the software "closes" the shape. What they did was enter the coordinates in a certain order, say, clockwise to counter-clockwise. The software then closed the structure internally. For example, imagine a Cartesian 2-d graph and you want to define a square. You put in (1,1), (1,-1), (-1,-1), (-1,1), and you get a 2x2 square, right? But which part is the "inside" of it? The part contained within that shape or the part outside of it?

Depending on what order the coordinates were entered in, the software would determine the "interior" of the cerrobend block to be everything but the area that the doctors laid out, so they wanted a square but they got a plane with a square cut out of it.

This kind of thing is exactly why the results on screen should be hand-checked. The math is ludicrously simple to do this, a high school student could run the dose calc formula in a few minutes. It's nothing more than simple algebra to get an approximation that falls within 0.1% tolerance of the delivered dose.

Re:Not a bug

[stlhawkeye]

It's both. The program should not have accepted easily recognised invalid input and the user should not have entered it.

The input was not invalid. See below.

I don't care if it's not in the spec, it's commonly accepted programming practice that all input should be bounds checked and any program that doesn't do that is crap.

It checked the input and rendered the requested shape. What they got out of it was not what they were expecting, and they didn't hand-check the results, which would have revealed that the shape they defined was interpretted by the software to be everything BUT the area they wished to protect. This kind of error cannot be removed from code other than to remove the ability to do this, which no planner would tolerate, it's a common and oft-used feature.

Your rm example is not equivalent as command line programs are by design flexible; in unusual circumstances it may be exactly what the operator wants to do.

RTP software is also designed to be flexible. No two cancer cases are alike, every treatment is very unique and requires a unique solution.

I'm going to cut-and-paste this response to everybody's thread here since everybody's saying the same thing.

The write-up is inaccurate. What they did was specify a block shape. This is a common feature of RTP software. YOu enter coordinates for the block and the software "closes" the shape. What they did was enter the coordinates in a certain order, say, clockwise to counter-clockwise. The software then closed the structure internally. For example, imagine a Cartesian 2-d graph and you want to define a square. You put in (1,1), (1,-1), (-1,-1), (-1,1), and you get a 2x2 square, right? But which part is the "inside" of it? The part contained within that shape or the part outside of it?

Depending on what order the coordinates were entered in, the software would determine the "interior" of the cerrobend block to be everything but the area that the doctors laid out, so they wanted a square but they got a plane with a square cut out of it.

This kind of thing is exactly why the results on screen should be hand-checked. The math is ludicrously simple to do this, a high school student could run the dose calc formula in a few minutes. It's nothing more than simple algebra to get an approximation that falls within 0.1% tolerance of the delivered dose.

Re:Not a bug

[stlhawkeye]

No. When you design software that is explicitly intended to perform potentially lethal actions on human beings, you absolutely make sure it's foolproof. You do input validation at every freaking step, then double-check the result before you pull the trigger.

If I go in for LASIK and get my retina burned off because some technician turned the wrong dial up to 11, you bet your ass I'm suing the manufacturer right along side the clinic. It should not be possible for the user to screw up the software when life is on the line.

The software does indeed do input validation. Here's how it works:

What they did was specify a block shape. This is a common feature of RTP software. You enter coordinates for the block and the software "closes" the shape. What they did was enter the coordinates in a certain order, say, clockwise to counter-clockwise. The software then closed the structure internally. For example, imagine a Cartesian 2-d graph and you want to define a square. You put in (1,1), (1,-1), (-1,-1), (-1,1), and you get a 2x2 square, right? But which part is the "inside" of it? The part contained within that shape or the part outside of it?

Depending on what order the coordinates were entered in, the software would determine the "interior" of the cerrobend block to be everything but the area that the doctors laid out, so they wanted a square but they got a plane with a square cut out of it.

This kind of thing is exactly why the results on screen should be hand-checked. The math is ludicrously simple to do this, a high school student could run the dose calc formula in a few minutes. It's nothing more than simple algebra to get an approximation that falls within 0.1% tolerance of the delivered dose.

Re:Not a bug

[stlhawkeye]

Your example is incomplete. Imagine that you type "rm -rf / junk" and the system responds "Delete /junk?", so you answer "Y" and it then deletes the whole filesystem.

That's at all what happened, and is a far more flawed analogy than mine.

It is most certainly a bug. First, there is a mismatch between what is shown on the screen and what the system is doing.

That is not what happened. The write-up is not completely accurate. The screen showed EXACTLY what the doctors requested, but they misinterpretted what it was.

Second, the system obviously had gaps in its validation of input. This makes it no less of a bug than many of the others listed (eg fingerd bug).

The input was valid, or the block would not have been rendered. The input produced a cerrobend block that included a plane of everything except for the space enclosed by the coordinates they provided. This is why you hand-check results. See below.

Furthermore, it is the responsibility of designers and developers of medical software to ensure that potential hazards are identified and mitigated.

This is done with susprising rigor in RTP shops, but Multidata was well-known for being behind on its paperwork. Regardless, a hazard like this would not likely have any software mitigation built in.

A hazard of "calculated dose does not match image shown on screen" is not some obscure hazard that no one would have thought of - it is the first that comes to mind!

That's not quite what happened. Again, the write-up is inaccurate.

Please tell me that these people are not involved in medical software anymore.

Plenty of them are, they just work for different companies now in the same industry.

Re:Not a bug

[drinkypoo]

Not according to the article in wired:

The doctors discover that they can trick the software by drawing all five blocks as a single large block with a hole in the middle. What the doctors don't realize is that the Multidata software gives different answers in this configuration depending on how the hole is drawn: draw it in one direction and the correct dose is calculated, draw in another direction and the software recommends twice the necessary exposure.

Wired's not exactly known for correctness, but still...

Re:Not a bug

[Buck2]

Was the delivered dosage abnormal in any sense?

Would a blinking prompt saying ARE YOU SURE? have helped at all?

Re:Not a bug

[frankie]

results on screen should be hand-checked. The math is ludicrously simple

The software merrily blasted multiple patients with lethal doses of radiation, when it could have done "ludicrously simple" math and popped an alert dialog. Yes, the doctors screwed up. No, the developer does not get a pass. He is also to blame. The failure condition should not have been possible.

Typical software standards (e.g. version X.0 is effectively a public beta) absolutely do NOT apply to life-critical equipment. End of story.

Re:Not a bug

[Ernesto Alvarez]

Although in this incident there is a clear operator error (attempting to do some function clearly out of spec), the creators of the software are also to blame, if the problem was as you described it.

Changing the order of the vertices of a geometric figure should not affect the way the "inside" of the figure should be, since the order of the points is irrelevant (geometric-wise, as in mathemathics).

The software should have probably prompted the user (in all cases) which should be the inside area and not assumed something that is not clearly defined (especially since we're talking about a potentially lethal assumption).

As the sibling posts say, a better UI would have probably helped a lot, but there was a fatal mistake in the software from the beginning.

You shouldn't call software made under insane management and disregarding procedures "rock solid" (especially if there are deaths involved). It is definitely not. I would have supposed that software developers would have taken a hint after Therac-25.

Re:Not a bug

[AaronLawrence]

You're making it sound worse and worse. Even if you don't consider this a code bug, it seems like a disastrous user interface for safety critical software - therefore a massive failure of requirements specification.

Re:Not a bug

[stlhawkeye]

The software merrily blasted multiple patients with lethal doses of radiation, when it could have done "ludicrously simple" math and popped an alert dialog. Yes, the doctors screwed up. No, the developer does not get a pass. He is also to blame. The failure condition should not have been possible.

Typical software standards (e.g. version X.0 is effectively a public beta) absolutely do NOT apply to life-critical equipment. End of story.

The software recommends a dose. It's up the dosimitrist to verify that the recommended dose is correct. This is like saying that the Pentium chip with the floating point error should have the simple math to correct its own error. The software is given a gantry angle, beam angle, collimator data, etc, and calculates what the delivered dose ought to be to hit their goal. I don't think some of you responding to my post really understand how this software works, because you keep suggesting simple solutions to the "bug" that wouldn't have solved anything.

This post in particular ... I can't even characterize how ignorant your statement is. Alert dialogs ... there's just no way for the software to "know" that there's a problem here. It's up to the user to double check these things. What "failure condition" are you talking about?

Re:Not a bug

[frankie]

The failure condition is obvious: lethal doses of radiation delivered to patients by a software-controlled device. Res Ipsa Loquitur.

I don't think some of you responding to my post really understand how this software works

I understand how medical control software SHOULD work. If the software was designed to follow instructions blindly, then it was designed INCORRECTLY. Any software that is specifically intended to inflict physical changes on a human body should have built-in safeguards to prevent catastrophic error. I do not accept any other answer, and I believe the majority of western civilization would agree with me if asked.

2003 North American Power Outage????

[darthnoodles]

en.wikipedia.org/wiki/2003_North_America_blackout

From Wiki page:

It also found that FirstEnergy did not take remedial action or warn other control centers until it was too late because of a bug in the Unix-based General Electric Energy's XA/21 system that prevented alarms from showing on their control system, and they had inadequate staff to detect and correct the software bug. The cascading effect that resulted ultimately forced the shutdown of more than 100 power plants.

Re:omg

[greginnj]

And i suppose if I had a "broken" gun in my basement and you broke in and stole it, then tried to use it and injured yourself, you could sue me right?

...believe it or not, this is essentially true. A lawyer friend of mine (in NJ) tells me that if you booby-trap your house against thieves, a thief breaks in, and is injured, he can sue you and has some chance of winning. I forget what the actual liability is (it's not 'unsafe working conditions' or something urban-legend-sounding like that), but there are grounds for a suit.

Software Engineering makes reliable code

[ke4roh]

Testing techniques abound - unit testing, integration testing, data flow testing, and mutation testing to name a few. Scripting tests makes them repeatable, and if we test and test again, we can have some certainty of the reliability of the software. How? Software reliability engineering. See the book by John D. Musa. (See his web site, too.) It's all about using statistics and probability to analyze the likelihood of another failure in a certain amount of time. We all know it's cheaper to fix a problem earlier, so it's best to design the system so that, given the frequency of observed failures during testing and the cost of a failure, you set an acceptable risk and build the software to match the risk.

Re:Microsoft's striking absence

[lisaparratt]

The depressing nature of Microsoft's vast array of bugs induces a general cumulative increase in malaise in society as a whole, rather than having any incidents that jump out and grab you.

Maybe not terrorism...

[HotNeedleOfInquiry]

But certainly a tactic the RIAA would use if they could get away with it...

intentional bug?

[GuyinVA]

"1982 -- Soviet gas pipeline. Operatives working for the U.S. Central Intelligence Agency allegedly plant a bug in a Canadian computer system purchased to control the trans-Siberian gas pipeline"

can this really be considered a bug? It was an intentional software error..

Re:omg

[daniil]

I'd say that its intent was to INDIRECTLY cause terror.

You keep using that word, 'terror'. Are you sure you know what it means?

The fact that there was an explosion of such magnitude doesn't bother me a bit. And I bet the majority of the citizens of the USSR weren't shaken a bit by this explosion, because (drum roll) they never knew such an accident had happened (and that's, for me, the scary part). And nothing spells success better than an act of terror noone finds out about, now does it?

Re:omg

[FooAtWFU]

And i suppose if I had a "broken" gun in my basement and you broke in and stole it, then tried to use it and injured yourself, you could sue me right?

Right. I could. Also, if I were trespassing on your property and, say, slipped on your pool deck and got injured, I could sue you for that too. Shall I go on?

Not a bug but I think this is appropriate

[Iphtashu Fitz]

My dad tells this story from time to time. I don't know if it's true, but it makes a good story. Back in the early days of computers when only big corporations had them, most software was written in-house by staff programmers. One of the major soda manufacturers had a new mainframe and had one of their top programmers write an accounting package for them. It so happens that the manufacturer was a major competitor of 7-Up. Well for whatever reason the programmer left the company on not-too-good terms. The very next time the manufacturer when to print out a report from the accounting package, every 7th page contained the phrase "Drink 7-Up" in big block letters. They had their remaining programmers go back through the code and try to remove this new "feature" but they were unable to. This guy was so good that he'd embedded the logic for this nastygram right into the actual logic of the accounting package. Supposedly there was code that would dynamically generate other instructions that, when executed would generate other instructions, etc. They were supposedly unable to get rid of the 7-Up message without breaking other parts of the program, so they ended up having to go back to square one and write a whole new accounting package.

So the story goes...

I remember...

[grumpyman]

our 2nd year course professor spent 2-3 classes talked about Therac-25 in a C/C++ intro class. That always reminds me of how serious a bug can damage.

omg!

[daniil]

OMG! An idiot on Slashdot!

I find it a bit ironic that while your username states "Yahweh Doesn't Exist", you still keep calling up His name...

Priority!

[Sierpinski]

I'm really surprised that the Prius recall got in there over this bug:
http://www.ima.umn.edu/~arnold/455.f96/disasters.h tml.

Maybe I'm old fashioned, but loss of life is a bigger problem than loss of profit.

Re:Priority!

[Craster]

That links to two articles. If you mean the Ariane 5, then from the article:

This loss of information was due to specification and design errors in the software of the inertial reference system.

Not a bug. Bad specification and bad design.

What the heck is 'operatives'?

[grumpyman]

1982 -- Soviet gas pipeline. Operatives working for the U.S. Central Intelligent

How tactful! 'Operatives'? I'm sure the Chinese/Cuba counter-part will be called 'spy'.

Well, they're ok, but not quite the worst

[douthat]

I think the two worst computer bugs of all time are the two that quite possibly could have wiped us all out. More inforation here.

(Copied from the article:)
        * November 9, 1979, when the US made emergency retaliation preparations after NORAD saw on-screen indications that a full-scale Soviet attack had been launched. No attempt was made to use the "red telephone" hotline to clarify the situation with the USSR and it was not until early-warning radar systems confirmed no such launch had taken place that NORAD realised that a computer system test had caused the display errors. A Senator at NORAD at the time described an atmosphere of absolute panic. A GAO investigation led to the construction of an off-site test facility, to prevent similar mistakes subsequently. A fictionalized version of this incident was filmed as the movie WarGames, in which the test system is inadvertantly triggered by a teenage hacker believing himself to be playing a video game.

        * September 26, 1983, when Soviet military officer Stanislav Petrov refused to launch ICBMs, despite computer indications that the US had already launched.

        If it weren't for two humans who said "fuck what the computer says!", we might be in a very different place right now.

Re:Well, they're ok, but not quite the worst

[kisrael]

If it weren't for two humans who said "fuck what the computer says!", we might be in a very different place right now.

Good point. (Coversely, if either had been some kind of sneak attack, the side with the guy who hesitated would be more screwed).

I wonder about those red phones...isn't this the ultimate in gamesmanship? Would the USSR just say "what? no, no, no missles headed your way, must be some kind of glitch..."

Re:Well, they're ok, but not quite the worst

[hackstraw]

If it weren't for two humans who said "fuck what the computer says!", we might be in a very different place right now.

I guess that is why they were there.

Computers are excellent at performing according to the logic that is programmed into them. For the most part, they cannot "think" or take a step back and say, "I'm sure I did everything right, but something still looks wrong". I used to put on my math tests something like, "I know this is not the right answer, but here is my work". To me, that is much more important than purporting that the answer is correct, and most of the time, I had done something stupid that given more time than the class allowed, I would have found the error.

Just recently, I had an issue with my bank because I had just over my minimum balance to not receive a maintenance fee. But one month I did dip below that minimum value, and I put the money back in shortly after that. Anyway, for a few months I was still getting maintenance fees because the balance was going below the minimum value because the maintenance fee was causing the balance to go below the minimum again. I would go to the bank, show them my balance history, and they would say sorry and refund my account. However, the refund was not applied at the time of incident, but immediately, so next month I would get another fee.

Finally, I said, "Look, I can't keep coming in here to get this fee removed. Especially, when the fee is because of a fee, and I've been able to keep the balance at the agreed upon amount with the exception of when you keep billing me. I could put more money in the account to compensate for a fee so that it would not drop below the minimum, but in my eyes, that is similar to extortion. I can close the account if necessary." Finally, the banker put a fee hold on my account for 45days or so, and its only a memory now.

Re:Well, they're ok, but not quite the worst

[elemental23]

Coversely, if either had been some kind of sneak attack, the side with the guy who hesitated would be more screwed

Considering the probable outcome of an actual nuclear attack, it doesn't really matter, does it? Better to err on the side of caution, I'd say.

Re:Well, they're ok, but not quite the worst

[kisrael]

Well, to a rational mind it wouldn't matter so much but these guys were more strangelove than rational.

I guess that was the "beauty" of MAD...they knew if they reacted to a non-existent first strike, they would very like get a very real retalitory strike right on their heads.

Probably BS

[hughk]

I looked at this a while back because many millenia ago, I worked at the company that produced the telemetry/control system for the Trans-Sib pipeline. It was a specialised outfit based in Warwickshire, UK. It is very doubtdul that their systems could have nobbled by anyone. The network was closed, based on an X.25ish HDLC and the software was blown on to UV erasable EPROMs. The CIA may have modified the s/w at the pump stations, but again it is doubtful.

Re:Probably BS

[glesga_kiss]

The network was closed, based on an X.25ish HDLC and the software was blown on to UV erasable EPROMs. The CIA may have modified the s/w at the pump stations, but again it is doubtful.

The CIA (etc) don't sit behind IE flaws and root-kits. If they want to hack a network, they literally break in an attach what they want. Or they do it at the phone company and just man-in-the-middle on the line. Things like Carnivore are well known now, so it's not as if any of this is beyond the realms of reality.

Finally, they could have an employee on the inside. Probably the most likely candidate. "hey buddy, wanna help protect your freedom? Slip this in the next commie release and I'll give you a few thousand dollars". Like all security, the human link is the weakest.

Re:Probably BS

[timeOday]

I think it's more likely the CIA just called the president of the company and said, "hey, wanna help us screw the Soviets?"

Re:Probably BS

[flyinwhitey]

I think it's even MORE likely that the CIA called the president of the company and said "hey, do exactly what we want, or we'll screw you AND the Soviets"

Re:Probably BS

[glesga_kiss]

I think it's more likely the CIA just called the president of the company and said, "hey, wanna help us screw the Soviets?"

Wouldn't be too far fetched, certainally prior art of that kind of thing. It's well known that CIA and MI6 are actively involved in commercial espionage. Any business in the UK intending to sell overseas can drop MI6 and the Foreign Office a call and get access to normally restricted information. The Foreign Office is the legitimate face of this; the main difference being that they cannot bribe foreign officials. No such restrictions on MI6 of course! ;-)

Look up the Airbus scandal for more info. Granted, the espionage was used to prove other illicit dealings, but that's not the point! Well, I suppose it is...the lesson to learn is that everyone is at it.

Re:Probably BS

[hughk]

The first point is that the software was difficult enough to keep going anyway. To patch it would have needed too many people in the know. EPROMs were being reblown constantly to apply updates and code was being stepped through in EPROM emoulators. Dodgy code would have been painfully obvious to too many persons. There is a slim chance that it could all have been stabilised after I left, but that is unlikely.

The second point is how to ensure that nobody gets killed. Even at the height of the cold war, to cause the potential deaths of civilians in the USSR would be seen as a direct act of war.

Re:Probably BS

[BlueStraggler]

So if you knew you were working on the Trans-Siberian pipeline, how exactly did the Soviets "steal" your software (in the words of the article)? Did you not get paid, or is this a case of Cold War FUD, and anything the Soviets bought was described as "stolen" for propaganda purposes?

Re:Probably BS

[hughk]

I worked on the precursor project, TPEP (Trans-Penine Ethylene Pipeline). The Sovs bought the Trans-Sib telemetry/control system and this was no problem to export. This is why I cry BS. Perhaps the pump controllers had something special (we only interfaced to them).

They would certainly have had access to full technical data on all equipment (it is normal, even if we had retained service rights) and that may or may not have included source code. However all the engineers involved in deploying (and debugging) the systen would have had source and I don't think particular care would have been taken to ensure that it was "protected". Not that anyone would have learned much, as it was all in assembler.

Did the original post actually quote correctly?

[theshowmecanuck]

It would be nice if someone quoting a post in an article to sensationalize, at least made sure the quote was not misleading or wrong... there were no satellites in space during World War One, so of course the Halifax Explosion (which really was the largest non-nuclear explosion recorded) was not the largest non-nuclear explosion seen from space.

From the post:

The resulting event is reportedly the largest non-nuclear explosion in the planet's history.

The actual quote from a hyperlink in the article mentioned in the post:

"The result was the most monumental non-nuclear explosion and fire ever seen from space"

The actual largest non-nuclear explosion occured during World War One in Halifax Harbour when an munitions ship collided with another ship and exploded. It is known as the Halifax Explosion. It was picked up on seismographs and created an 18 metre tsunami.

Understanding the end user

[gmerideth]

Years ago, while working on a project for a medical firm, I found out first hand just how horrible things can go wrong with what we eventually agreed was a "bug" but was more of a "human bug" issue that made me sit up and realize that it's not just programmers who will use our programs.

Without getting to detailed, the end users were allowing certain conditions to go unchecked as the software was telling them it was "OK". There was a rather neat explosion (read, small) that hurt nobody and damaged some equipment because instead of being "OK" it was telling the operator that there was exactly "ZERO K" of space available for data storage on a recording device and the test needed to be shutdown.

Now, the operators were told that when the counter got low the would see a warning and be told to stop the tests so, was it a bug, was it my assumption that these 11.95/hour service techs would "understand" what "0K" means from "OK" (that's a zero(0) and an O there)? Either way, there was some damage, we had a bit of a laugh, but at least nobody got irradiated and died.

Y2K

[Dausha]

What about the Y2K bug? I believe that had a greater economic impact than many of the other "worst."

Re:Y2K

[sjames]

While Y2K was widely reported as a bug, that is not quite true. In many cases, the problem was that the software was in use LONG beyond it's design lifetime. When the software was written in the '70s, memory on a mainframe was measured in K not meg. The extra 2 bytes for the year would have been an extravagance. Further, 9999 made perfect sense to indicate end of input since the software was meant to be retired well before September 9th, 1999.

I do not characterise that as a bug since the ill behaviour late in the '90s was fully expected (and even documented) by the original programmers. A bug would imply that the software behaved in a way that was not expected.

>p>For that ancient software, the fact that it was still in use beyond it's design lifetime (and in fact, beyond the design lifetime of it's hardware platform) and the sourcecode either lost or still on punchcards and still untranslated from COBOL (which practically nobody bothers to learn anymore) is a management problem. There's a reason they're called MIS-managers :-)

The later code that had the problem (including all Perl CGI) was a matter of carelessness. The blame there lies with the designer and in some cases management. Much of the problem code was a quick and dirty hack to 'get the job done'. That might be a design decision (in which case it's design lifetime should have been months to a year), or was management driven in the classic case of manager pulls dreadfully short timeframe from his nether region, skips QA, and gives the assignment to the first inexpensive warm body who says I can code the web or threatens to if the decent programmer continues to insist on a design and QA phase. In the latter case, the "director's cut" of the docume ntation would read: This is a piece of crap that might do nearly anything but work properly. So, no bug there, it was expected. In the warm body case, the 'programmer' probably shouldn't have been a programmer. In the throwaway code case, management failed to throw the code away!

Re:Are you sure the grass is greener?

[symbolic]

Would licensing prevent the multi-million dollar debacles created by large consulting firms that seem to routinely escape any means of accountability? Would an individual programmer's license have any effect whatsoever on the QA portion of a development project? Or the management? Or any decisions that are completely outside the control of any individual license holder?

I certainly don't advocate sloppy programming, but I'm not entirely sure that licensing would have the desired impact. If anything, it's just more red tape.

Mars Climate Orbiter -- English/metric SNAFU

[alumshubby]

speaking of NASA foulups, Remember this one? "(CNN) -- NASA lost a $125 million Mars orbiter because a Lockheed Martin engineering team used English units of measurement while the agency's team used the more conventional metric system for a key spacecraft operation, according to a review finding released Thursday."

A radiology system written in Java 1.1????!

[Viol8]

If they were that worried bugs and so forth they'd have written it
in ADA or a similar far more reliable language than that piece of
junkware. Back in 1997 you couldn't rely Java and its VM to run a
clock without crashing , never mind a life critical piece of equipment!
What the fsck was your company thinking???!

Re:A radiology system written in Java 1.1????!

[koehn]

It really doesn't matter what language you use: bugs can be written in any of them. In this case, the customer wanted a GUI workstation running on Windows, with the possibility of being cross-platform. Java was new and cool (1.1 had been out for six week when we started), and they decided to give it a shot. This is a company with fifty years experience in medical systems, not some dotcom startup, so the procedures are in place to make sure that their products don't kill people.

As it turns out, JDK1.1 (along with a native-C library for quick image processing, and a custom PCI card for doing 30MB/sec image transfers) was just fine for the task. We had a team of seven testers working on the project full time for a year, and were able to ship with zero severity 1-2 defects.

We set a new record for lowest defects/KLOC at the customer (a major player in the medical systems industry), despite running JDK 1.1 on Windows NT 4. Our product was several times faster than the C-based product it replaced, had more functionality, and provided more accurate diagnosis for the patient.

Good design is the most important thing in developing good software. The language/runtime/OS can provide crutches to save you if you screw up, but bad design will result in defects no matter how sturdy the crutches are.

Re:A radiology system written in Java 1.1????!

[SeanAhern]

Am I correct in assuming that Java wasn't the system which actually interfaced to the hardware control systems? It sounds like it was primarily the GUI at the user end, and other software (possibly embedded) handled the actual hardware control mechanisms that turned the radiation beam on and off.

Re:A radiology system written in Java 1.1????!

[renoX]

> It really doesn't matter what language you use: bugs can be written in any of them
Sure but a VM is more complicated than a simple compiler as it adds another layer..
And being new is not an advantage either: I remember having being burnt by a GC bug in 1.1.7 (can't remember exactly which version it was in 98 I think) where the GC would remove objects when they were only referred by a static handle (classic singleton pattern).
So by using a 'brand new' system, not only you have to care about your bugs but also about the bugs which weren't ironed out of the system yet.

For a system where reliability is paramount, I wouldn't go to the latest fashionable thing!

Re:A radiology system written in Java 1.1????!

[koehn]

It was a GUI/workflow app, not a hardware control system. Diagnostic Radiology is when a radiologist is looking at your images (think of the digital equivalent of a lightbox on the wall). Our system could bring up the patient's historical exams (useful for cancer patients), cross-reference exams in different orientations (coronal, saggital, and axial), make annotations, and dictate a diagnosis into an automated dictation system.

Radiation treatment is the kind of system where there's a gun to turn on/off. This is a system some friends of mine have built that is truly amazing. If you have a lung tumor near the spine, this thing takes into account your lungs' expansion while you breathe (in realtime) as it administers the dose. The math is, umm, a bit stunning.

Re:A radiology system written in Java 1.1????!

[koehn]

I remember having being burnt by a GC bug in 1.1.7 (can't remember exactly which version it was in 98 I think) where the GC would remove objects when they were only referred by a static handle (classic singleton pattern).

Holy cow I remember that bug! You needed to use the -noclassgc option to keep it from happening.

While I agree that when using a new system you'll find more bugs, it doesn't mean that you need to do any less testing on an older, more "established" system. That's the mistake made on several of the bugs in the article: they assumed that since the underlying components were used before, they must be stable.

Re:A radiology system written in Java 1.1????!

[SeanAhern]

It was a GUI/workflow app, not a hardware control system. Diagnostic Radiology is when a radiologist is looking at your images (think of the digital equivalent of a lightbox on the wall). Our system could bring up the patient's historical exams (useful for cancer patients), cross-reference exams in different orientations (coronal, saggital, and axial), make annotations, and dictate a diagnosis into an automated dictation system.

That makes sense. With this in mind, Java works perfectly in this situation. I would probably have chosen PyQt, but I'm quirky that way. Java's probably an even better solution. Congratulations on a successful project!

Radiation treatment is the kind of system where there's a gun to turn on/off. This is a system some friends of mine have built that is truly amazing. If you have a lung tumor near the spine, this thing takes into account your lungs' expansion while you breathe (in realtime) as it administers the dose. The math is, umm, a bit stunning.

That's impressive. I've worked with people who do the tomographic reconstruction from the raw data from MRI/CT machines, and I've had them explain some of the math to me. Impressive stuff.

Re:A radiology system written in Java 1.1????!

[renoX]

You're right that even with 'well used' components, there may still be bugs and you must test both, unfortunately tests don't always show the problems (Murphy's "law") and using proven components may still be wise.

To Err Is Human

[skidoo2]

Second paragraph, first sentence: Spelling error. "Pruis."

Re:To Err Is Human

[6*7]

Toyota uses the name Pruis on it's Aussie website: http://www.toyotamotorsport.com.au/heritage/timeli ne/

Re:You get what you pay for NONSENSE

[mumblestheclown]

Some of you marked the parent comment "insightful" because it doubtlessly seemed like commonsense, reasonable analysis.

However, you have been fooled. The parent comment is competely at odds with the article.

The article shows largely a series of examples where you DID have HIGHLY PAID and HIGHLY trained professionals with plenty of experience and oversight, but nevertheless very significant bugs occurred. So, the real lesson from this article is not "you get what you pay for," but rather that "software development is very hard" and perhaps that "by nature of its hardness, we can expect critical flaws to pop up from time to time, even when highly trained, experienced, and monitored programmers are involved."

Thanks for proving my point

[kcurtis]

The Soviets stole blueprints and built a gas line using it. What part of planting faulty plans is unlawful? They were stolen.

The US action was not unlawful. Hence, the action was not terrorism.

Now, do I think the CIA engages in terrorist activite? Well, quite possibly. But this doesn't even fall near that. It was a counter-espionage act designed to foil the success of an enemy's spying activities. And it worked.

Computers, Ethics, and Society

[Kelson]

When I went through college, the computer science program had a required course on the "Social Impacts of Computing" -- everything from the privacy implications of data mining to deaths. The Therac-25 case was required reading.

One thing that stuck in my mind was a point that it takes decades to see the true impact of any new technology. The telephone, the automobile, the airplane. Look at the US highway system and suburbia for impacts of cars that took 50 years to really hit. We're just beginning to see the wider impacts of computers.

Abuse of language

[Presence1]

"That CIA gas plant explosion 'bug' is disgusting and has America == No.1 Terrorist written all over it if true."

I might as well say: "Idiots like you that corrupt the language are worse than terrorists."

Both are absurd exaggerations that have nothing to do with reality, and only degrade the ability of our language to carry meaning.

Get Real. Terrorism is the deliberate use of violence against civilians in order to induce a state of terror in the general population, as a method intended to achieve political, religious or ideological goals.

The CIA were not using violence, they were attempting to cause stolen technology to fail.

The CIA were not targeting civilians. Moreover, AFAIK, not one person was even killed in the explosion, which happened in a very remote area, and the specific explosion was certianly not planned (they had no knowledge of or control over how the Soviets used the stolen technology).

The CIA were certainly neither attempting to induce a state of terror, not cause change by inducing a state of terror.

You want to oppose the US government? Great -- there are many good bases on which to do so. But please, before you speak up next time, get some facts, learn how to use the language, and THINK! You might then have a chance of convincing somebody of your point, instead of just annoying them with your ignorance.

Re:Abuse of language

[Terralthra]

The fact that other people misuse the word does not mean you aren't too.

The GP is correct. Unless it is a deliberate attempt to incite terror (thus the name), it isn't terrorism. There are other words, like sabotage, or espionage, that describe the act committed.

A person wearing a coat on a warm day isn't a terrorist either. The authorities not respecting habeus corpus, probable cause, etc., doesn't make them right and correct in what they label things.

Re:Abuse of language

[Presence1]

Other more authoratative books and articles indicate that the software was stolen. See:
http://en.wikipedia.org/wiki/Farewell_Dossier
and
http://bmonday.com/archive/2004/02/27/583.aspx

Even if the gas pipeline control software was purchased, the articles and reasonable logic indicate that CIA put the bugs in the Soviet version, and not the general version. I don't see you producing a shred of evidence or even allegations to support your implication that they let the bugs spread generally, caused other explosions, deaths, and bankrupted the company. This is nothing more than inuendo.

Let's keep the argument on point. It is NOT about whether this is right or wrong, but that it does not qualify the US as terrorists. Hacking and sabatoge alone do not qualify you as a terrorist, any more than terrorism in the vicinity of a computer qualifies you as a hacker.

Re:Microsoft's striking absence

[zootm]

I guess the difference is that that bug isn't really likely to come up in standard usage. Although it was widespread and known for so long, it never caused any widespread problems, unlike every example in that rundown, which are all worse.

I'm not saying it's not serious — it clearly is. It's just less serious than each of the ones in the article.

Not that "bug found in relay" story again

[Anonymous Coward]

With that recall, the Pruis joined the ranks of the buggy computer -- a club that began in 1947 when engineers found a moth in Panel F, Relay #70 of the Harvard Mark 1 system. The computer was running a test of its multiplier and adder when the engineers noticed something was wrong. The moth was trapped, removed and taped into the computer's logbook with the words: "first actual case of a bug being found."

I hate to be pedantic (well no, I love it), but according to the Jargon file's entry on "bug":

Indeed, the use of bug to mean an industrial defect was already established in Thomas Edison's time, and a more specific and rather modern use can be found in an electrical handbook from 1896 (Hawkin's New Catechism of Electricity, Theo. Audel & Co.) which says: "The term 'bug' is used to a limited extent to designate any fault or trouble in the connections or working of electric apparatus." It further notes that the term is "said to have originated in quadruplex telegraphy and have been transferred to all electric apparatus." ...

Actually, use of bug in the general sense of a disruptive event goes back to Shakespeare! (Henry VI, part III - Act V, Scene II: King Edward: "So, lie thou there. Die thou; and die our fear; For Warwick was a bug that fear'd us all.") In the first edition of Samuel Johnson's dictionary one meaning of bug is "A frightful object; a walking spectre"; this is traced to 'bugbear', a Welsh term for a variety of mythological monster which (to complete the circle) has recently been reintroduced into the popular lexicon through fantasy role-playing games.

But then again, why expect more from Wired.

Re:Not that "bug found in relay" story again

[expeorian]

The article doesn't say the Mark I incident was the origin of the term "bug." What the article says is that this was the first known computer bug. If you're going to be pedantic, it pays to read what the article actually says.

Re:You get what you pay for NONSENSE

[cryptoguy]

> The article shows largely a series of examples where you DID have HIGHLY PAID and HIGHLY
> trained professionals with plenty of experience and oversight...
> ...software development is very hard

You are absolutely right, it is hard. You really are making the same point I am. What they thought was enough, was not. It's not a matter of paying the same people more money. It's a matter of taking more time and using more developers, and more experienced developers. It's also a matter of more careful design (ie more time and expense), more design reviews, more code reviews, more testing, all by more experienced people. It sounds like you are throwing up your hands and saying "It's hard, so accept the bugs and get over it". OTOH I'm saying that more and better resources, properly developed and managed, can make a critical difference.

MOD PARENT DOWN

[igny]

Interesting???? More like a troll.

*Phew*

[Anonymous Coward]

Looks like they haven't found the bugs in my code yet

Soviet gas pipeline explosion

[dtfinch]

That was a feature, not a bug.

Re:You get what you pay for NONSENSE

[Bastian227]

Some of you marked the parent comment "insightful" because it doubtlessly seemed like commonsense, reasonable analysis.
However, you have been fooled. The parent comment is competely at odds with the article.

Technically, the parent was responding to his parent, not the article. In any case, I think agreeing with (or repeating) an article makes insightfulness more difficult. Some of the most insightful statements come from disagreement and tangental thinking.

Oh?1

[Poromenos1]

See this comment. Of course you can always screw something up, but as the poster says, you can mathematically prove that some classes of bugs will not happen. But well, you can take my "ensures" to mean "lowers the probability of an error to a negligible amount" if you want.

Re:You get what you pay for NONSENSE

[mumblestheclown]

This is fair enough, but if the claimed "insightfulness" is so much at odds with what has just been so clearly demonstrated via serious examples in the article, then in my book a little more than blatant assertion is needed to qualify as "insightful."

Show of hands?

[ekc]

I wonder how many people reading this thread are working on software that could potentially cause bodily injury? I unfortunately have to count myself in that category, as I am coding for a new geophysical transmitter which handles a considerable amount of current, and there are both software and hardware fail-safes that need to work. Some of the key electronics are fibre-optically isolated, but you can only go so far...

Re:Microsoft's striking absence

[NanoGator]

"MS isn't mentioned ONCE."

It's less striking when you read the article. Most people wouldn't use Windows to control a rocket.

Re:Microsoft's striking absence

[Greyfox]

This may have something to do with Microsoft's striking absence in critical control systems. It's easily understandable for rockets and satellite guidance systems where you don't really have a whole lot of OS to begin with. Someone less intuitive is absence in medical control software etc. But then if I walked in and saw that the machine that was about to pump tons of radiation into me was running Windows, I'd turn around and walk back out. I'd personally consider my chances with cancer to be better than my chances if I put my life in the hands of Microsoft's software.

Make no mistake, Microsoft software does have flaws and they cost society billions of dollars a year. They're just not as blatantly obvious as having a rocket explode on lift-off or shooting a patient full of too much radiation.

Re:Microsoft's striking absence

[borawjm]

While I'm not sure if anyone has been directly killed by a machine running a windows product, I can probably be assured that many monitors, keyboards, and computer cases have been smashed and thrown out of buildings because of their software.

Never lived it down...

[Linker3000]

10 PRUNT "Hello World

My faith is restored

[A nonymous Coward]

I saw the idiot's reply to my parent post, daring me to name any legitimate government the US overthrew, knew that would happen, and dreaded having to respond to anyone that ignorant because I'd want to go get dates and references and everything ...

And you guys came thru for me! Hot damn that is good :-)

this was not a bug

[Anonymous Coward]

According to several docs, this system was taken down by mod.

January 15, 1990 -- AT&T Network Outage. A bug in a new release of the software that controls AT&T's #4ESS long distance switches causes these mammoth computers to crash when they receive a specific message from one of their neighboring machines -- a message that the neighbors send out when they recover from a crash.

One day a switch in New York crashes and reboots, causing its neighboring switches to crash, then their neighbors' neighbors, and so on. Soon, 114 switches are crashing and rebooting every six seconds, leaving an estimated 60 thousand people without long distance service for nine hours. The fix: engineers load the previous software release.

Re:this was not a bug

[narcc]

MOD had nothing to do with it -- yes, the system went down while MOD was under investigation but the problem itself was tracked to a bug in a software update that was applied *three weeks* before the crash. None of the MOD boys were ever charged with anything related to the AT&T incident.

For a good account check out Masters of Deception by Michele Slatalla (theres a used copy on amazon right now for like 83 cents -- snatch it up, its a good read)

Mangement problems

[gr8_phk]

"...trained professionals with plenty of experience and oversight, but nevertheless very significant bugs occurred."

Some of the bugs reported in the story were not so much the fault of programmers, but of management. The phone network bug was a misplaced { character in a nested if-else construct. The code had already been though extensive testing, and then a small change was needed. Because it was a "minor" change someone said it didn't need to go through the extensive (expensive) testing again. It's always easy to point at the code or the guy who wrote it. Especially when the boss is the one tasked with finding out what went wrong.

Re:Mangement problems

[TFloore]

The phone network bug was a misplaced { character in a nested if-else construct.

Is that what it was? I thought I'd heard that the AT&T outage was from a missing break; in a switch-case statement.

I found that more believable, because a missing { would cause a compiler error, where a missing break; is a valid way to purposely fall into the next case.

Though, really, I suspect both of us are just repeating rumors we heard.

Re:Mangement problems

[petermgreen]

yeah missing and misplaced breaks (if something has to be brought out of a switch for some reason and is inside a loop) can cause hell its kind of a design issue with the C switch statement that if you don't wan't fallthrough you have to explicitly tell it you don't.

C is an old language that is full of quirks. Its dervivitves have got rid of some but not all of those quirks.

Re:Mangement problems

[gr8_phk]

I was going from memory, but I recall reading that it was a misplace bracket that still allowed the code to compile but changed the meaning of it. A missing bracket of course would fail at compile time. A missing break in a switch statement would be similar and may have been what happened.

For a really interesting mess, I once saw a VB program that contained a conditional goto from the "then" portion of an "if" into the later half of the "else" portion. Yeah, I would have shot the guy if I didn't work for him at the time. OTOH, he knew just how bad it was - but it worked.

Re:Mangement problems

[diablomonic]

WOW...that is bad :) did he do that sort of stuff a lot?

Re:Mangement problems

[HeroreV]

yeah missing and misplaced breaks (if something has to be brought out of a switch for some reason and is inside a loop) can cause hell its kind of a design issue with the C switch statement that if you don't wan't fallthrough you have to explicitly tell it you don't.

I see that you're new to Slashdot. Welcome.

Re:Mangement problems

[HeroreV]

Could you give an example? I can't imagine when something like this would be needed.

Re:Mangement problems

[petermgreen]

while i admit i'm slightly newer here than you (at least as a registered user i was posting as an AC long before i got an account here) i'd like to know what it was in your post that make you give the "you must be new here" response.

The CIA bug...

[Hymer]

...is not a bug. It was planted on purpose. It is malicious code, a trojan or virus.

Gough Whitlam

[A nonymous Coward]

I looked him up in the wikipedia, and don't understand what you mean. The US has fooled around in countless elections and domestic affairs around the world, but I don't know what you mean in this case. Care to elaborate?

Re:You get what you pay for NONSENSE

[tyen]

...you DID have HIGHLY PAID and HIGHLY trained professionals with plenty of experience and oversight, but nevertheless very significant bugs occurred...So, the real lesson from this article is not "you get what you pay for," but rather that "software development is very hard"...

It doesn't matter how highly paid and trained your professionals are, if the environment that produces the software is not conducive to eliminating these types of flaws. Like if they are not given enough resources to test and QA the the projects they are assigned, there is no organizational commitment to take the time and expense to document properly, or leadership overrides technical objections to project timeframes, etc. Most of the cited projects could probably be classified as failures of project management rather than failures of the end product (the software) that these flawed projects produced. Yes, software is hard and the software profession should continue its efforts to improve quality, but that doesn't let the organizational culture, leadership and processes that produced the software in these cases off the hook.

Why is it when the accounting profession makes spectacular mistakes that take down entire Fortune 500 class organizations, there is a critical analysis of the processes that led to these failures, and remedies often comprise prescriptive measures for these processes, but similar analysis for software failures focus upon the software flaw but not the environment that allowed the flaw to emerge? Now sometimes the remedy in the accounting case might not make complete sense (like SOX), but the point here is people don't look at just the end result (the accounting system transactions) of the accounting process.

Re:Whoops forgot to hit preview

[brunson]

I was informed that in the state of Texas it is illegal to use the word "engineer" in your job title unless you a) have passed the P.E. exam or b) drive a train.

And that's the way it should be.

Re:Microsoft's striking absence

[21chrisp]

No they use Command+F ;-)

From the quoted article...

[Anonymous Coward]

Some outside observers, however, said they are not convinced NT is blameless.

"It still boggles the mind that any divide by zero error on NT would cause a system to crash, let alone" 27 end-user terminals, said Gil Young, corporate network engineer for a systems integration firm in Orlando, Fla. "I don't care what operating system, computer or application I'm using, I should be able to type in a zero and expect the computer not to crash, especially if that zero is to represent a closed valve."

Re:From the quoted article...

[BroadwayBlue]

Interesting. Reminds of a college math professor who gave no partial credit. His reason: the Challenger disaster. He claimed that someone miscoded the field for temperature range. Apparently there was a certain temperature range within which the Challenger could launch. Zero should have been out of it, but it wasn't coded properly...and null equaled zero. So when someone didn't put in a temperature, the Challenger launched when it shouldn't have and a couple minutes later it was over. I dunno if that is accurate or not, but that was his story. A visiting prof from Russia or the Ukraine. /shrug

Re:Microsoft's striking absence

[gmuslera]

3 words: "Out of contest".

In fact, what MS products have goes beyond what the weak word "bug" transmit (check this movie poster for a small example) unless you put the Heinlein's Starship Troopers ones in that category.

Anyway, i would had put in that list when Windows NT killed a navy ship... maybe losing a rocket could have been more expensive, but windows NT is more widespread and probably still used in critical places.

Re:Whoops forgot to hit preview

[RobinH]

Look, I write software for control systems (and I design them electrically too). Just because programmers at Microsoft or EA Games have tight schedules where they are just too stressed to write code well doesn't mean all code needs to be written like that.

Back to what you were saying, if you have a system that could cause damage or whatever, then you start by writing your output routines, and you create rules to govern the machine (i.e. outputs A and B can't come on at the same time, or output C can't exceed this value). Then you write another module that monitors the inputs AND outputs looking for fault conditions that shuts down the machine if you do anything dangerous. Only this part of the code needs to be signed off by an engineer. Typically it's simple code, and easy to prove correct, with peer review. Then you write other modules that essentially make requests through the safety checks to do anything. You don't have to review the complex other code so much, because your output stage should catch any mistakes.

That's how you make a machine safe. Unfortunately, most engineers I know just go out and write the software figuring there's no difference, and that's how bad things happen. It comes from believing you won't make a mistake, or believing that testing will catch all problems. If you plan from the start that you're going to be making mistakes, you can catch them before damage is done. It's too bad this isn't taught, even in the software engineering classes I took at a Canadian university.

Re:Time for stressing more on formal specification

[ashtophoenix]

But isn't that true for any system, and not only software? That if it is used other than for what it was designed for, it could fail. Suppose I need to make a simple function for generating prime numbers from 1000 to 500000, then tht would be my interface and then I could verify its correctness using a formal method verification system (or an automatic verifier). Of course this is making it extremely simplistic...but I think there are occassions where formal verification can, if not eliminate, highly reduce the number of bugs. Although, at the state that I had read about it, it would probably take years to write a system of medium complexity using such a method!

Building safe systems

[uncqual]

Basically you'd have to have one engineer, or team thereof, overseeing the entire project to be sure that proper methods are being followed to ensure that there aren't any bugs.

Ah, but any such engineer would by definition be unqualified as they would have to think they can do the impossible. First, one can't insure that there aren't any bugs in real systems using current technology (or even anything on the horizon). Second, while having methods, processes, and tools to increase requirements, design, and code quality is important, simply "following methods" insures very little about the resulting system's quality if those doing the following are idiots or just don't care much.

It's important that life critical software (and hardware) not only have few bugs (and good requirements yada, yada), but that it is designed defensively - which may require additional sensors and additional hardware in addition to watchdog monitors etc.

For example, even if you're pretty sure that the software in a machine won't decide to pump a liter of morphine into the patient within ten seconds, you should have some hardware/software combination that stops such absurd and deadly results even if the primary software fails (or the operator made an absurd error which the primary software failed to catch).

For another example (since I didn't RTFA), I don't know if they list the irradiation device that killed at least one patient because a bug (in a driver associated with keyboard input IIRC) resulted in a shield (which should ALWAYS have been in place if the "more powerful" radiation source were used) not being moved into place before the more powerful radiation source was activated. IMHO, this system should have had an independent (probably electromechanical) system that just REFUSED to activate that radiation source if independent sensors didn't detect that the shield was REALLY in place (and, perhaps even, that the shield had just recently been retracted and extended - to help detect failures in the "shield sensing" device or an operator's misguided attempts to fool the system).

Re:Building safe systems

[uncqual]

(I actually went and refreshed my brain on the overexposure to radiation case after many years - my "shield" description is very simplistic although the general idea is correct. So, don't do any designs based on my prior post as I will disavow all liability)

Re:Building safe systems

[Hrvat]

The Therac-25 medical accelerator case involved exactly this. The previous version of the machine actuall did have electro-mechanical redundant safety systems. They were removed in the new (25) version. Thus when the previous version of the machine with the new software failed, the safety systems actually kicked in and stopped overexposure and the bug was not detected there.

The new machine was the problem. Without the safety systems the underlying bug was exposed and people died.

Re:Building safe systems

[Fulcrum of Evil]

Ah, but any such engineer would by definition be unqualified as they would have to think they can do the impossible. First, one can't insure that there aren't any bugs in real systems using current technology (or even anything on the horizon).

Look one comment up. You can ensure that no bugs create a dangerous condition, which is different from no bugs at all.

For another example (since I didn't RTFA), I don't know if they list the irradiation device that killed at least one patient

Therac-25, and they'd better have listed it - it's damn near canonical.

Re:Building safe systems

[uncqual]

You can ensure that no bugs create a dangerous condition, which is different from no bugs at all.

Actually, no you can't insure even that there are no dangerous bugs. You can reduce the probability, but for practical systems you can't reduce it to zero with current technology. Obviously if you could eliminate all dangerous bugs, you could (at some cost) eliminate all bugs by declaring all bugs as "dangerous" and tracking all of them down. Of course, sometimes a "bug" is not a coding error but a design or requirements flaw.

Re:Building safe systems

[Fulcrum of Evil]

Actually, no you can't insure even that there are no dangerous bugs.

Yes you can. The post I referred to described a way to do this by constraining outputs to known safe values. There are still bugs, but none that can hurt you.

Obviously if you could eliminate all dangerous bugs, you could (at some cost) eliminate all bugs by declaring all bugs as "dangerous" and tracking all of them down. Of course, sometimes a "bug" is not a coding error but a design or requirements flaw.

Nope, declaring a bug dangerous doesn't make it so. When I talk about dangerous bugs, I mean actual physical danger.

Re:Building safe systems

[uncqual]

Yes you can. The post I referred to described a way to do this by constraining outputs to known safe values. There are still bugs, but none that can hurt you.

I think my point is being missed... If software is doing the checking for safe values, you still can't be SURE that there are no bugs. You can be comfortable enough to ship it, but not 100% sure. Even if there is no OS (and hence no OS bugs) and you have a separate processor, memory, busses etc. for checking, you need to prove that the processor and chipsets have no bugs - I don't know of any such proofs. The software doing the checking obviously needs to be written in machine code or by a PROVEN (in the formal sense) compiler (I assume someone has written one of these somewhere in academia for a simple language). The machine code version of course is harder to check as well as a high level language version (and easier not to notice the failure of the programmer to check a timer value for wrap or handle an ECC memory trap correctly).

Anyway, I'm just being pedantic about 100% vs. 99.99999999% (although, who knows how many 9's)...

Re:Building safe systems

[Blue23]

Actually, no you can't insure even that there are no dangerous bugs.

Yes you can. The post I referred to described a way to do this by constraining outputs to known safe values. There are still bugs, but none that can hurt you.

Doesn't work in all, heck in MANY cases. Your input assumes you know all states, and can determine everything that's dangerous.

Take air traffic controller software. List all dangerous conditions. You can't. You can make reasonable assumptions, but EVERY condition isn't possible. Maybe the problem end up being that you've got a radar Hw error flooding the software with over 2^32 signatures, and the programming language dies with arrays that big. You can't think of every possibility.

That why firewalls don't say "these are bad conditions, keep them out". They say "this are good conditions, keep everything else out."

But that's not always practical - I can make a radiation therapy machine perfectly safe - it'll never turn on. But if you want the system to deal with potentially unsafe conditions, having the hubris to assume you can identify every dangerous condition in your output state isn't reasonable except for the simplest of projects.

Cheers,
Blue

Re:Building safe systems

[Fulcrum of Evil]

Doesn't work in all, heck in MANY cases. Your input assumes you know all states, and can determine everything that's dangerous.

No, I assume that I know the most common states, and that I know which of those are safe. Everything else is dangerous.

Take air traffic controller software. List all dangerous conditions.

List all safe conditions that you're willing to deal with. Everything else is declared as dangerous.

But if you want the system to deal with potentially unsafe conditions, having the hubris to assume you can identify every dangerous condition in your output state isn't reasonable except for the simplest of projects.

I can identify expected safe states and exclude everything else. That's hard, but it can be done.

Re:You get what you pay for NONSENSE

[loose_cannon_gamer]

I think both the parent and grandparent have some validity. I'm a master's student in CS who has managed never to take a software engineering class before this semester (and I graduate in December). This has been an eye opening experience. Let me point out some of the well known highly advocated techniques which, as far as I can tell, most graduates and many 'out in the field' software engineering professionals don't do that would help avoid these bugs.

1. Design reviews, by peers and independents

2. Code reviews, by peers and independents

3. Regulary, organized, unit testing

4. Correctness proving

5. Documentation is about a bazillion forms

6. Defect tracking

7. Effective software process metrics measurement and improvement

8. Continuing education

9. Humility / egoless programming

This list was assembled in about a minute off the top of my head. I work in a CMM3/4 type organization, and although there are processes for these things, most people don't use them, or consider them a hassle.

So my point is, the parent is right -- creating good software, even when done by properly trained experts with great experience -- is hard. But the grandparent is right too -- doing all of the above to 'do it right' takes time and money, and many organizations, and by this I mean software process management as well as the actual engineers, don't understand the value / aren't willing to pay for or aren't willing to do all that work. And occasionally, as the article shows, the piper comes and takes his payment.

Re:Microsoft's striking absence

[AviLazar]

Remember when the LA air traffic control tower crashed

A control tower crashed? How does a control tower crash?

Bad Software

[DenmaFat]

A 1999 PC World story, Software Bugs Run Rampant, looked at consumer software bugginess, including Microsoft's.

Re:You get what you pay for NONSENSE

[enjo13]

I think more interesting is the fact that you can trace the growth of software engineering through these bugs. The most recent bug on the list (2000) was largely a case of good software being misused. Its not surprising that recent developments in software development have been largely focused not on the engineering output, but the user experience. Processes designed to get programmers thinking about not only how the system works at the code level, but how it will be used as well.

I do think the original conclusion is reasonable, although not supported. Software CAN be largely free of error, but it requires a dedication to engineering (process), skill, and expertise all at once. As the serious bugs in the list occured, software development has evolved to keep them from happening in the future. The scary thing is that a great many companies, working on critical systems, still refuse to adopt the modern practices that give them the best chance of NOT killing anybody. That fact alone makes the argument for certification quite compelling.

Coined Phrases

[AviLazar]

a club that began in 1947 when engineers found a moth in Panel F, Relay #70 of the Harvard Mark 1 system. The computer was running a test of its multiplier and adder when the engineers noticed something was wrong. The moth was trapped, removed and taped into the computer's logbook with the words: "first actual

The phrase about buggy software was coined by Rear Admiral Grace Hopper. She discovered the moth that crawled into the computer and causing the error. There's a small exhibit showing her picture and holding a moth at the Pentagon.

You can find a sample article Here

Re:Coined Phrases

[AviLazar]

Oh and I forgot, it was the Mark II system, not the Mark I system.

Yes, it does happend

[stm2]

You might have to put warnings on compliers like do not code if you have no clue what you are doing, etc but requiring a license won't ever happen

In Argentina, in some provinces, you must be "licensed" to program, or even to call yourself "computer consultant". Hard to believe? Read it here or here or here an opinion agains it (sorry, all in Spanish).

from one of the links, (my own translation):

"[professional license] assure that professional exercise is made exclusively by the people who certify corresponding academic formation as well as ethical integrity in their performance, as a minimum guarantee of the quality..."
 

Re:Microsoft's striking absence

[flyinwhitey]

Ok, so if the machine is known to have the issue, and isn't fixed, that's not MS's fault it's the admin's.

And if you disagree, take it up with the dozens of individuals who made exactly the same argument when discussing the "new" Linux worm earlier today. But post it in that thread, just to see what happens.

Re:Microsoft's striking absence

[uncqual]

But then if I walked in and saw that the machine that was about to pump tons of radiation into me was running Windows, I'd turn around and walk back out.

I would also - but it's probably pretty impractical to tell if just the operator interface is running Windows, or if the low level controller of the electromechanical sensors, switches and actuators is also running Windows. I wouldn't worry about the former, I'd worry a lot about the latter. (Well, to be honest, I probably would accept the treatments anyway - risk analysis would lead me to trust Windows more than trusting my body to eradicate the cancer on its own)

My guess is that the operator really wouldn't know either (although, she would probably assure me that it "it's very safe").

Re:You get what you pay for NONSENSE

[twiddlingbits]

You mised one..

Item 0: Requirements reviews by peers and independants. If you don't have good requirements you obviously don't know things well enough to be building them. Sure you can catch some requirements issues in 1 and 2 but the longer you wait the costlier it is to fix.

A MSCS is NOT a Software Engineering Degree, so why WOULD you take courses in SE?I'd say that CS and SE are two different professions. There are places to get a MS SE (Texas Tech comes to mind) if you are interested.

Disagree with them on some bugs

[AviLazar]

Some of the bugs they listed are not truly bugs.
Soviet Gas Pipeline...This was a desired feature working just as intended (unless they CIA didn't want to blow up the pipeline)

Buffer Overflow in Berkley - a worm is not a bug. it is a program designed to infiltrate a system and do something. While the people utilizing the program may not have intended this to happen (duh) the makers of the worm did.

A bug is an unwanted aspect of the code as implemented by the people who wrote (or edited the code) but this does not include something affected by a virus/worm. A program that crashes every six minutes for no apparant, or intended reason has a bug...a program that gets infected by a virus which causes it to crash every six minutes is not a bug. Also, a piece of code that is intentially inserted in the hopes of crashing a system is not a bug...it is a feature. It may be undesirable, but it is a feature.

Re:Disagree with them on some bugs

[praxis]

I agree with your assesment of the pipeline "bug".

The buffer overflow was a bug, a very classic one. It was not the intention of the designers that an incoming packet could inject an executable payload.

Did you read the article you linked to?

[flyinwhitey]

Do it now, then you'll understand.

"The simple root of the problem on Yorktown was that politics were played in the assigning of the contract -- there was not a discussion of engineers, it was just a very small group of people pitching for it," said an engineer close to the project, who spoke on the condition of anonymity.

In a statement issued this week on why NT was chosen over Unix, the Navy said that while Windows NT was specified in the Statement of Work as the operating system for the workstations in question, other components of a coming upgrade will primarily utilize Unix-based systems.

"They rushed this stuff on the ship, there was no real prototype, and then they tried to make things work as they went along," the source said. "I don't think that Unix or NT were ever really evaluated -- it was just somebody thinking this was good, with no knowledge."

The article is very clear. It makes the case that this was a poor job of designing and implementing the system. The software just happened to be NT.

The more I learn, the less I know

[porkThreeWays]

The more I learn, the less I know

I heard that a few years ago. The older I get, the truer it becomes. The more I learn about life in general gives me insight as to what's possible out there, and as to what I haven't accomplished!

Re:The more I learn, the less I know

[jp10558]

I think the whole thing has to do with the different spheres of knowing (IIRC - the actual title might be different):

1. Knowledge you have that you are aware of
2. Knowledge you have that you are ignorant of
3. Knowledge you are aware you are ignorant of
4. Knowledge you are are not aware you are ignorant of

So, as you move knowledge from the other areas into area 1, you tend to pull things "up" if you will. Knowledge moves from 4 to 3 as well.

2 isn't a contradiction, just that you might not be aware that some "tip" is true, or may not realize at a certain time that certain stuff you know is actually relevant to the situation at hand.

The scary part is area 4 is a default, so the less you move "up", the less you are aware that you don't know things. This is why lots of people say things like you did - the more you learn, the more you learn you don't know.

Sometimes you do.

[ichigo 2.0]

FTA: A radiation therapy device malfunctions and delivers lethal radiation doses at several medical facilities. Based upon a previous design, the Therac-25 was an "improved" therapy system that could deliver two different kinds of radiation: either a low-power electron beam (beta particles) or X-rays. The Therac-25's X-rays were generated by smashing high-power electrons into a metal target positioned between the electron gun and the patient. A second "improvement" was the replacement of the older Therac-20's electromechanical safety interlocks with software control, a decision made because software was perceived to be more reliable.

What engineers didn't know was that both the 20 and the 25 were built upon an operating system that had been kludged together by a programmer with no formal training.

Not completely correct

[elgatozorbas]

Actually the reply was: "That's the problem with randomness - you can never be sure.", which is not quite the same. And the sequence was "nine... nine... nine".

Worse: I recall this from memory

Worst: and checked if on the cartoon, pinned on a wall a few offices away.

22222222 missiles ... almost launched WWIII

[Khopesh]

My favorite bug is a computer chip in the US surveillance of Soviet Russia's missile silos. Basically, some early warning system stated that Russia had launched something like 2222222 missiles from every source they had. (I'm not sure of the actual number, but it only contained 2's.)

Some person down the line noticed that the Russians didn't have that many missiles, couldn't have launched them all with such synchronization, and that there were an awful lot of two's in the report ... actually, every digit of every number was a two. It turned out to be a fried chip somewhere, always pumping out the same bit regardless of input (I have no understanding of the technical side of the issue; maybe it hit the 32-bit limit and the int->string function reacted with 2's).

Good thing we were not too automated, and that we employed somebody smart enough to critically examine his printouts.

Disclaimer, this is a favorite tidbit of one of my professors ... I have no real source to refer to.

Re:You get what you pay for NONSENSE

[fandog]

a great many companies, working on critical systems, still refuse to adopt the modern practices that give them the best chance of NOT killing anybody

I've come in contact with a number of (U.S.) companies in the last few years that write various critical applications, (ie: that could kill someone if done wrong) and all of them have had CMMI level 3 or more, or Six Sigma or ISO processes in place. This is not because they're being benevolent, but because their own lawyers would never allow them to sell such a product without covering their own asses. Also, financially it makes more sense to have testing and reviews first to CYA than put up with the possible bad P.R./Lawsuits, etc.

The Yorktown should qualify

[Gr8Apes]

The Yorktown's failures encompass a large number of flaws and single points of failure. I guess it's more a testament to bad architecture than any one single bug.

Re:Whoops forgot to hit preview

[CastrTroy]

That works great for the kind of machines you described, and I wasn't saying good code couldn't be written, I'm saying that it isn't usually written, and won't be written in off the shelf software. The problem is, if you look at something like a mars lander, then you can't just shut it down if it gets some bad inputs. Also, even good inputs can result in the the machine not doing what it needs to do. If it has to land on mars, and some input tells it to fire the left rocket for 4 seconds, then the input may fall within proper values, but may push it way off course. There's no GPS in space, so you can't get your position very accurately, and if you go way off course, you may not have enough fuel to get back on course.

Licensing - ACM Position

[Embedded Geek]

I recently completed an "Ethics in the Information Age" class for grad school (my earlier M.S. and undergrad predated such focused classes). As part of the discussions, we talked quite a bit about the Software Engineering Code of Ethics created by the ACM and IEEE and how such a code was a precursor to making software engineering an licensed, certified profession (akin to a CPA). So I figured it'd be neat to link to ACM's page advocating licensing.

Guess what: They don't, although they appear to be hedging their bets with safety critical software.

An interesting read...

Re:You get what you pay for NONSENSE

[cylcyl]

The article shows largely a series of examples where you DID have HIGHLY PAID and HIGHLY trained professionals with plenty of experience and oversight, but nevertheless very significant bugs occurred
first bug was improper process
second was sabotage
third was INEXPERIENCE
fourth was new tech experiment, professionals involved but probably mostly grad students with varying experience
fifth - I'll grant you this one
sixth - I've worked with telcos for 10 years, chances are, it was a mod rushed out by marketing, switch bugs are, like in any other programming field, par for the course.
seventh - poor oversight and testing
eighth - university code base, generally minimal oversight.
ninth - improper testing
tenth - might qualify, but the doctors clearly went outside the allowed specs and did not check the calculations.

So, out of the 10, only one and half can be said as having "HIGHLY PAID and HIGHLY trained professionals with plenty of experience and oversight", I would say that your statement is at odds with the article, not the parent post.

Re:omg

[ichigo 2.0]

Did you RTFA? It stated that the CIA found out the Soviets were going to purchase a Canadian computer system, and decided to knowingly sabotage the equipment in such a way that it would pass initial test but would fail in actual operation. So ditch the "-might-".

Re:You get what you pay for NONSENSE

[skiflyer]

and testing... don't forget testing... one was a case of a perfectly cromulent program which triggered a bug in the underlying OS... another was the case of a passable program when used properly, but which allowed users to "hack the system" to get a desired result, which then revealed an unexpected bug.

Better Languages

[RAMMS EIN]

This seems like a good thread to plug my essay Better Languages for Better Software (again). In a nutshell: many (probably the vast majority) of bugs that are found in software nowadays can be entirely eliminated by using safer programming languages. As an added bonus, these languages are often more concise than languages in popular use today, which means more productivity and/or time to fix bugs.

What about ActiveX?

[argent]

Or does a that's inherently insecure (that is, it's not actually possible to fix the underlying security flaw without changing the design) not count as a bug?

The problem is more fundamental than competence

[MOBE2001]

Consider how much software is written by people with five years or less of professional experience, on short schedules, with no time allocated for continuing education. If software projects weren't always rush jobs, and on relative shoestring budgets, the quality would be better.

The software reliability crisis has very little to do with greed, engineering incompetence or the lack of big budgets, in my opinion. There is something fundamentally wrong with the way we program our computers, something that no amount of quality control measures can ever cure.

The reason that software is bad has to do with a custom that is as old as the computer: the practice of using the algorithm as the basis for software construction. Switch to a synchronous, signal-based approach and the problem will disappear. Complex algorithmic software is essentially unreliable, something that Fred Brooks has shown in his now famous "No Silver Bullet" paper back in 1987. For an alternative approach to software construction see this article in The Silver Bullet News.

Regardless of what has been said in the past, the problem can be solved. Otherwise, we are in big trouble, very big trouble.

Radiaton - How High is Too High?

[geomon]

From the following website:

Blood-forming organ (Bone marrow) syndrome (>100 rad) is characterized by damage to cells that divide at the most rapid pace (such as bone marrow, the spleen and lymphatic tissue). Symptoms include internal bleeding, fatigue, bacterial infections, and fever.

Gastrointestinal tract syndrome (>1000 rad) is characterized by damage to cells that divide less rapidly (such as the linings of the stomach and intestines). Symptoms include nausea, vomiting, diarrhea, dehydration, electrolytic imbalance, loss of digestion ability, bleeding ulcers, and the symptoms of blood-forming organ syndrome.

Central nervous system syndrome (>5000 rad) is characterized by damage to cells that do not reproduce such as nerve cells. Symptoms include loss of coordination, confusion, coma, convulsions, shock, and the symptoms of the blood forming organ and gastrointestinal tract syndromes. Scientists now have evidence that death under these conditions is not caused by actual radiation damage to the nervous system, but rather from complications caused by internal bleeding, and fluid and pressure build-up on the brain

Other effects from an acute dose include:

            200 to 300 rad to the skin can result in the reddening of the skin (erythema), similar to a mild sunburn and may result in hair loss due to damage to hair follicles.

            125 to 200 rad to the ovaries can result in prolonged or permanent suppression of menstruation in about fifty percent (50%) of women.

            600 rad to the ovaries or testicles can result in permanent sterilization.

            50 rad to the thyroid gland can result in benign (non cancerous) tumors.

As a group, the effects caused by acute doses are called deterministic. Broadly speaking, this means that severity of the effect is determined by the amount of dose received. Deterministic effects usually have some threshold level - below which, the effect will probably not occur, but above which the effect is expected. When the dose is above the threshold, the severity of the effect increases as the dose increases.

Re:Whoops forgot to hit preview

[RobinH]

The problem is, if you look at something like a mars lander, then you can't just shut it down if it gets some bad inputs.

True, it's just that in my line of work, off is usually the safe state, but what should be done is to go to some kind of safe state, whatever that may be. Sometimes you revert to a manual operation, for instance.

Also, even good inputs can result in the the machine not doing what it needs to do.

Which is why you need to also hire a mechanical and an electrical engineer to design those aspects so that the mechanical and electrical systems fail in a safe and detectable way.

For instance, it used to be that stoplights were designed with a physical disk inside that rotated creating the "program" of the different lights. You also had interlocked electrical circuits so that both greens could never come on at the same time. These are mechanical and electrical ways to make the system fail to a safe condition. I have recently been at an intersection where I saw the traffic lights had green both ways (during a storm). This is because some vendor is selling a traffic light system on the market that is completely software based, and they hired a bargain basement programmer and/or engineer to design it, and we should find them and shoot them for their incompetence, but I doubt that will happen.

Re:Whoops forgot to hit preview

[CastrTroy]

The problem is, there isn't always a safe state. In many cases there is, but not in all cases. What's the safe state for the mars lander that's drifting off course. Manual override is impossible, because signals take 20 minutes to get there, and by then it may be too late. It may not even have line of site at the time, and therefore communication is impossible.

Patriot

[uxo]

No question, the bugs in this top ten list do not represent history's worst software bugs, but rather some of the most newsworthy (Google-able). I tend to think of Wired as being to technology what Omni magazine was to hard science.

The article mentions the radiation therapy device killed five people. I was only able to find three fighter shootdowns blamed on the Patriot. What others are there?

Re:Patriot

[k1773re7f]

No question, the bugs in this top ten list do not represent history's worst software bugs, but rather some of the most newsworthy (Google-able). I tend to think of Wired as being to technology what Omni magazine was to hard science.

What? OMNI was a "hard science" magazine? Oooooh, I see what you mean.

Why isn't Patriot missle mentioned? Here's Why:

[dan_sdot]

Both radiation bugs in both cases have killed less people then the shiteware used in Patriot missile system

The patriot missle was never designed to intercept other missles. It was originally designed as a fast-deployment anti-aircraft weapon. When Saddam started launching Scuds at the Kurds, the US wanted to invest some money REALLY QUICKLY in getting a missle system that could stop some of these scuds. The quickest way to do this was to contract Raytheon to quicky modify their anti-aircraft missle system to be much more precise and hit other missles.

In other words, the Patriot missle system used during the 1st gulf war was just a quick kludge, and considering, it actually worked pretty well.

BTW, by saying the the Patriot missle system killed people are you implying that its failure to shoot down scuds is guilty of murder?

Re:gets()

[mfrank]

All you really have to do is force everyone at the company to use an include file with this:

#define gets() DONT_USE_GETS_YOU_MORON()

Re:Oh.. a USA fanboy..

[Kohath]

USA = Good Guys.
All others = Bad guys

More practically:

USA = our side
All opponents = enemy

Preferred winner: our side (USA)
Preferred loser: enemy

Actually

[geekoid]

One of the systems mentioned was kobbled together by someone with NO prior programming experience.

The other 9 didn't mention the experience of the programmers.

Other examples did show a lack of basic interface skills.

I would wager nearly all these issue would have been caught if parallel testing had occured. Since so few people even know what parallel testing, much less how to apply it, it's no surprise the industry is in such a sorry state.

They deffinatly should count it, becasue it

[geekoid]

highlights the number one reason bugs get to the end user, Improper testing.

Except in my case. In my case it's do to Secret opratives sneaking in and foikling my code. Also, they mess up my spelling.

Re:Microsoft's striking absence

[IdleTime]

Tell that to all my co-workers who had their machine BSOD on boot thanks to me adding "type c:\bsod.txt" to the startup commands.

Just because a bug is not easily exploitable doesn't mean it is not a serious bug.

Re:My prediction

[lidden]

Where the heck did you get this from? I did some googling and the 49 day problems seems to have been with Windows.

Silly Soviets, it's Lin-ux, not Line-X

[Subrafta]

the Soviet authorities in 1970 set up a new KGB section, known as Directorate T, to plumb Western research and development for badly needed technology. Directorate T's operating arm to steal the technology was known as Line X.

From the linked article: http://www.msnbc.msn.com/id/4394002

Re:Why isn't Patriot missle mentioned? Here's Why:

[arivanov]

No.

It shot down at least several aircraft due to friendly fire.

Further to that at least several of the blasts in Ryadh and other places around the gulf in Gulf War 1 did not look anything like Scud blasts. Smaller, high explosive blasts, some of them right above the ground instead of after hitting it. I remember even CNN voicing the suspicion that it was not a Scud blast, but the patriot selfdestructing (and this part disappearing immediately from all repeats of the coverage).

If I recall correctly, at least one of these strange blasts had casualties.

So no, I am not blaming Patriot for failing to shoot down R1s. I am blaming it for blowing up civilian ground targets while trying to do so. Along with a few friendly aircraft for good measure.

Re:You get what you pay for NONSENSE

[megarich]

...we can expect critical flaws to pop up from time to time, even when highly trained, experienced, and monitored programmers are involved.

Exactly sir. You are right. Humans are fallible by nature so even the best and brightest minds will inevitably make mistakes. Couple that with the fact it's not easy either to debug or proofread thousands to millions of line of code, its almost like finding a needle in a haystack, and unpredictable things can and will occur.

Re:Microsoft's striking absence

[Bender Unit 22]

I'd say it was rather the decision to use Windows as OS for a system that important that was the error here.

Re:Whoops forgot to hit preview

[RobinH]

I really think the default safe state for the mars lander while safely on the ground on Mars is "do nothing and wait for program download". The safe state while re-entering is either "do nothing and crash" or "take a stab at when to fire the retro-rockets and probably crash". Either way, it doesn't matter from a safety perspective - there's nobody to kill on Mars (as far as we know).

This applies more to medical equipment and big machinery back here on Earth.

Another great AT&T bug

[magictongue]

This is not a "single" bug but rather a train wreck. A botched Siebel CRM upgrade cost AT&T thousands of new customers and an estimated $100 million in lost revenue. This eventually led to the sale of AT&T Cellular to Cingular at a less than optimal price. The article is great in explaining how management and big "personalities" lead to these kinds of disasters.
A full story of the bug:
http://www.cio.com/archive/041504/wireless.html

Re:You get what you pay for NONSENSE

[Skippy_kangaroo]

In agreeing with you I will also argue that you typically require HIGHLY PAID and HIGHLY trained professionals to get these really nasty bugs.

If you have someone who is an amateur they are likely to make obvious mistakes which will cause obvious (but non-lethal) problems in the code and therefor - it won't pass the most basic of quality testing.

On the other hand, with highly paid professionals, they know how to write code that passes quality testing protocols. So, their work will more easily be put into production and out in the real world where it has a chance to seriously harm users when the subtle bug is discovered.

Re:Call it what it is - FUCK UP

[Beardo the Bearded]

When you have an owner, a CTO, a CEO, end users, product maintenance, new R&D, etc. all asking for your attention and you don't have time to relax and concentrate, errors fall through the cracks. You'll learn this.

Yes, it's a fuck-up. That's exactly what it is. I personally fucked up a line - ONE FUCKING LINE - of code that caused a worldwide recall on our products. (I used = instead of |= ) It's unlikely, but there's a chance that someone's going to die if the unit doesn't get refitted before it gets used.

It was missed in my tests, it was missed in the pre-production tests, it was missed in the post-production tests, and only one repeat ONE customer told me that it was wrong, MONTHS after other customers told me that they LOVED the new firmware version.

Some employers won't let you say "fuck", let alone "fuck-up". Right now, there's a guy getting a red flag at DOD / DND for having "Fuck" show up too many times on a web page. The moniker "bug" was coined over 100 years ago, when "damn" was offensive. If you want to use your own nomenclature, go ahead. Just don't be surprised when someone asks you want the fuck you're talking about.

Re:Why isn't Patriot missle mentioned? Here's Why:

[tafinucane]

The "strange blasts" seem to be an invention of your memory, or poor reporting at the time.
Do you have a source you can site? I've looked through a few online sources critical of the patriot's poor performance in Gulf War I, and have found no mention of any that destructed near the ground or civilian deaths. For example, here's a House committee report referred to by many other sources who decry the patriots' performance.

In Gulf War II, they've taken out two coalition planes, though. Maybe you were thinking of that?

False. Hopper did *not* coin the phrase.

[porkchop_d_clown]

While she has the honor of finding the first actual bug in a computer (the moth), the term "bug" had been in use for at least 70 years prior. For example, Edison used it in letters to associates in 1878. Wikipedia is your friend.

and yet another radiation machine problem

[GunFodder]

The Therac-25 error is quite famous. That's why it blows my mind that there is another lethal radiation therapy software error listed. You'd think that people would have learned from the first mistake.

Re:Microsoft's striking absence

[kruithof]

OTOH today I saw some medical machines (probably for blood-analysis and similar things), which were running embedded windows.
It definitely did me want to run away crying.

Andries

understates the pentium floating point bug

[planetfinder]

The description of the pentium floating point bug
reads like a damage control press release from intel.
In spite of what the article says this bug could result
in enormous errors in situations were cancellation error
came into play.

what about the intel 286 bug

[planetfinder]

that effectively left PC users with only 640K of memory
for ever and ever.

Re:You get what you pay for NONSENSE

[rtb61]

They just need to accept there a two professions in the software industry, coders and proof readers. Proof reading code and making corrections and fowarding changes required is a seperate skill set to the creative writing of compact efficient code.

WP not-5.1 for not-DOS

[texaport]

1986 Word Perfect 1.0 for Mac
1988 Word Perfect 1.0 for Amiga
1990 Word Perfect 1.0 for AtariST

Gravely injured one -- fatal for the others.

Re:Microsoft's striking absence

[varmittang]

Well, its a bug that is in the OS that MS profided to run this system. Its not the admins fault, and I'm sure the admins probably did everything to get rid of it. But its a known bug in the OS. So well known that a maintenance procedure has been implemented to keep the bug from showing itself by rebooting the comptuer system every 30 days. This one time they didn't reboot it after 30 days and it got to day 49, so the system crashed. Now why does this OS problem get blamed on the admin? There is no OS out there that should need to be rebooted before reaching a set date on a very important system such as this? I'm sorry, this is not a bad setup by and admin like the Linux worm would need to take advantage of a bad setup.

A good carpenter never blames his tools

[Mingco]

But in the case of programming bugs, I believe the cause is the programming language. Currently, too much information is required by the programmer in order to get a program to run properly.

If a program is the sum of all information required to get it to run as intended, one part of it is the computer part--- memory, source code, data assets, other deterministic inputs. But the other part is the programmer or group of programmers who have a collective knowledge that is required to get the program to run correctly.

For example, if I write an API that has three functions A(), B(), and C(), the computer has the same information as if I write an API that has the three functions A(), Init_A(), Cleanup_A(). But the programmer has *extra* information that the computer does not know, namely that there is a relationship and interdependency between the three functions.

Furthermore, as demonstrated above, this relationship is often conveyed by ad-hoc naming conventions that are hardly standardized between two programmers at the same company, much less at different companies.

There are thousands, possibly millions of pieces of implicit information like this in the meat-memory of programmers. We tend to call this "programming experience". That is, each new program learns through trial and error or by cut and paste that functions need to look like this:

Init_A();
A();
Cleanup_A();

Rather that this:
A();
Cleanup_A();
Init_A();

But due to event-driven programming, we are sometimes uncertain what order each function will be called. So, we place ASSERTS and conditionals to handle the out-of-order cases.

What this all leads to is bugs because the memory state and mixed conventions of all of the various programmers is always in some uninitialized, unknown state. If a chain is only as strong as its weakest link, then a program is only as strong as one of its programmers on its worse day--- and we tend to stress our programmers a lot with long hours and tight schedules.

The undetermined state of the collective minds of all of the programmers also explains why there is a mythical man-month. If you regard the program as not just the source and its assets, but include its programmers as well, you can easily see where your systems will fail in how arbitrarily stringently you treat your source code, but how lax you treat documentation and programming conventions.

The solution, which is easier to say than to implement, is to take as much implicit information as possible away from the programmer and put it into the program. Certainly, as memory capacity grows, we shouldn't be using the same programming languages that we had when memory capacity was 1/1000th of what it is now.

Once this information is included in the program, Init_A(), A(), Cleanup_A() don't need to be named as such. Their relationship can be visualized by the programmer through a documentation tool that shows the relationship of each function to each other function that has a relationship to it (sort of like a LinkedIn network, but for functions).

I don't know if all of the implicit information in a programmer's head can be transcribed into explicit information for the computer to use. If, during the programming process, all of this information can be described efficiently and simply, then functions themselves may attempt to initialize themselves by searching their own relationships for other functions that satisfy their parameters.

Then, we can write something like "draw_pixel(10, 12, YELLOW);" and expect it to work properly as a stand alone line because the function itself can figure out how to call all of its preconditions.

This is perhaps something serious computer scientists can answer. I don't know how much implicit knowledge can be transferred from the programmer's brain and into an explicit structured code in the computer's memory and source. Certainly some, unlikely all, but perhaps most. The more the better.

At this point, if some advanced alien society were to look at the primitive state of our information age advances, they would laugh at us, ridicule us, and perhaps consider us "cute" in the same way as when we watch monkeys poking a stick into a hollow log for grubs.

Y2K?

[fbg111]

Where's the Y2K bug? Just because we fixed it before it manifested doesn't mean it wasn't a whopper. Tests done on various equipment from oil & gas pipelines to telephone switching equipment showed the potential for serious consequences. It should definitely be on the list.

The story so far...

[Humorless Coward.]

At this point, I'd just like to add that,
aside from the bickering about whose got the
biggest example of stupidity...

We also have allowed the example of humans
used as live error checkers in a mission-critical
environment (the early-warning system controllers
in the nuke story) to be presented.


I find it humorous that, in this age, we're often
presented with the Orwellian as commonplace,
and perhaps in five years, we'll actually ignore
several instances in the media of politicians
asking the public, "What are you going to believe?
what you see, or what we tell you is the truth?"



Oh, and thank God(tm) there's no peer review at Wired.
I mean, how else would it be the world's most-widely-read
computer-savant satire magazine? If those guys actually
knew about what they were talking, I'd be worried ;)

Re:Soviet gas pipeline explosion is likely a myth.

[Tablizer]

I've heard roughly the same thing. There seems to be disagreements about whether it was caused by the CIA planted bug or operator error. One story has it that the operators cranked up the pressure to push gas through because hard-to-locate leaks were draining needed pressure. Rather than investigate and fix the probable leaks, the operators simply cranked up the pressure to compensate because they were being pressured (pun) to deliver gas.

Re:Microsoft's striking absence

[flyinwhitey]

I love when people post, and try to seem reasonable and intelligent, but then do things like this.

"Now why does this OS problem get blamed on the admin?"

Well, let's see... WAIT!!! You answered your own question!

"its a known bug in the OS. So well known that a maintenance procedure has been implemented to keep the bug from showing itself by rebooting the comptuer system every 30 days."

That's why.

God you made that easy.

Re:Whoops forgot to hit preview

[Craster]

Back to what you were saying, if you have a system that could cause damage or whatever, then you start by writing your output routines, and you create rules to govern the machine (i.e. outputs A and B can't come on at the same time, or output C can't exceed this value). Then you write another module that monitors the inputs AND outputs looking for fault conditions that shuts down the machine if you do anything dangerous. Only this part of the code needs to be signed off by an engineer. Typically it's simple code, and easy to prove correct, with peer review. Then you write other modules that essentially make requests through the safety checks to do anything. You don't have to review the complex other code so much, because your output stage should catch any mistakes.

Unfortunately, what's missing there is the process for validating your decision-making criteria. You wrote the rules ("Output C cannot exceed this value"), and you coded for these rules, and you haven't mentioned anyone signing off or quality checking these criteria. Requirements definition and validation is an utterly vital part of any software project.

Re:You get what you pay for NONSENSE

[mumblestheclown]

You probably think of yourself as a person capable of logic, right?

Then how come you make such a blatant logical error?

His argument was that highly trained / experience professionals would lead to less likelihood of errors happening or something to that extent.

My point was that the list counter-evidences this theory, as in that case highly experieced programmers also created catastrophic mistakes - even if we accept your dodgy ("poor oversight and testing", according to you, has nothing to do with the skill/experience of those involved) count of 1 or 2 out of ten, my basic point still stands, since for my point to be valid, i dont have to show that all ten were caused by experienced software people, but rather simply that some were. if you showed me a list of the 100 worst software mistakes of all time and it turns out that 99 were caused by junior programmers, then you might have a point. but as is, you don't.

I am sure you are a smart person, but consider taking a course in basic logic. Try http://www.philosophypages.com/lg/, especially the section marked "Quantification Theory."

Re:Whoops forgot to hit preview

[DrRhinehart]

Shutting a system down might be even more catastrophic. E.g. fly-by-wire software.

About the ariane 5 bug

[thedude007]

according to the official report, Ariane 5 bug was an overflow during a conversion caused by a too large lateral speed in ariane 5 cinematics. Ultimatly, this bug was due to the lack of 'requirement tracability' between ariane 5 and ariane 4. Another ultimate cause was the missing of proper testing simulation software.

Re:Whoops forgot to hit preview

[RobinH]

See my other replies in this thread. Switching to a "manual mode" may be an alternative.

Re:You get what you pay for NONSENSE

[cylcyl]

I guess this might turn into flamefest, but whatever....
Then how come you make such a blatant logical error?

I disagree on making a logical mistake. I was responding to (and quoted)

The article shows largely a series of examples where you DID have HIGHLY PAID and HIGHLY trained professionals with plenty of experience and oversight, but nevertheless very significant bugs occurred

The emphasis in bold is mine, but the words were yours. One or two of TEN does NOT make "largely", which implies a majority. Therefore at least five should fall into your rather specific categorization. This was not the case.

Perhaps you meant to say something else in the original post. But the words you used was inaccurate. Perhaps you mean that "HIGHLY PAID and HIGHLY trained professionals with plenty of experience and oversight" CAN result in serious bugs. Tho this was NOT the theme of the article either, but a perfectly valid comment.

Bug!

[sjames]

Two different ways to input the same shape resulted in visually indistinguishable outputs, but one of them would cause a fatal mis-calculation. If not a b ug, at least a serious design flaw in the user interface.

Re:Whoops forgot to hit preview

[sjames]

There are software engineers in Canada now. They can legally sign off on a software project. The problem is, is that you don't want to have every one of your programmers be licensed software engineers, all signing off on their own code.

It seems to me that what we need is a well defined set of conditions that require a project to be signed off on. All others would not have the requirement.

it's reasonable that software that could be a danger to fife and limb would require signoff. For other software, the expense just isn't worth it.

Even in life critical applications, there are design methods that could restrict the signoff requirement to only the critical modules. For example, design a sort of operating shell that doesn't allow unsafe operational conditions. That code is developed in the most rigorous (and therefor expensive) manner and gets a sign-off. Code that runs inside it is allowed to be less strictly developed and is meant to provide non-critical features and perhaps come up with more efficient operation. As long as the shell is sure to countermand unsafe operation and carry out critical functions by itself, that is fine.