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

41–50 of 58 posts

Re: Infamous Software Bugs

#41

Post by joezydeco »

anc84 wrote: post #34
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.

This is one of my favorite nuggets in the digest, it's from November 1988. It's Clifford Stoll writing at 3:45 am about his discovery of the Morris Worm. The Morris Worm was literally the first internet virus captured in the wild.

http://catless.ncl.ac.uk/Risks/7.69.html#subj1

Warning - this one email will lead you to multiple rabbit holes (Stoll, The Cuckoo's Egg, Robert Morris, etc).

https://en.wikipedia.org/wiki/Clifford_Stoll

https://en.wikipedia.org/wiki/Morris_worm

Re: Infamous Software Bugs

#42

Post by forgottenpass »

dkbrk wrote: post #3
Piskvorrr wrote: post #2

Well...I'd say that https://en.wikipedia.org/wiki/Therac-25 has become much more notorious than the Arianne launch; but it's also a UX fault, not a straight-out software error.

Yep, also I would say that Heartbleed is definitely deserving of a place.

Many more-interesting bugs than Heartbleed have existed. If Heartbleed is notable, it is largely as a study in the success of branding and marketing campaigns for security bugs. Or being the straw to break the camel's back on openssl cleanup efforts.

Re: Infamous Software Bugs

#43

Post by Zenst »

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.

Well as most dosage is focused, you just increase that area to include the sensor. WIth such focused exposures you have shielding for the patient for the parts you do not wish to radiate and with that just place the sensor upon that and not impacting dosage upon patient at all.

That's how I'd do it from my understanding of the usage practices today.

Re: Infamous Software Bugs

#44

Post by Albright »

thedaydreamer wrote: post #38

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,…

"They" didn't destroy it; it was destroyed by the Martian atmosphere.

…At least, that's the official story. I recall there being a lot of conspiracy theory-like buzz at the time from people who also couldn't believe NASA could make such a stupid error like that. It does make you wonder.

Re: Infamous Software Bugs

#47

Post by randlet »

Zenst wrote: post #43
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.

Well as most dosage is focused, you just increase that area to include the sensor. WIth such focused exposures you have shielding for the patient for the parts you do not wish to radiate and with that just place the sensor upon that and not impacting dosage upon patient at all. That's how I'd do it from my understanding of the usage practices today.

Shielding a patient like this isn't really feasible. The half-value-layer of lead in a 6MegaVolt clinical beam is 17mm [1]. That is, even with nearly an inch of lead shielding in place you'd still be delivering a large dose of radiation to healthy tissue.

[1] https://quizlet.com/4622164/hvl-layers-flash-cards/

Re: Infamous Software Bugs

#48

Post by randlet »

joezydeco wrote: post #41
anc84 wrote: post #34

Earlier quoted context omitted.

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

This is one of my favorite nuggets in the digest, it's from November 1988. It's Clifford Stoll writing at 3:45 am about his discovery of the Morris Worm. The Morris Worm was literally the first internet virus captured in the wild. http://catless.ncl.ac.uk/Risks/7.69.html#subj1 Warning - this one email will lead you to multiple rabbit holes (Stoll, The Cuckoo's Egg , Robert Morris, etc). https://en.wikipedia.org/wiki/…

The Cuckoo's Egg is a really fun read!

Re: Infamous Software Bugs

#49

Post by icegreentea »

thedaydreamer wrote: post #38

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,…

So I went ahead and read the MCO Mishap Phase 1 report (linked here: http://www.icics.ubc.ca/~cics525/handouts/handout_MCO_report...) and I'm having a hard time finding something that backs up the wiki summary of two navigators raising concerns and having them dismissed.

The report does go ahead and state all sorts of organizational (and otherwise 'soft' issues) that contributed to the end failure.

The report notes that earlier deviations between measured and modeled results were noted, however, they were hampered by limited data (in the sense that they couldn't measure what they wanted). It is implied (though not stated) in the report that in the absence of appropriate data, the operations navigation team attempted to contain/mitigate the deviations instead of 'solving' it.

The report also notes substantial organizational issues. Different navigation teams were used in development and operations, and there were insufficient knowledge transfer during hand-off that hampered the operations navigation team ability to notice these issues. Communications between the main operations team and the ops nav team were not effective. They were apparently spatially separate teams. In addition, model-measurement conflicts which were brought up were solved via e-mail instead of over formal processes. The report suggests that systemic use of formal processes may have allowed teams to uncover the problem earlier in time.

And of course, the report also states that insufficient verification/validation of the supplied software was not completed. The entire section on verification/validation (MCO Contributing Cause No. 8) is just a giant cringe fest.

The implication is that the MCO project was just... not run well.

Post reply on HN