Slashdot Mirror
Debug your Code, or Else!
Trevor Lovett writes "I ran across a collection of famous software bugs that have caused large scale disasters including the explosion of the Ariane 5 rocket due to integer overflow and the misfiring of a US Patriot missile that caused 28 deaths because of accumulated floating point error. "
Remember that time when that kid dialed into NORAD and used that security exploit to get into the Thermo-nuclear war simulator and everyone thought it was real until he and the inventor were able to trick the computer into playing Tic-Tac-Toe? I see a LOT of bugs in the software there but no one ever seems to care about that...
The ultimate network admin tool needs HELP!
2) 2000 - Poorly coded garbage collection causes Word 97 to crash, lose last 2 hours of research paper. Class was in 30 minutes, paper was late. I lost my scholarship.
3) 2002 - IE Crashes while writing AWESOME first post for /., My karma never recovered.
What, me worry?
This is quite amusing, but a software bug in my field can result in patients lives being lost. It's kind of scary sometimes :)
Later,
Phil
Lets see I was on 15 out of the 44 projects there. Not bad, eh?
Currently, I'm working on a system to contain virus outbreaks so scientists can study virii within major cities...
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
debugging
(fp)
The surprise isn't how many situations have cropped up because of software bugs, but rather how few. If you think of all the things that code is written for, and yet there hasn't been any major 'disaster'. Yes, the deaths and accidents are tragic, but on the grander scale of things, it's amazing that nothing truly catastrophic has happened.
sig--we don't need no goddamn sig
the scud caused the deaths of the soldiers. the patriot just failed to stop it. fool.
but it worked on my computer...
"Facts are meaningless. You could use facts to prove anything that's even remotely true." - Homer Simpson
I'd take issue with the inclusion of the London Millennium Bridge; that wasn't so much a failure of software, but a flawed model, that failed to take into account the effects of swaying pedestrians. After it was rectified, there were new data - never used in any bridge model - incorporated into such models so that it won't happen again. That's science; not a bug.
Yeah, I work on projects for some big companies, and they expect bugs. It's a given fact when you get software, you get bugs, period. Your reputation depends on how you deal with them, and how severe they are. Do any of you get surprised about a bug in something that you get?
I seem to remember PowerBook 3500C was known to catch fire. Not a bug, per se, but it could have killed somebody. I know I almost threw mine out the Window and that could have caused serious damage.
Anyone got a translation? Altavista choked on it.
The Therac-25. Now THAT was a scary machine. I'm willing to put my life in the hands a doctor, but a bunch of underpaid, undertrained programmers who don't understand how critical a bug can be? No thanks!
It really amazing how many software project managers that don't fully understand what regression testing is all about.
Software engineers simply cannot be trusted to do more than small unit level testing! We get into a pattern of behavior, we know what to expect, and simply do not stress test the system.
Thats why I like hiring sales people and 2-year olds to test my code at the unit/integration level.
Old age and treachery almost always overcome youth and skill.
Software Horror Stories linked from the post's link
In which case Microsmurf should be on the Most Wanted list right up there with the al-Qaeda ...
...
It's only FAIR
-
--- Will in Seattle - What are you doing to fight the War?
the BSOD. I still have nightmares.
"I don't think it's selfish, to eat defenseless shellfish." -NOFX
A lot of these are not confirmed software problems and there is very, very little in the way of any kind of proof or explanation on the sites linked.
The shooting down of the Iranian airliner being attributed to a software problem is supported by nothing more than some guy's claim. (I've spent time in the Combat Control Center of a carrier and I think this is bull)
While looking for the info. on that, I read the airbus crashing at an airshow stuff - no proof just allegations by the person who lost his job because of the incident.
All ready looking at the other posts I can see this is the case for many other 'bugs'. Interesting but not all too accurate.
.
It's hard to believe that's how Micronians are made. Why don't we see it right now by having you both kiss one another?
I seem to remember PowerBook 3500C was known to catch fire. Not a bug, per se, but it could have killed somebody. I know I almost threw mine out the Window and that could have caused serious damage.
I know a lot of people who threw out Windows when they got their Macs...
Michael-
You catch enchiladas by picking them up behind the head and holding them underwater until they don't kick anymore -VeGas
The pentium bug is certainly famous because every idiot and its brother think it is rare for a CPU to be buggy. The second condition in the list is "caused a large scale disaster". This condition is, sadly, also met. It caused a large scale public relations disaster for Intel because once again said idiots thought that a CPU bug is rare.
Wrong Starting Estimate of Uranus mass
But I thought Uranus is a hole...
(Sorry, I just had to)
Developers: We can use your help.
I wrote the algorithm that scheduled the dialins. It used a pseudo-random approach during the day, weighted by outstanding traffic.
But at night, there was period during which we had to unload all messages before the next day's processing. During this time, the pseudo-random algorithm was replaced by a deterministic one that assigned computers time slots.
The computers also had auto-rety in the case of failure, so each call could result in several if it were blocked.
Unfortunately, during coding I had put in the number of modems answering phones at 20 (as an arbitrary number for testing). During the hectic rollout, this never was changed to the actual number which was much smaller.
Once the system came on line, every night at 1AM portions of Omaha (which included lots of call centers) would lose all long distance service for a couple of hours, as all these computers called in and retried several times.
Eventually the phone company figured it out and contacted us, and we discovered and corrected the discrepancy.
Another issue was that we had a number of hotels that were using pulse dialing (this was a long time ago in a galaxy far far away). Sometimes these would be off by one due to the inherent unreliability of pulse dialing, and the result was a lot of calls to certain numbers related to the 800 number, all in the middle of the night.
BTW... as far as I know, this was the first large widely distributed commercial computing system to use switched telephone circuits for communications (but no doubt some other grey-haired slashdotter knows of another).
The only good weather is bad weather.
bah sure this is another attempt from the goveremnt to blame us nerds for doing somthing heh. maybe if theypaid us more they wouldnt get buggy code ahhaha.
eric
They're coding in Ada. Jeez, man use a real language like BASIC.
Remember, You are unique...just like everyone else.
Far and away my favourite:
NORAD defense radar system mistook the Moon for a hostile incoming missile
They don't say why, but I've heard that it was because they forgot to program in leap years, and thus the moon was in the "wrong" position. Anyone have anything further on this?
Click on the links, otherwise you don't get all the details. French-friendly exocet missile? Huh? Unless you click through you don't realize that the British radar thought the exocet missile was a friendly munition since the British arsenal included exocets. Any munition headed straight at you is probably not friendly.
[o]_O
He was considering making Fatal Defect required reading for the C programming course I took. From Amazon.com:
In Fatal Defects: Chasing Killer Computer Bugs, Ivars Peterson describes dozens and dozens of hoary computer bugs and gives biographical sketches of the bug detectives who located and fixed them. This book, which reads like a novel, is both entertaining and informative. Many of the bugs that Peterson discusses are not in computer programs per se but in the human systems that run and operate the computers. Very often the operator fails to understand what the computer program requires as input and types in an incorrect command. The computer then executes the command, with potentially disastrous results. Fatal Defects has important lessons for both those who design computers and those who use them.
He also insisted that we not call them bugs. "They are ERRORS, calling them bugs makes it sound like they are cute little accidental things that pop up when actually they are programming mistakes."
-- Adam
As computer systems become larger and take on more important roles, software bugs will cause much larger destruction and loss of life.
Civil Engineering has been around almost the longest of all engineering and a glitch can wipe out entire towns/cities with floods.
As the CS field matures and more ambitious projects are undertaken there will be mistakes. But we learn from each one and the advances always outweigh the risks.
Make reading the ACM's RISKS digest a part of your regular routine, and you'll hear about these kind of software-related problems and many others - usually shortly after they happen. The RISKS digest is available on Usenet as comp.risks, as a mailing list, and on the WWW at http://catless.ncl.ac.uk/Risks. A new issue is published on a semiregular basis, every one to two weeks. It's not only informative but interesting too.
--Jim
Sure, some people here gripe about this not being newsworthy. But as a hardware guy, I am happy to see that software guys are finally going to be held to some sort of standard.
In electronics, if your hardware has ONE little problem, it's almost bankruptcy time. Remember the Pentium FP bug? And how it would have affected very little? Remember the hoopla, people wanted new processors, etc..
But software bugs? Who cares! It's NORMAL, it's EXPECTED. Well, geeks and nerds, time to get your asses in gear and live up to the same standards mechanical and electrical engineers have been living up to for decades.
I'm tired of being held to a standard of perfection that the software people (who make more money than me!) don't even KNOW about.
GPL raises this to new levels of concern. You can never know where your code will be used. It might just find itself in an cruise missile.
-twb
French-friendly exocet missile?
The French are NEVER friendly. Rude, yes, but friendly, never.
So much for poor Visual Basic Programmers :)
Damn, they never get to do fun stuff like this.
Rapid Nirvana
This one time I missed closing an /a tag on a post, and missed getting a wicked killer First Post.
It hurts when I pee.
I hope you don't mind a little nit-picking. The thread is titled "Debug Your Code." A lot of the problems listed in the article were for errors that occurred in situations outside the parameters that the programmers were expecting.
I personally see debugging is the art of making sure the code works and is fulfilling the logical expectations of the programmer.
These problems show that there is a need to go way beyond traditional debugging, and do aggressive testing outside the programmer's box. Debugging ain't enough. Those dregs toiling away in the testing department might be worth their skin afterall.
kd
It delayed the re-opening of the airport for about seven months or so. After it did finally open the system wasn't working yet so the baggage system had to be operated manually for a couple of months.
I was a consultant at a major bank 3-4 years ago. An FTE made a one line error in a Cobol program for printing bank statements. Everyone in a small town of about 6000 got Their first page of statement and pages 2,3,4 etc. of someone else's statement.
What other piece of buggy software in history ever caused as much widespread collective apoplexy? :)
"Ask not what your country can do for you." --John F. Kennedy
Many of these bugs on long range probes and other stuff could be prevented with whole system debugging.
Just test your software in situ, meaning that you take your final code, running in your final product (like the entire spacecraft, ready to be loaded), with all the sensors and comm links, and you just falsify sensor data. For example, you could heat a temperature probe, and put a pressure sensor in a compressor. The system thinks it's getting real data, and if the thing mis-converts something, it'll do it on the ground before launch. This tests EVERYTHING from cables to interfaces.
-twb
The Therac-25 was an automated x-ray machine that overdosed patients. Fatally. It was a UI bug rather than a software bug. It's dissected in "Killer Defects" (IIRC) by Negroponte (again, IIRC).
Best Slashdot Co
Don't take my word for it. Do a web search and see for yourself. Here are some references to get you started:
http://www.fas.org/spp/starwars/docops/rp911024.ht m
http://www.csmonitor.com/durable/1997/09/08/opin/l etters.1.html
GMD
watch this
in the one talking about the denver airport. "Airport opened in February 1995....1 airline used it..Others used an alternative carbon-based neural network system."
The Day the Phones Stopped, by Leonard Lee.
Some of the incidents on the page are covered in this book, which mainly addresses the problem of becoming overly dependent on software for real-life, mission-critical applications.
Unfortunately the book, published 10 years ago, appears to be out of print, but as I recall, the issues it covered are even more relevant today.
How about that horrid bug that extends the width of the window data by a factor of 8, making it impossible to read?
Does Slashdot want me to just waste more time at work or what?!
I'm sure we all have those bugs that we catch in bench testing. Mine was forgeting to add a cancel button to the following dialog box:
... well, you read the papers. Glad I caught that one before I released it to test.
"OK to delete database"
When I caught that one I had visions of a user who had his/her million dollar database deleted charging into our office with a shotgun and
Remember when the Hubble first came out and everything was fuzzy? The mirror was ground perfectly -- except they had missed a "sin" term in the curvature equation. Result: the outer edge was mis-ground by 1/80th of an inch.
"Diplomacy is something you do until you find a rock." --Richard Pound
Let me get this straight... the resolution of the internal clock of the Patriot is 0.1 seconds, and yet an error of just 0.34 seconds caused the system to fail completely... Isn't that is cutting things a bit close right there?
And this error 0.34 second error occurred after nearly 4 days of uptime... The clock was off by less than 0.34/100hours*60*60 ~ 1ppm. That is a pretty dang good clock yet not good enough.
This does not sound like a software bug to me, this sounds like a poorly designed system.
If I misestimate the mass of a planet, is that a software bug?
If my software sells stock when a certain threshold is hit and yours does the same, and that least do a financial industry meltdown, did my software not work as planned, or is the issue more the dynamics of the market being somewhat unpredictable?
The tacoma narrows and london milennium bridges are both listed here, yet neither one is a software issue - hell the tacoma bridge collapsed in 1940!
That said, it is a pretty interesting list, but calling it a list of software bugs and using it to underscore the importance of regression testing software is a bit of a stretch. If anything, it underscores the importance of editing and proofreading your content.
I don't understand why there are spaces in the URLs I wrote in my message, but here they are, sans spaces:
http://www.fas.org/spp/starwars/docops/rp911024.ht m
http://www.csmonitor.com/durable/1997/09/08/opin/l etters.1.html
Note: I am NOT a regular reader of the Christian Science Monitor. I included that link because the author is from MIT. And before you mod my previous post as off-topic, I'm just pointing out that it's easy to dismiss something as a software bug. It's much harder to do some real thinking and make sure that the concept is valid to begin with.
GMD
watch this
Half of it boils down to, We are not responsible for anything bad, even if we were warned about it and have a fix for it that we are holding on to sell as part of an upgrade.
Fight Spammers!
The bug that caused Airane explosion was a requirements analysis bug. The Pentium FP bug was a hardware bug.
A quick skim of the rest nets me at least 6 more non-software software bugs
After seeing that, I can't really trust the list on things I don't have a good knowledge about.
Here's a challenge for someone: Go through the list and find out how many (if any) of the listed software bugs are actually software bugs.
The claim for this one is that a Patriot during the Gulf War failed to intercept a Scud missle and the Scud missile killed 26. Ergo, a software bug killed 26 people.
Considering that even the military now admits that no Patriot *ever* intercepted an Iraqi scud, this inference is unfounded.
(A former Theratronics employee is standing right behind me, but he denies having worked on the Therac-25.)
According to the writeup in Aviation Week, the overflow was in code from a previous version which was still being called but whose results were never used.
Then to make it funnier, turns out the system engineers had decided that since software is infallible, any exception condition would indicate a hardware failure(!), so instead of a reset they shut the affected computer down altogether.
Funnier yet, they felt free to shut the computer down because there was a backup, but the backup was running identical software, so in no time at all it experienced an identical failure.
on the Steve Baller smash-hit Developers Developers Developers Developers, Developers Developers Developers Developers!
The patriot missile failure was blamed on a roundoff error causing an accumulating time error, resulting in a miss.
But the bug was more fundamental: The missile and radar computers synchronized clocks when the system was booted, then drifted apart. After a hundred hours the drift from the roundoff was enough to make it lose a target.
But had the missile synchronized its clock upon launch (or better: target acquisition, to give it time to settle), the tiny roundoff error accumulated in flight wouldn't have mattered. Meanwhile, had the calculation been perfect, differential clock speeds still would have caused a drift.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
"debugging" is an unfortunate word, it suggests that when a program is created it *somehow* contains "bugs" or "gremlins" and that these have to be removed.
The bugs don't get there by themselves, in my experience they are usually the result of some (often understandable) assumption on the part of the system designer or programmer.
A trivial example is a subroutine designed to add to integers and return the result failing to check that 1) it was called with *two* parameters and 2) that both parameters contain integers.
The design of the program should incorporate code to positively check that all possible assumptions are true.
The techies can't be responsible for drawing up the complete list of assumptions, the user or customer must be involved in this process also.
If an accountant has told me how to prepare a balance sheet, he must also tell me the complete list of checkable assumptions that must be tested. I'm not an accountant (engineer, architect, whatever), the relevant expert must take responsibility.
Nor can we rely on "experts" (computer or otherwise). All of us practising some skill, sooner or later, start taking things for granted. Not only do we need expert debugging, we need dummy debugging to mind the bits that the experts will take for granted.
I had a prof who was stressing someone else's opinion that we change from the word "bug" to the phrase "time bomb" so that people would get a better feeling for what they really were -- incorrect sections of code just waiting to mess you up.
and goes on to say:
seven times the loss of human life, but less of a tragedy? I guess they are soldiers so fuck 'em, eh?
This story is over two years old, so they have had ample opportunity to correct it. The "comment" button on that page just takes me to the front page. Nice.
Also on that page, "The DoubleSpace automati hard disk comparision software included in Microsoft MS-DOS 6.0 [. .
Ironic that there are such glaring errors in an article about buggy software.
Well, I wasn't particularly a fan of Byte before, but now I'm convinced that they suck.
-Peter
lack of proper validation of input data is a BUG!
Some years back, as a grad student, I saw a bunch of colleagues do a rather unnerving experiment. Much of the number crunching was, as usual, done in Fortran. So they instrumented the compiler to silently test for integer overflow, report when it happened, and also report whether the program tested for it.
Their result was that roughly 50% of the Fortran programs on the mainframe computer produced at least one number in the output that was wrong due to undetected integer overflow.
This itself would be bad enough. But a bunch of us followed this up by asking Fortran programmers about it. What we did specifically was to point out that, unlike floating point, where there's an interrupt, integer arithmetic required a separate instruction to test the overflow flag. So testing for integer overflow took extra cpu cycles. Then we asked them whether they thought that software should be modified to always test for integer overflow, as is done with floating point.
The answer was overwhelmingly that if it took extra cpu cycles, the software should not check for overflow.
When we pointed out that this introduced the risk of programs producing incorrect results, the Fortran programmers invariably said that didn't matter. Faster is better, even if some of the results are wrong.
I think of this whenever I read about computers used in medical, transportation, or other areas where malfunctioning software could put lives at risk.I don't believe that the "software culture" has changed significantly in this respect since then.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
Hmmm...
so you're saying a Pentium chip is software?
Why dont you read the article.
"You worthless post!"
-Shakespeare, 2 Gentlemen of Verona, 1. 1. 147
I once worked (temporarily) in a hospital, where the entire patient information system was made in Clipper by one of the surgeons in his spare time. He had a custom version for every user: when someone wanted some new function, he coded it on the spot for that person. No version management, no design, nothing.
This guy was approaching 65, and he was the only one who knew how it worked, so it was an accident waiting to happen. No-one wanted a new system however, *because* it was tailor made for everyone.
As it turns out, there have been a lot of screwups in the operations performed there. (Wrong bloodtypes, unnoticed allergies, etc.)
Didn't exactly surprise me
Be wary of any facts that confirm your opinion.
Christian Science Monitor is usually a reputable paper, if only because they have their own reporters doing the work instead of tacking stuff onto ap/reuters stuff.
The spaces are due to the slashdot lameness filter. Yay perl.
[o]_O
So is it a webpage bug when you see:
:)
"Pentium Prozessor" and "Pentium Porcessors" in the writeup... [rant] This is the same kind of sloppy work that causes cars to explode, missiles to veer off course, and a busload of nuns to get blown up by a rogue robot (Nun Soup?) [/rant]
Oh well
"It's tough to be bilingual when you get hit in the head."
Javascript's misuse of Date.getYear().
Well, the method itself (and similar methods in server-side web scripting languages) was not the buggy part - it was just that people didn't realize it returned year-1900 and not year without centuries part...
I remember that the New Year's Day in year 100 (or 19100, depending on website) was ocassionally a very happy one.
And for the life of me when will programmers realize
that just because the software works on their
box it may not work on another machine.
If you don't have a clean fresh install of a MS
operating system you have no idea what kind of crap
is on the box.
Just installing Visual Studio,Source Safe etc, makes
testing useless on your main machine.
Program on your main machine.
Test on a clean machine.
Its easy. And then maybe QA would not feel you are
a bunch of overpaid jerks.
A few years ago, I remember reading an article about a US Navy warship that ran WinNT and the system got a BSOD and left the boat crippled for at least a few days...
:)
Can you just imagine the following situation?
Mr. President: Fire the nukes!
NORAD: Firing now, sir....wait...
MS Nuke has caused a general protection fault at address 0x0324324h:8901. The application will now close. Please contact Microsoft Support.
(a few seconds later after the crash)
An annoying popup message comes up:
"Register your userid at Passport.NET!"
I think the situation speaks for itself.
So we have a specification problem and a system design problem. Neither is a pure "programming problem".
Software crashes are like airplane crashes -- blame the lowest guy on the totem pole. In air crashes, it's the pilot. In software, it's a coder.
Welcome to the Turing Tarpit, where everything is possible but nothing interesting is easy.
"Wrong Starting Estimate of Uranus mass in
Iteration, Data Compression, 1986"
Caused wife 1.0 to go into panic and terminate all sex threads for the next three weeks.
a fucking scud did. The patriot bug prevented it from helping, but it didnt kill anyone. Sheesh.
My software always works perfectly on my system. Zero bugs.
I have no idea what the hell the users do to it to screw it up.
A student in my robotics lab mistakenly inserted a mirror-the-z-axis instruction in a robot program - oops - The robot dutifully attempted to follow and lifted itself on its gripper, almost tipping itself over. It made me glad that I hadn't bolted it down since either the table or the robot would have had to suffer.
leave it alone.... I want in :-)
When after sitting down for 36 hours straight when I first learned to program in C, I wrote a small, but usefull, payroll program. By the end, during the function that would print out the check, I added "Press any key to continue, any other key to abort". Lucky for me I never released that program.
---
All comments are not factual unless stated otherwise.
There were many things that went wrong during the incident, but one of the FEW things that worked correctly was the AEGIS weapons system on board the guided missile cruiser. The error lay in the crew's mistaking the range information reported on the radar screen with altitude information. As a result, the CO thought that the incoming contact was flying straight towards his ship and decreasing in altitude (preparing to attack).
Blaming a "cryptic display" is hardly a software bug if anyone is familiar with radar screens. That's why we train people to read them!
The bizarre thing is that the fix is that a patriot installation literally has to re-boot on regular intervals in order to reset the internal timers. The bug is real, and it has to be dealt with.
Believe nothing -- Buddha
No discussion of catastrophic bugs is complete without the Therac incident report. Everybody who calls himself or herself a "programmer" should be forced to read that one... twice.
I live with a house mate that loves optimised coding.. along with this he cant stand adding code just to to simple sanity checks.. now this bloke was gonna get a job with some government missile development base.... :/
I dont see how you can justify speed over reliability to such an extent.. are there lots of you kinda coders out there?
moo
I'm picturing this: bridge full of people, I whip out my sound system and lighter and blast out "Stairway" with my lighter held on high.
I start to sway. Everyone else sways.
As the bridge comes down and I fall to my death, I think that must be the most original way to flaunt those suicide hotline signs at the end of the bridge.
Jesus saves....And takes 1/2 damage.
We have to accomodate our users and unknown environments. When a reasonable user makes your program do something bad, that's either a user training problem or a software bug. You didn't check input data carefully enough, or you didn't provide a good user interface, or your requirements were bad, etc. All of those are software bugs.
The Pentium bug, I'll agree with. Florida voting, I'll agree with. DDOS is software bug. Software run in an environment like the web has to accomodate malicious users. Wall Street Crash, software bug. There was a set of conditions in which the software did bad things.
...the ice cream bug!
Your first link is a translation of a patriotic Israeli article cheerleading the competence of their military. It doesn't necessarily make what they're saying false, but does make it suspect.
The second link is way low on content, I'm not sure how to judge it. All it says is "we looked at a bunch of videotapes and arrived at this conclusion". And then goes on to mention the bitter dispute between the U.S. and Israeli military over why the system didn't work so well in Israel.
I'm not sure I'm going to buy either argument. I know enough about flight characteristics to question the assertion that the scuds were so good at jinking and chaff the patriots (which were originally designed to hit jinking, chaff releasing aircraft) couldn't hit them.
If the scuds were dropping debris because extra fuel tanks made them unstable:
1) Why wasn't the wobble a pronounced problem at launch when the extra weight would have completely thrown off the trim characteristics of the missile?
2) Dropping "debris" is a bad thing, and it's only a matter of time before doing so results in an uncorrectable failure of the missiles flight aerodynamics. Why weren't most of them failing earlier?
3) Missiles don't fly in smooth trajectories nearly as often as you think. They jink to try and make anti missile systems (like say the Phalanx close-in weapons system) miss them or think they are dead and not worth any more attention.
Even if the patriots did fail, why would that have grave implications for our anti ballistic missile shield? SCUDs are cruise missiles, not ballistic missiles. Why do you think those big computers at Norad can accurately predict where the warheads will hit just after boost?
Education is a better safeguard of liberty than a standing army.
Edward Everett (1794 - 1865)
Human effects on bridges is hardly a surprise. Recall in 1981 when the Kansas City Hyatt's skywalk collapsed, killing 114, because the pedestrians were dancing (and the design was altered to ease construction). You'd think that would have been enough of a wake up call to the millenium designers to consider human motion. more info
Armys break cadence when marching across bridges, at least as far back as Napoleon's time. Presumably they learned that the hard way.
On a more personal note, I have participated in the unintentional destruction of a gymnasium. 80 or so people crowded together in the middle, bouncing up and down, and then "down and down". We fractured the engineered wooden joists. Fortunately it failed gracefully. Just sagged down about 4 feet in the middle.
What I'm trying to say, not particularly directly, is "don't give the designers of the bridge a pass because this new phenomenon struct their bridge". Chastise them for risking people's lives and wasting resources by neglecting the loads placed on bridges.
The old joke about the coder informing the salesman about the "Bug" in the software.
To which the salesman replied, "It's not a bug, it's an unexpected feature!"
Sales people are the bane of the coders existance.
We have to create the products they already sold to the clients.
-Goran
Carpe Scrotum - The only way to deal with your competition.
In one of my programming classes an instructor had a phrase that applies to this. "Bullet proof your code" Meaning whatever the user enters the program should work right.
Problems often come up in programing for input. Normally you have an expected range of input, and if your program works at all and the input is in the expected range you get the expected output. BUT what if the use enters the ABSOLUTE maximum value, is your variable size large enough? what about the absolute min, often zero, does it still work right. Your not going to try and divide by that zero or something that will fail. What if a negative number is entered.
Those are all basic unput checking questions...but its the general idea. Bullet proof your code, or at least try to make it so.
LinuxWorx
Spelling errors are intentional as are gramatical error
During live coverage of a Scud attack, one of the Patriots veered sharply to the left and hit an insurance office. The cause was said to be an error due to a time leak. The longer the Patriots were "online", the more leakage occured.
If you aren't part of the solution, there is good money to be made prolonging the problem
This was perhaps a glitch in the design of the system, but it certainly sounds like the software worked as intended. That's not a bug, is it ?
Oh, I can't help quoting you because everything that you said rings true
This IS the text on this very sort of thing. I love techno-"oops, that's not right, is it?"-horror stories and this book is filled with them. I REALLY recommend this book! Here's an example of the page after page of entries it contains:
Making Rupee!
Due to a bank error in the current exchange rate, an Australian man was able to purchase Sri Lankan rupees for (Australian) $104,500, and then to sell them to another bank the next day for $440,258. (The first banks' computer had displayed the Central Pacific franc rate in the rupee position.) Because of the circumstances surrounding the bank's error, a judge ruled that the man had acted without intended fraud, and could keep his windfall of $335,758.
Computer Related Risks - Peter G. Neumann - ACM Press - 1995
The bottom line here is "computing is, in a technical sense, a risk". Actually, technology - of any kind - is a risk. Which I suppose leads us to remember that life is a risk.
At which point, I'll just stop rambling and point you all to Amazon to buy the book.
I swear by MacOS X. Although I use to swear *at* MacOS 9...
For example in VB if I say;
dim strDouble as string
and say strdouble = strDouble * 0.02
I will get a run time error trying to compile the code (it is a result of a TYPE CONVERSION ERROR). I don't think that this type of error is possible with the advanced compilers on the market.
I think this is another example of the government trying to cover up some stuff with a savvy press release. Don't believe everything you read. This mistake with the missles is just a story to cover up a more emberrassing truth.
Man I'm glad I can safely say nobodies life will ever hang on my ability to code.
I think most of the bugs in software are the result of "Coding Under Influence". Wether it is a strict time-limit, ambiguous specifications, no sleep or other disturbances, it leads to blatant dumb assumptions or similar faults. Everyone knows that driving under influence is dangerous and can lead to accidents. Why do "software architects" think this is different when someone writes important programs?
I think part of the problem is that writing software is a rather new handwork in comparison to e.g. metalworking. Programmers don't have a union, often they work under poorer confitions than workers at conveyor belts if you consider the higher responsibility they have.
But that's exactly what debugging is. Implmenting a spec is one thing, but also being able to handle data that isn't exactly what you expect is what happens after you debug an application.
As a programmer, you parse through input from a user, if the user does something that they are not supposed to, the program should either ignore the input or prompt the user, possiable an error message.
You have to throw data at a program that it shouldn't get and the program should only do what it was designed to do, not more or less. Buffer overflows are bugs in software that can be exploited to make to program do something it wasn't designed to do.
(don't mind the yellow)
The problem wasn't that pedestrians swayed, but that when the bridge swayed, the pedestrians compensated to keep in balance. This caused the bridge to sway more.. you get the point.
Cars don't do this. But we move our feet to stabalize ourselves. Not too many bridges have to worry about something like this.
The fix was pretty easy too. They essentially put shock absorbers under the bridge. Just like what a car uses to keep a spring from rebounding incessantly.
In any case, the SERIOUS problem was that when you flew over the equator, the computer would suddenly 'realize' that you were upside down from where you wanted to be and try to immediately turn the aircraft over to the 'proper' orientation. It was said that the aircraft would have survived the maneuver, but the pilot's neck would not.
Luckily this was found during simulations If it had happened during a real flight, it could have taken a long time (and lots of fatalities) to figure it out.
On a lighter note, there is apparently a subroutine -- phonetically referred to.. It was either wait_on_wheels() or weight_on_wheels(). In either case, it was added after some slap-happy test pilot tried retracting the landing gear while sitting on the runway (resulting in millions of dollars of repairs).
Sometimes boldness is in fashion. Sometimes only the brave will be bold.
Of course, no one has ever died as a result of the Coriolis effect, but the rotational frame of reference one of the scientists refers to sounds like the rocket that missed its landing point in the original link.
They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.
-sk
I always run these.
I had a job writing regression tests. I have not looked into any of these install tests. I doubt they are as thorough as they could be, but they have failed once in a while, and I have always investigated the failures.
Infuriate left and right
I have read that one advantage we had over the Germans in WWII was that our machine guns were not as accurate as theirs.
Due to this inaccuracy, our machine gunners were able to hit a larger window, didn't need to shoot as accurately and, as a result, killed more people- kind of like comparing a pistol to a shotgun.
So, maybe Saddam is on to something by 'copying' good 'ole Yankee ingenuity.
... try some intentional stupidity. The Interface Hall of Shame
Never confuse volume with power.
i wonder how long it will be before a f1 driver is lost or something insane occurs with all the new software they have and the ability for the pits to communicate back to the cars now legally. ... 'changed permissions on steering wheel device ... locked driver user out of ability to change back break balance'
... oh my i can just see using BAR/Honda as a weapon to take out other drivers on the track. because they use some insecure microsoft shit in their cars.
i would love to see the bug list that the teams a have accumulated already with the new launch control systems
i noticed that BAR/Honda has a job opportunity for NT embedded programmers (Windows CE) with msXML & Soap experience
homefully the embedded NT stuff was for something like a sophisticated training PDA instead of dealing with the car.
members are seeing something, your seeing an ad
Your assumption about the nature of pedestrian motion that caused the bridge wobble is incorrect:
They did take into account pedestrian movement on the bridge; they didnt take into account pedestrian motion on the bridge locking in to the motion of the bridge:
1) Pedestrians walk on bridge
2) Bridge wobbles slightly
3) Pedestrians adjust their walking to be in phase with bridge
4) Bridge wobbles more
This was a new phenomenon, due to the lightness of the construction of the bridge. It is now fixed, by the addition of dampers.
-BB
Uh oh. The SCUD is very much a ballistic missile. Therefore most of your points are moot as debris follows the same trajectory as the rest of the missile, disregarding air resistance of course.
I don't even pretend that it would be easy to create a stable unstable flight, but it seems that if something so dumb can elude our ultra-high-tech anti-missile systems, then maybe we should consider doing the same thing on purpose. Without letting the missle turn in to a mass of flying shrapnel though.
THAT NEVER HAPPEND, you people have some real reality issues. MOVIES ARENT NECESSARALLY REAL!
_______
Death wish, n.:
The only wish that always comes true, whether or not one wishes it t
I wonder what experiences anyone else has had with divide by zero "glitches." Anybody else have a similar experience?
In the old USSR (Stalin times), there was a standard bridge acceptance test:
1) put project managers, lead architects and engineers under the bridge;
2) put heavy loaded trucks on the bridge.
That was real extreme testing.
Actually, the Pentium bug was software related not hardware. The "computer hardware" was fine. The burned in microcode was wrong. So, despite the fact that it manifested itself as a hardware error, it was in fact the chip's own software that was wrong.
Embedded code is still code.
Don't put screen captures directly into .DOCs, as they will probably be stored as uncompressed 24 bit RGB images. Simply convert them into 256 colour images before pasting them into the file and they will be stored with run length encoding.
Also turn off "fast save" (otherwise known as "corrupt my data").
Alas I think it is harder to get rid of the rest of the crap it puts in there (unless you save as RTF and manually trim it :-)
A lady told me after showing her the bug web site that during the 60's when they were developing s/w to monitor the astronaut that a person who prided himself in zero bugs in his s/w had develivered s/w that crashed. In this case the s/w did data reduction of data which and crashed since it didn't take into account the astronaut dying (in which case an astronaut actually did die) and thus the vital sign data was flat lining.
in the data area of my driveway. It doesn't contain a delorean, and I think you should fix that particular bug.
The Hyatt's skywalk collapsed soley because of the change in design. The design change caused the walkway to fail to meet building code. Some civil engineers who studied the disaster were surprised it could support its own weight, much less the weight of the pedestrians.
Quoting from a Kansas City Star article.
The dancing people were by and large on the floor below the skywalk, participating in a dance contest.
The mistake that caused the Hyatt disaster was not one of failing to consider human motion in the design, but failing to consider the effects of seemingly minor changes in design.
But then again, I could be wrong.
Thanks dude (presumably). I had tears coming from my eyes laughing at this one.
Perhaps all errors are bugs.
However, not all bugs are errors.
As another anonymous poster intimated with a quote from the Mythical Man Month, there are some bugs that arise not from errors in coding per se, but from problems that arise in the combination of code or in unanticipated uses of it.
You could call such things errors, in that coders should understand how their code works together and should anticipate users' intended behavior.
However, I think "bug" is a more apt term, because it more adequately describes the fact that some problems arise not from the code itself, but from factors that arise from elsewhere, outside of the structured input and output of the program. They are factors beyond the correctness of the code, that arise from inadquate understanding of the system in which the program functions.
Anyone can make any code "buggy" by using it in a way that it was not intended for--by going outside the input scope of the program, so to speak. You might say that that's not a bug, it's misuse, but I say there's a fine line, and that fine line is why bugs are not called errors.
One of my CS profs in college told us that the reason 3 mile island happened was because:
- the control software for the plant was written in fortran
- the temperature on one of the readouts came out ***** instead of a number (asterisks in a fortran program represent(ed) a number larger than your format statement will allow)
- some engineer that didn't know that just said 'huh. look at the pretty asterisks' instead of following up on things.
is this just urban legend? have i been suckered in?
As a former ADA (Air Defense Artillery) officer in the U.S. Army, I can tell you that the Patriot Missile system was designed primarily to shoot down enemy aircraft. It's ability to kill missiles is a secondary feature.
Robotiq.com is heavily tested on animals
In the early 1990s, before this part of the Eastern U.S. had ten digit dialing, our SCO server would dial out, at 1:00 am, to all the little Pep Boys stores in PA and New Jersey in an attempt to update their inventory tables. Alas, one programmer forgot about the New Jersey area codes, and of course there are some overlapping 7 digit numbers between the two states. Oh, and did I mention that the system was coded to KEEP TRYING every ten minutes minutes until it was successful? Heh, heh...at least it wasn't my phone they were ringing at one am...
Yikes. I'd call in sick that day.
Of course the bad side of this is that if it collapses, you've just lost
1) The bridge
2) People who were most familiar with the project, and could fix it
3) The heavy loaded trucks that could've been used for something else
But I guess the idea was to have this be scary enough so that it would never happen. Ever actually hear of a bridge failing this type of test?
Please subscribe to see the more insightful version of th
well it comes installed on all PCs, whereas you have to download open office which costs money in bandwidth charges! :-)
Actually there are missiles designed to do just that, such as the polyphem fiber guided missile, which has a 'weave' feature.
1. You'd have lost this anyway - that's the point of the test.
2. They designed a failed bridge, and you want them to design the new one?
3. These are cheap when you have hundreds of millions of slaves.
What are you saying! The Corilois effect is one of the main causes of huricanes!
The floating point explanation is analogous to that coriolis-effect-causes-water-to-swirl-in-the-toile t myth that you find in so many physics textbooks
There is even worse physics-textbook myth: that the elevation forces of pane wings are caused by different velocities of the air flow below and above the wing and irrelevant application of Bernoulli law. I thing it was Zukovskij who showed that if there is only laminar convention, total forces are ZERO on any shape. Explanation is little more complex and turbulent convention has to be involved to explain the forces.
Coriolis-effect-causes-water-to-swirl-in-the-toile t myth that you find in so many physics textbooks (the Coriolis effect only works on planetary scales).
I know this is offtopic, but "planetary scales" ? Please... I certainly hope no one quotes you on that one. Man-sized pendulum is just a one example with what one can easily detect the coriolis effect. Long range cannons are another thing where the coriolis effect is also taken into account and there are many many others.
Just because the bath tub doesnt show the coriolis effect you shouldnt jump the gun and start talking about "planetary scales".
1 Earth is warming, 2 It's us, 3 it's royally bad, 4 we need to take action NOW
Firmware can be soft
Robots are everywhere, and they eat old people's medicine for fuel.
I'm sorry, I don't know VB at all but isn't VB case insensitive?
Also, with this example, you haven't yet initialized the variable. Wouldn't this give an error of some type regarding use before initialisation?
You do have to remember that the contract is usually given to the "lowest" bidder. Cost cutting usually, but not always, means shaving safety factor.
Like the astronaut said, when asked how he felt. I'm sitting atop a hydrogen bomb built by the low bidder in a government contract! How do you think I feel?
Surely out of the 20,000+ people in attendence last weekend in Pelham, some were Slashdotters. Maybe....?
Well if you were there, I bet the phrase "Bridge not designed for pedestrians dancing" brought back the fear of death for you.
If you weren't there, this isn't offtopic. Seriously.
Given how the current trend in a lot of scientific fields is to borrow good ideas from mother nature, I'll betcha this is on somebody's drawing board somewhere.
"Do you expect me to talk?" "No, Mr. Bond. I expect you to die!"
Um, no. The SCUD is the theater ballistic missile not a cruise missle. It looks like a WWII German V2. See this page for more info.
Last year I was talking to a small-plane pilot about this. I of course had seen the 'educational' shows that explain about the wing shape, air pressure, and such. The pilot mentioned that that was just part of it.
Then I asked about the stunt planes, the barn-stormers who fly upside-down. He said for those planes, the wings are symetrical top-and-bottom. No "greater air pressure on the underside" or nothing, because if that was the case, when they went upside-down, they would plow into the ground. For them, it is all pilot skills keeping the plane flying level.
I certainly don't know the full details, but it is an interesting topic.
Some software that works.
420,000 lines of code, and only one error found in each of the last three versions.
In the last eleven versions, 17 errors altogther were found.
Note how much money it costs to produce software of that quality, and you will see why software usually has bugs - especially when you add in the short development cycles that management wants today. Damn the testing, full release ahead!
> This small generator can be made pretty damn indestructable (blackbox anyone?)
This is a nice thought, but we're talking about spacefaring vehicles, not airliners. There isn't an airplane built that goes as high as these vehicles. The problem actually isn't a downrange crash from a failure within launch frame (the casing for the radioactives will withstand this sort of failure), but a reentry-style fall from a failure in the second/third stage. From that height, the generator is going to be falling very fast and very hot, and solid iron has trouble surviving these conditions (as would most black boxes, and anything else not specifically designed to withstand de-orbiting). So, while it's not a very big problem (from sub-orbit, it's hard to hit a populated area), it's still very possible to drop radioactive material in a populated area such that contamination is likely.
I agree that there has been a lot of fearmongering about using radioactives for spaceships, but we learned in AE classes that using the term "indestructable" in conjunction with anything that leaves the atmosphere is usually a mistake.
Virg
BRL has a test suite, as does Kawa. I don't think test suites in free software are so uncommon.
The explanation for the sinking of Sheffield is incorrect. I work on the system used (it's still in use, although enhanced beyond recognition). If this was caused by a software error it would have been legendary status within the company. A better description is given here
This from the referenced NASA writeup on the loss of the Mars Climate Orbiter:
"The 'root cause' of the loss of the spacecraft was the failed translation of English units into metric units in a segment of ... software" said Arthur Stephenson, chairman of the Mars Climate Orbiter Mission Failure Investigation Board.
That's not the root cause! The real root cause is that we in the US insist on using the obsolete, difficult to use, and non-standard English system. The failure to convert units was a manifestation of this true "root cause".
I'm sorry you didn't find either link I provided to be convincing. There are many other sources of info. I suggested (and still do suggest) that interested readers do their own web search.
Dropping "debris" is a bad thing, and it's only a matter of time before doing so results in an uncorrectable failure of the missiles flight aerodynamics. Why weren't most of them failing earlier?
If your point is that a missle so unreliable doesn't make a good miliary weapon, I completely agree. The Iraqis were desperate to increase the range of the scuds and simply took the missles apart, stuck in some more fuel, and tried to put them back together. I doubt they tested the modifications thoroughly. Scuds in general are thought to be "joke" weapons. Most military planners felt this way prior to the Gulf War and had so little respect for the scuds that they didn't bother to factor search-and-destroy missions into their planning. Unfortunately the scuds, while poor military weapons, are reasonably good terror weapons. They have crap accuracy but can hit an Israeli city well enough. When the problem became apparent, the US had to divert significant aerial resources to search-and-destroy missions. So, in a way, the laughable scud actually was a successful weapon, if you consider that terror was Saddam's goal.
Even if the patriots did fail, why would that have grave implications for our anti ballistic missile shield? SCUDs are cruise missiles, not ballistic missiles.
As others have already pointed out, your statement is in error. Scuds are certainly not sophisticated cruise missles. My comment about the Patriot failure being a bad sign for our upcoming missle defense shield was to point out that if we can't hit relatively-slow-flying scuds, how are we possibly going to hit speedy ICBMs? We haven't even solved the theatre ballistic missle problem yet. So we're years away from being able to intercept WMD-bearing ICBMs.
GMD
watch this
As I heard someone say: "The program fails and the power plant explodes, poisoning the earth and the sea. Famine and disease sweep the world. All die. Oh, the embarrassment."
-bZ-
I'm pretty sure the media has mentioned this, beyond those two media links you already posted, I mean. The issue has been debated since the first Patriot experiences during the Gulf War.
But I don't really see how this has "grave implications" for an anti-ballistic missile shield. The effectiveness of the Patriot missile used during the Gulf War era is in doubt, but a that does nothing to invalidate the general concept of destroying a ballistic missile with another interceptor missile. It certainly isn't easy to do, and there may be better ways to accomplish the same goal or things more worthy of our limited resources, but to claim that it's somehow physically impossible is both disingenuous and incorrect.
I once wrote a little program that extracted per-store files from a mainframe and deposited them on a LAN for transmission to the stores during nightly polling. One thing I didn't check for was behavior when disk space was exhausted on the LAN. What happened was that 0-byte files were created, but the data appends failed. When the dozen or so per-store files were downloaded to the stores and out to the POS terminals, they replaced the formerly good files, and when the terminals rebooted they nastily crashed, neatly mangling operations at the stores and in IT that morning while we scrambled for solutions.
Of course, we modded the program so it would warn and page when LAN space was reaching its limit. And they bought a bigger hard drive and we never had that problem again.
So, remember to check for space before you write those files.
Continuin OT:
I know this is offtopic, but "planetary scales" ? Please... I certainly hope no one quotes you on that one. Man-sized pendulum is just a one example with what one can easily detect the coriolis effect.
You are right in a sense that you can "easily" set your own experiment which proves eatrh rotation (although I would go rather which biger pendulim than man-sized and repeat the "church pendulum " experiment. He cerpainly ment swirl convention in the atmosprhere as this is wrongly as a anologous to the "wrong" sink swirl.
Long range cannons are another thing where the coriolis effect is also taken into account
Here you are wrong: the influence of the wind is certainly much higher than the effect
many many others
wrong explanation of C. effect. And as you say,
I certainly hope no one quotes you on that one.
How about the code I used to write for my crappy atari in basic - I didn't have a disk drive so I had to key it in whenever I wanted to run it - I was a very poor geek :]
You're right about the firmware ...
But how about squishyware?
Is wetware firm?
I'll shut up now, i'm not trolling, really :)
Robots are everywhere, and they eat old people's medicine for fuel.
I enjoyed this article, but regarding your statement that "misfiring of a US Patriot missile ... caused 28 deaths because of accumulated floating point error", I would argue that the SCUD MISSILE LAUNCHED BY THE IRAQIS caused the deaths , NOT the misfiring of the Patriot missile. The referenced article says that the Patriot "failed to track and intercept an incoming Iraqi Scud missile." Uh... don't the Iraqis deserve 100% of the blame for the deaths here? They launched the damn missile! What software bug caused THAT little problem?
It is true that the Patriot missile did not succeed, but don't ever forget that those 28 people would be alive if the SCUD was never launched to begin with.
> We, as programmers, should make sure that our software are comunicating properly.
Am I the only one who sees humor in saying, "...software are communicating properly" in a comment about communicating properly? Anyone?
OK, I'll shut up now.
Virg
I have read that one good thing about Java is that it does not rely on pointers for memory management. Is that true?
:) -- the VERY FIRST THING I wanted to try to do was to "dereference" this NULL pointer.
Also, I recently have begun a C++ class and on the subject of pointers, the textbook says this:
Never dereference the "NULL" pointer.
Well, after reading that, I decided that -- being a total programming geek after all
Unfortunately, the textbook did not go into detail about how this could be accomplished -- no surprise there.
So can someone tell me what the probably outcomes of dereferncing &NULL would be? Is it really as dangerous as the book's author suggests?
(It occurred to me that it might have a similar effect to something that I read about a while, back -- "Tao of Windows Buffer Overflow" -- this article [cultdeadcow.com]. )
So does anyone here know how to "dereference the NULL pointer"?
I would appreciate some detailed sample code.
Then I asked about the stunt planes, the barn-stormers who fly upside-down. He said for those planes, the wings are symetrical top-and-bottom. You can fly upside-down with "standard" shape only with different angle relative to the horisont although they work less efficient.
I am not expert in aerodymnamisc but in general the turbulences above wings increases the lifting forces but also drag forces so you increase the fuel consumption (you can see that during plane landing where for lower velocities the wings are reshaped). Improvements in the shape of wings of planes is mostly optimisation between these two forces. Otherwise we would have just "plane" (well, symmetric) wings and we would change its angle.
What you say?
The 'funny' thing about having a near miss by a scud - is that you have a good chance of being hit by the patriot that was diligently following it down.
Be Free: Free Software Tuition
I'm pretty sure the media has mentioned this, beyond those two media links you already posted, I mean. The issue has been debated since the first Patriot experiences during the Gulf War.
I guess I'll have to take your word for it but I think all the mass media has done is "mention" it. Pretty much everyone I tell about the failure of patriots is either in shock or replies with "That's not true! I know they work! I saw them destroying scuds on CNN!"
It certainly isn't easy to do, and there may be better ways to accomplish the same goal or things more worthy of our limited resources, but to claim that it's somehow physically impossible is both disingenuous and incorrect.
I never said that it was physically impossible. Four minutes before your post I made a reply to another's comments. I realize that you probably didn't get to see my 2nd post before posting yours. So at the risk of being modded Redundant, here's my answer:
"My comment about the Patriot failure being a bad sign for our upcoming missle defense shield was to point out that if we can't hit relatively-slow-flying scuds, how are we possibly going to hit speedy ICBMs? We haven't even solved the theatre ballistic missle problem yet. So we're years away from being able to intercept WMD-bearing ICBMs."
GMD
watch this
A friend of mine implementing logic in a process control system, overseeing water control for an entire valley, repeatedly dumped over a million gallons of water doing a few test runs.
Actually the problem is known as an assumption error in modeling. It's a problem with the basic assumption used to represent the real system in modeling. Those assumptions should be tested during model validation but often are skipped. Software bugs are verification errors. It sounds like the model programmer built a perfect model based on the inputs he was given, but a basic assumption (that large numbers of pedestrians will use the bridge) was not included.
"As for the future, your task is not to foresee it, but to enable it." - Antoine de Saint-Exupery
"the Coriolis effect only works on planetary scales"
actually if you take a round pan, put a plug in the center, fill it up with water, let it stand for about a 10 days, then pull the plug, you can see the Coriolis effect. Any still body of water that sits still long enough is subject to that force. However that force is pretty weak, so in vibration or motion will disturb it.
The Kruger Dunning explains most post on
They forgot to mention that the hole in the ozone layer over the antarctic was ignored for years because the first satelites to observe it were programmed to consider the data they were collecting outside the bounds of possible valid data.
... could it?" and sent up a satelite to check - sure enough, big hole...
Some guy eventually thought "Nah, couldn't be
The old railroaders in Sweden would do the same, after they'd made a tunnel through a mountain the architect/engineer that specified it had to stand in the middle as the support beams were removed, makes for good design/quality control.
Wax-Museum Fire Results In Hundreds Of New Danny DeVito Statues
How did it go? The system freezes up and posts a dialog that says something like "Unexpected system error: -72." And there's only an "OK" button...
"Biped! Good cranial development. Evidently considerable human ancestry."
Okay, let's consider I completely missed that the SCUD is a ballistic missile. I thought it wasn't because I thought SCUD stood for Subsonic Cruise Unarmed Decoy. Which apparently there is such an acronym, but it doesn't seem to represent these missiles. I concede that point.
So we're back to the SCUD being a ballistic missile. So if the missile is ballistic, following a ballistic trajectory, why was it wobbling in flight? The bulk of the missile, sans debris, should have been in a ballistic trajectory. The scud has controllable fins, so it does have some measure of cruise guidance, I would think if the missile were coming apart in flight, the control surfaces would be among the first to go, and then the missile would again be in a purely ballistic trajectory. Why was it wobbling? If it started tumbling end over end, I wouldn't expect it to survive more than 100 miles. Whatever destabilization occurred needed to start while the missile still had thrust, or the control surfaces were still intact.
Education is a better safeguard of liberty than a standing army.
Edward Everett (1794 - 1865)
According to http://www.ima.umn.edu/~arnold/disasters/patriot.h tml: "The range gate's prediction of where the Scud will next appear is a function of the Scud's known velocity and the time of the last radar detection."
I should have known that Gates was involved in all of this!
sometimes a bug actually is a bug. there is some debate as to whether or not the first time a "bug" was mentioned that it actually was a bug or not. this link clears up some of the confusion. (there was a bug, a moth, found inside a computer, but the word was in use before that time).
There's no emoticon for what I'm feeling!
You're blaming the wrong people for the Patriot fiasco.
The Patriot didn't kill 28. Iraq launching a ballistic missile that killed 28 - That's where the blame lies.
Display some adaptability.
Well, lets hope they don't shoot during reboot then...
"First lesson," Jon said. "Stick them with the pointy end."
I think there are at least one country that is holding on to old (supposedly outdated) Surface To Sea missiles for this exact reason.
Test (where they were presumably used as target practice) showed that they were very difficult to hit due to their erratic flight.
This "feature" (and now we are talking eature in the MS sense, folks) was considered to compensate for their low accuracy.
Calculations indicated that they would have a higher kill ratio than a better missile would.
Wierd!
"First lesson," Jon said. "Stick them with the pointy end."
Or if it has I've never seen it. The article linked on that web page is such utter crap the health department should cite them for releasing sewage.
I was on the Yorktown when this occurred. I had been there since the initial installations and upgrades of all these systems began. And the primary LAN administrator was a friend of mine, he had been reassigned out of our division to support the new networks.
The bug in the software allowing it to crash when it hit that infamous divide by zero error that everyone knows everything about was triggered by the local jackhole putting in some bad information to the system. As I recall, no one was particularly surprised when they found out who it was either.
The computer shutdown forced all the ships engines to be taken offline. ALL of them, not just the 4 gas turbines used for propulsion but the 3 turbines used for electricity as well. This one point is actually a little worse than most articles I have seen make it out to be, during the (brief) period of time while the ship was shutdown, she was shut down cold. Emergency lights and UPS systems and not much else.
However, the ships engineers were able to restart the engines within a fairly short amount of time. I'd say they had the lights back on in well under an hour, getting the main engines online took a bit longer, perhaps as long as 2 hours.
The ship then sailed under her own power to Norfolk Naval station.
The network itself didnt exactly take "days" to restore from this horrible catastrophe. A highly technical and in-depth troubleshooting procedure commonly known as "a re-boot" was performed as soon as the electricity was brought back. A highly overpaid Microsoft technician could probably shed more grim, terrifying details as to the painful nature of this arduous troubleshooting technique.
The ship remained in port about 2 days while tech's went back through the logs to identify who or what screwed up to ensure it was safe to continue using the automated systems. It was an investigation into what happened, not anything remotely like taking "two days of pierside maintenance to fix the problem"
Reading the article again, I think I can safely say that that DiGiorgio fucktard apaprently had a very tenuous grasp on reality, and absolutely no knowledge about the incident whatsoever. Every single statement concerning the Yorktown he made in that article was false, to the degree that I'm not even sure he had ever HEARD of the Yorktown when he was being interviewed for the article.
"The Yorktown has been towed into port after other systems failures, he said."
With the exception of harbor tug boats guiding a ship to the pier, used by every ship in every fleet of the world, the only time the Yorktown had a tow cable attached to her was when she was doing the pulling. The specific incident I remember was in the case of a cargo ship that happened to be in the very unfortunate circumstances of 1. dead in the water 2. wanted for cocaine shipping and 3. found by the Navy.
I suppose there is a slim chance that the Yorktown MIGHT have been towed back in the early 80's when a russian destroyer rammed her, but I doubt even then.
"If you understand computers, you know that a computer normally is immune to the character of the data it processes," seems to me to be a fairly good indication that he has never observed a computer being used by people.
"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.
I just think that's kinda funny is all.
Especially considering that most of the other computer systems were designed in the 70's. They were all, of course, rock solid. There'll never be a problem with anything like that. Besides we only use those for safe, little tasks like SHOOTING MISSILES.
"Installing a control system on a warship and resolving problems as the project progresses is a costly and naive process." This person has apparently never seen how the military approves new technology. Ignoring his idea that "installing a system and testing it so you can get rid of the bugs is costly and naive" the smartship program was designed to force new technology into the fleet as quickly as possible, with the Yorktown being used as a TEST ship, in order to identify what works well and what doesnt. Without programs such as this, getting ANYTHING new actually implemented into the military can take well over 5 years.
I really like the part at the end where he touts himself as the visionary whistle blowing martyr.
One last comment...a previous poster mentioned that "The Yorktown crash was the result of mixing mission-critical and non-mission-critical programs on the same box. Big no-no"
I'm not sure what his point is here, the administrative network did use some of the same servers but had nothing to do with, well, anything.
Trust me, when all involved know of this beforehand, the bridge won't collapse!
When you have to trust your work with your life, you do a good job.
No matter how wicked this sounds, it probably worked... I doubt many people was killed.
(Of cours Stalin more than compensated for the lack of bloodshed in other ways...)
"First lesson," Jon said. "Stick them with the pointy end."
When I was working as a programmer I fixed a lot of problems caused by the previous programmers.
Many of them were caused by their making assumptions about the way the data would be presented to the program i.e. database records will always be sequentially numbered 1,2,3,4,5,6,...
These assumptions came about because the previous programmers would always generate the test records in the same way every time and never took into account that the user could do things like delete records 1,3,4 and 5.
Dumb things were done like hardcoding loops iterating from 1 to N over the database records. This would work well as long as the records were in fact numbered from 1 to N. Feed in records that weren't numbered from 1 to N and things quit working immediately. I was quite surprised that no one before me had ever caught this.
I ran into this kind of thing so often it wasn't even funny.
Another problem that I had was that the programmer just prior to me had a penchant for using IIf statements a mile long. Nesting them was also considered to be great fun. Putting all the code he could in one statement made for much better code in this guy's mind.
Seeing as a lot of this code didn't work right and had zero comments, I wound up breaking almost everyone one of these sick, twisted puppies up into separate lines/statements so I could try to figure out what the heck he was thinking when he coded them.
I used to use IIf statements myself but now I still have an aversion to using them after seeing how they can be misused.
I've tended to write much cleaner, readable, commented code after having experienced working with other people's cluttered handiwork.
...in the US army are usually expected to take a test flight with the pilot after they work on the machine. At least that's what I was told back in the 80's.
That is pretty good QA.
The skywalk collapse wasnt so much due to the dancing as it was to the change in design made by the engineers on the site. It was too hard to use cables long enough to reach the top and bottom platforms, so they just had cables to the top platform and cables from the top to the bottom. As a result the cables were only able to support half the tension that the original designers intended.
All Software Engineers should have a look at Correctness by Construction: Better can also be Cheaper from Crosstalk the Journal of Defence Software Engineering. It contrasts the usual C approach with one using a really tight but powerful subset (SPARK) of an already pretty tight language, Ada
This isn't just an anecdote: there are documented facts. The results (for the problem domain of aircraft avionics and large systems) may not be applicable to the normal b2b and gamezware - but then again, they might. Have a look at the stuff in bold later in this post.
It's not a magic bullet : from the same article:
But the real kicker, one that should cause everyone to sit up and take notice, is this:
One more thing: the SPARK and similar RAVENSCAR ( pdf, HTML version here) subsets of Ada-95 are just that : (proper)subsets that just omit certain language constructs. Write to the profile, and the code is compileable by any Ada-95 compiler, like the downloadable Free GNU version GNAT 3.14p (though commercial users might want the latest-and-greatest non-free version 3.15a. And the ORK (Open Ravenscar Kernel) is, as the name implies, an Open Source Kernel for reliable real-time embedded systems.
Better, Cheaper, Faster, Open-Source with Free-as-in-Beer downloadable compilers. IMHO worth at least investigating, even if you decide Microsoft's latest language-du-jour is more appropriate for your situation. YMMV, and COBOL, C++, Assembler, C#, Java or even VB might be better in your case. But worth a look.
Zoe Brain - Rocket Scientist
GnuCash does.
Any sufficiently advanced technology is indistinguishable from a rigged demo
--Andy Finkel (J. Klass?)
The Pentium FP bug was a hardware bug.
This depends upon where you think the bug was. The real bug was a problem with a loop in the code that described the division algorithm. When this code was compiled it generated an incorrect design that was used to create the hardware. In other words, it was a hardware bug caused by a software bug.
That makes it a software bug in my book.
Support SETI@home
Don't forget to mount a scratch monkey.
I'm sorry, I'm laughing hysterically at the phrase "...a US Patriot missile that caused 28 deaths because of accumulated floating point error". Sounds to me like the missile did exactly what it's designed to do - kill. The missile has no knowledge of who's side it's on, it just kills, maims, and destroys without conscience.
/dev
Does anyone else find an eerie similarity between the subject matter at hand and the old sequences on Square One in which shots of the commission of simple arithmetical errors were juxtaposed with engineering disaster footage and a voiceover saying something like "If this mistake hadn't been made...THIS wouldn't have happened"?
Below is a paragraph on page 113 in the book "Modern Structured Analysis" by Edward Yourdon.
"I don't trust goats," --To Catch a Spy
how can you get a "run time error [when] trying to compile the code" eh?
(you can't, run time is when the program is running, AFTER you've compiled it.)
Runtime errors that will boot you all the way out of a program are all over the place ESPECIALLY in vb where you can leave errors unhandled all over the place.
Dunno if VB.NET forces you to handle all exceptions or not but it'd be cool if it did.
See here
.
Not in depth theory, but an excellent explanation . .
himi
My very own DeCSS mirror.
the program should only do what it was designed to do, not more or less.
throw data at a program that it shouldn't get
Exactly. Otherwise it's like a boat that stays afloat only in a harbor on a calm day.
And a cracker's exploit of a buffer overflow is maybe the kindest way of experiencing the bug. If you don't think so, explore the consequences of a shipping clerk triggering the same bug on a production system. Horrible thought, but the "black hats" may be the only friends you've got in the business.
Near the bottom of the article it talks about the Pentium rounding errors again. But it lists the bug as belonging to the Pentium Pro and the Pentium II.
This was a problem with early pentiums, not pIIs!
I don't know if the pros had the problem or not. I wonder if anything else in the list is erronius.
And for the life of me when will programmers realize
that just because the software works on their
box it may not work on another machine.
Just installing Visual Studio,Source Safe etc, makes
testing useless on your main machine.
Program on your main machine.
Test on a clean machine.
Something is horribly broken here.
If you must develop and test for such an environment, you must test on both a clean machine and a machine with all the "goodies" loaded. It doesn't really work to tell a customer that he needs to get rid of all his other software, reinstall Windows, and load your software.
And no its not easy, you need to test against all combinations of wierd stuff to ensure that it will actually run.
You can protect your program against simple input errors.
I know this as the monkey test:
Put someone behind the keyboard (just pull a sales from the other end of the building). Let hime type/click away. He(/she) shouldn't be able to do read damage.
So does anyone here know how to "dereference the NULL pointer"?
Sure: (In plain C)
int *blah = NULL;
free (blah);
Say hello to General Protection Fault (in Winblows, @ least)
still offtopic, but...
You are right in a sense that you can "easily" set your own experiment which proves eatrh rotation (although I would go rather which biger pendulim than man-sized and repeat the "church pendulum " experiment. He cerpainly ment swirl convention in the atmosprhere as this is wrongly as a anologous to the "wrong" sink swirl.
Naturally he went for the atmospheric effect of the Coriolis Effect, but a few metre pendulum made heavy enough will show C effect, no doubt.
Here you are wrong: the influence of the wind is certainly much higher than the effect
Certainly it it, BUT the effect is taken into account in long range cannon aiming, just as the wind and other atmospheric efects (humidity, rain etc). Ranges with 10 miles and more the C effect is well present even for linear motion. You do the math. We are talking about metres here. You'd be supprised how accurate shoreline cannons are these days. (I'm not saying their accyracy is less than a metre, but because the coriolis effect is the easiest to take out it's usually done) Over here in the 60dgr nother latitude, the C effect is just about v * w (a_coriolis = 2 v x w, and with sin 60 being 0.5). Naturally angular velocity of earth is freakishly slow, but for example 10 km shot with 300m/s velocity it gives you an acceleration of 2cm/s^2, and for a 30 second flight it results in almost 10 metre deviation, which is right there in the same magnitude as the accuracy.
1 Earth is warming, 2 It's us, 3 it's royally bad, 4 we need to take action NOW
> In the old USSR (Stalin times), there was a standard bridge acceptance test:
> 1) put project managers, lead architects and engineers under the bridge;
> 2) put heavy loaded trucks on the bridge.
And where were the people who made the decisions?
For the Millennium bridge is was pretty complicated though, they had a whole Science Shack special on the BBC. The natural frequency of the bridge sway was close to that of human walking.
As the bridge swayed, people changed how they walked to compensate, so they were no longer walking as expected, or moddled, and instead of the various movements countering each other they were pushed in sync which made a feedback loop.
Its more complex than that, but they found out a bunch of new information about engineering bridges becuase of it. You cannot really blame them for not taking into account stuff that wasn't known.
Human effects on bridges is hardly a surprise. Recall in 1981 when the Kansas City Hyatt's skywalk collapsed, killing 114, because the pedestrians were dancing (and the design was altered to ease construction).
Actually this wasn't a "human effect" the walkways would have collapsed anyway, as built, simply due to the force of gravity. Since the bolts holding the upper walkway were taking the load of both. (Also the bolts were right through where two pieces of metal were welded together. Thw whole thing simply wasn't built as designed.)
The Millennium Bridge sway was due to people moving on it, it was, AFAIK, built according to the design. Just that the design was bad.
In the old USSR (Stalin times), there was a standard bridge acceptance test: 1) put project managers, lead architects and engineers under the bridge;
More recently a Moscow court sentanced an architect to live in a building he designed. Most likely this is a Russian, rather than Soviet, principle.
The mistake that caused the Hyatt disaster was not one of failing to consider human motion in the design, but failing to consider the effects of seemingly minor changes in design.
It certainly wasn't the first case where an apparently minor change made in construction caused a structure to collapse. Nor is it likely to be the last.
I have to argue the usage here, because while your argument holds logical merit, his usage was incorrect in this context. His entire sentence readThis usage is not right, since in this context, if he wants to indicate plurality he should use the plural form "softwares" (which is awkward itself, but it the only grammatically correct choice for this construct). He could reword the sentence "...software communicates properly" but as he used it, it's not proper communication, hence my detection of irony.
Virg
I am not expert in aerodymnamisc but in general the turbulences above wings increases the lifting forces but also drag forces so you increase the fuel consumption (you can see that during plane landing where for lower velocities the wings are reshaped)/
The purposes of flaps (and leading edge slats) is to lower the stalling speed and increase lift at low speed. Otherwise you'd need much longer runways. (Though probably not quite as long as that at the KSC).
Maybe I shouldn't post this, but...
Back in the DOS days, I thought it was good form to put in checks for things that shouldn't ever happen, but, if they did, there was no way to recover. The trouble was that sometimes they did happen, and then customers would complain about strange 'Internal Error' messages that made no sense.
So, I stopped putting in those checks, and just let the program crash, generally taking DOS with it. This was more familiar to the customers, and they'd just blame Microsoft.
Here's my favorite quote from the article: Even in a tub having a perfectly symmetric drain, the circulation direction will be primarily influenced by any residual currents in the bathtub left over from the time when it was filled. It can take more than a day for such residual currents to subside completely.
You should check out the residual air currents in my toilet.
They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.
My physics professor/boss was talking about how some of the fusion/fission experiments they run here have to use gigantic flywheels to gradually tap energy off of the power grid for rapid release, and somehow got on the topic of how MIT designed theirs to be safe -
They pointed them so that if the flywheels somehow broke, they'd go straight through the engineering/architecture offices. And the people that designed them, too. Now *that's* pressure.
hmmm.. it wasnt that the cable could support only half the tension, it was that the joints (those for the upper cable to upper walkway joint) had to take double the load.
:(
in original design joints for each level supported only the load of that level (only the roof joints supported entire weight). by splitting the rod and having 2 joints on the upper level, the upper cable to upper level joint had to support the weight of both the walkways - which it couldnt do.
I use Friend/Foe + mod-point modifiers as a karma/reputation system.
There is some good information on the Web about the Therac cases, one example of which is here:
http://courses.cs.vt.edu/~cs3604/lib/Therac_25/The rac_1.html
It turns out that the machine didn't simply "incorrectly calculate the amount of radiation" -- it was a design failure of a shielding subsystem that relied on microswitches and sensors for feedback. This sidebar explains it pretty well.
The last paragraph reads:
Sounds like a good case for hardware safeguards. "Sure, they cost more, but aren't you worth it?"
- MFN
"Slow down, Cowboy! It has been 3 years, 7 months and 26 days since you last successfully posted a comment."
Well, this does depend on how you define "disperse". It's unlikely that the fuel would be thrown all that far when the reactor remains hit the ground, but since a good portion of the shielding would have been peeled off by the fall, the resulting lump of slag would be (both in a radioactive and thermal sense) quite hot, so nobody could stay within a quarter mile of it safely. In a remote location in the Sahara desert, it wouldn't pose much of a threat, but if it fell in a New Jersey suburb, it could displace quite a few people.
Virg