Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Infamous Software Bugs

bbvaopenmind.com

Post reply on HN
Print view View original

31–40 of 58 posts

Re: Infamous Software Bugs

#31

Post by therapix »

cafard wrote: post #21

Given that the performance of the Patriot missile was much over-hyped in the first Gulf war, should #3 be on there? Do we know that the missile would have intercepted the Scud if launched?

The Israeli army wrote a report about the error and a patch was uploaded into the US systems the day after the attack. Bad timing I guess. After day, the Patriots never missed their target and didn't need to be rebooted.

"e. Two weeks before the incident, Army officials received Israeli data indicating some loss in accuracy after the system had been running for 8 consecutive hours. Consequently, Army officials modified the software to improve the system's accuracy. However, the modified software did not reach Dhahran until February 26, 1991--the day after the Scud incident."

Re: Infamous Software Bugs

#32

Post by OopsCriticality »

danburgo wrote: post #30

Great article, but IMO it missed one of the most important bugs of all, the one with the Hubble Telescope and its mirror

How does that qualify as a software bug? Perkin-Elmer's custom null corrector was misaligned so the mirror was figured into the wrong shape. Edit: if anything, it was an organizational failure—PE chose to ignore other measurements that showed the mirror was the wrong shape.

http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/1991000...

Re: Infamous Software Bugs

#33

Post by randlet »

Someone1234 wrote: post #29
Zenst wrote: post #7

Earlier quoted context omitted.

Agree and also would of thought they would have a sensor on patient that measures dosage independently of the system giving the dosage. But from what I can tell - they do not.

How would you sense that without risking either deflecting the beam (which could cause harm/cancers in other body parts) or reducing the beam's intensity (which could cause treatment to be less effective). This is one of those ideas that sounds a lot easier than it likely is.

Putting things in the way of the beam to measure dose is actually quite common.

You can do real time dose monitoring using diodes (see [1]). The diodes are quite small and don't generate huge amounts of scatter.

It is quite common to use TLD's[2] to monitor patient dose which is then analyzed offline to give dose estimates after the fact.

edit: that said, I don't think anybody was doing real-time in-vivo measurements during the era of the Therac incident.

[1] https://www.aapm.org/pubs/reports/RPT_87.pdf

[2] TLD=thermoluminescent dosimeter, little hunks of metal whose electrons get stuck in an excited state when exposed to radiation, you then heat them up and measure the light they give off as they relax back to ground state. The amount of light they give off can then be correlated with the dose the patient received.

Re: Infamous Software Bugs

#34

Post by anc84 »

joezydeco wrote: post #20

Every software engineer should be aware of the RISKS digest (aka USENET's comp.risks). The mailing list and digest just celebrated it's 30th birthday in August. There's an incredible wealth of history here regarding bugs, related issues, and the overall risks of our dependency on computers in society. RISKS broke most of the major stories of the day including the Morris Worm, the AT&T Long Distance collapse, the Mars…

I had never heard of that, thank you so much for many cozy winter reading sessions.

Re: Infamous Software Bugs

#35

Post by rprospero »

Someone1234 wrote: post #29
Zenst wrote: post #7

Earlier quoted context omitted.

Agree and also would of thought they would have a sensor on patient that measures dosage independently of the system giving the dosage. But from what I can tell - they do not.

How would you sense that without risking either deflecting the beam (which could cause harm/cancers in other body parts) or reducing the beam's intensity (which could cause treatment to be less effective). This is one of those ideas that sounds a lot easier than it likely is.

My assumption is that you'd put the sensor behind the patient. After the beam has been through the body, you don't care if it's deflected or reduced.

Obviously, it's too late at that point to prevent the beam from hitting the patient, but you'll know that something went wrong and can lock the system until the problem is found.

Re: Infamous Software Bugs

#36

Post by randlet »

rprospero wrote: post #35
Someone1234 wrote: post #29

Earlier quoted context omitted.

How would you sense that without risking either deflecting the beam (which could cause harm/cancers in other body parts) or reducing the beam's intensity (which could cause treatment to be less effective). This is one of those ideas that sounds a lot easier than it likely is.

My assumption is that you'd put the sensor behind the patient. After the beam has been through the body, you don't care if it's deflected or reduced. Obviously, it's too late at that point to prevent the beam from hitting the patient, but you'll know that something went wrong and can lock the system until the problem is found.

Many (most?) modern linear accelerators have imaging panels behind the beam path (see image [1]) which could be used for dose monitoring although they are primarily used for imaging purposes. I'm not sure whether any of these are currently used for dose monitoring.

[1] http://tommytoy.typepad.com/.a/6a0133f3a4072c970b0147e2ed7f8...

Re: Infamous Software Bugs

#38

Post by thedaydreamer »

Wait a second, it says they had to destroy mass climate orbiter because the development and underlying software used different metric system ?

It's bit hard to digest. ( Although just checked wikipedia, it also says so ) How can a high performance organisation like NASA could make such a simple yet fatal mistake ?

Wikipedia page of Mars Climate Orbiter says that NASA was informed about this discrepancy by two people, but the "concerns" were dismissed.

What am I getting wrong here ? These are not the "concerns" you simply dismiss in a space mission. Could there be another story to this ?

Re: Infamous Software Bugs

#40

Post by VLM »

chapium wrote: post #17
AshFurrow wrote: post #14

You yanks and your aversion to the metric system...

The scapegoat for what was clearly an organizational failure. Why was the system using multiple units of measure. Did it pass navigation tests prior to launch? Was the test flawed?

I think OP was making a subtle joke about titling it "5 bugs" but providing metric 5 aka 6 in the article to cause a buffer overflow in the article itself. Which the buffer overflow in the article the 7th bug. Personally I think a recursion fail would have made a funny additional article bug, but buffer overflows are funny in their own way too. Or a picket fence / off by one error would have been funny like iterating from 1-5 to output the bug list where the bugs are enumerated beginning at zero... so why didn't we see bug 0 and the crash at bug 5 would have been pretty funny.

The story is normie clickbait anyway, and most of the bugs aren't mismatches between the source code and the (possibly non-existent) unit testing infrastructure, they're just cultural examples of blaming the lowest social status individual involved, that usually being a programmer. There was a programmer involved, someone in management screwed up and doesn't feel like taking the blame, therefore its the programmer's fault. In the olden days they'd just have blamed the closest (insert ethnic group here) or (insert religious group here), nothing really to be proud of.

Post reply on HN