Ten Technology Disasters 336
Ant writes "What do a 17th-century Swedish warship, an opulent Chicago theater and a Kansas City hotel "skyway" have in common? All met catastrophic ends and they have important lessons to teach today's innovators."
They forgot about number 11 (Score:3, Funny)
What about Texas City? (Score:2)
Re:What about Texas City? (Score:3, Interesting)
It's a good lengthy article. Worth the read
Re:What about Texas City? (Score:4, Insightful)
Firstly, that's not really what "heterodyne" means. Heterodyning is when you mix two signals to produce another at a different frequency. This is how pretty much all radio receivers work (yes, I know there are other ways. Go in a shop and buy a commercial super-regen radio, and I'll change that sentence). It's not a "glitch", it's more a constant physical property.
Also, the problem was not directly caused by the radio equipment, but by what was said. Yup, it's an unpopular view to take, but it was just plain human error. No blaming the machines here. Why? Well, it goes like this...
The day of the accident, there was very heavy fog around Tenerife. Visibility was extremely poor, and it was impossible to see the opposite end of the runway. Another factor was that normally, you only fly off from one end of the runway, depending on wind direction. If the surface winds are calm, it's the tower's call as to which runway is in use (denoted by the heading you're facing when taking off, in 10-degree steps, ie. Runway 25/Runway 07). *Both* runways were in use, so aircraft could line up at both holding points, to help reduce queueing.
Now, the Pan-Am pilot was first out, so lined up at the takeoff point, and began his takeoff run. There was some confusion about whether or not the KLM aircraft was to taxi from the hold to the takeoff point, due to both the controller and the Dutch pilot having english as a second language. This wouldn't have been a problem for the most part, because even if the KLM had been at the takeoff point, the Pan-Am would have cleared it with plenty room, even though it shouldn't have been on the runway.
The key is in what the Dutch pilot said - "We are now at takeoff". This is indeed a common phrase, generally meaning that the aircraft is sitting at the takeoff point and awaiting clearance. However, in Dutch, the prefix "at-" is equivalent to the English "-ing" suffix - the pilot had just effectively said "I am now taking off". It's an easy mistake to make if you speak more than one language. Even a language you don't often use creeps into things you say in your first language. Just watch it doesn't have consequences this serious!
Re:What about Texas City? (Score:2)
Thanks for the description. This story may be behind why I've never once heard "We're at takeoff" at major airports in many years. I've always heard the tower instruction as "taxi into position and hold" with the instruction repeated by the pilot. I guess because of this incident, they like to stay away from the word "takeoff" unless its an instruction to actually head down the runway. Interesting.
or Halifax. (Score:5, Interesting)
or Texas City (Score:3, Interesting)
There are some pictures [texas-city-tx.org] on this page. It seems that over 600 people died; or at least they recovered that many bodies. There may have been some who simply disappeared. There was a tidal wave which swept 150 feet inland (NOT 150 feet high, but that far away from the beach.). Since the ship was at the dock, it started fires in the town, and at a chemical plant near the docks. It set fire to another ship which was nearby. That ship blew up the next morning with even more force, and did even more damage. There are more pictures here [chron.com] and here [chron.com], which give some idea of just how big ithe explosions were.
Re:or Halifax. (Score:2)
Being stuck in a burning building with exits blocked is a far cry from a couple of fireballs here and there. Just use your legs and walk away from it.
Re:What about Texas City? (Score:2)
disasters course (Score:2, Interesting)
Supposedly this engenders a greater sense of responsibility into the engineers to be. I think it worked it for me
Websurfing done Right! StumbleUpon [stumbleupon.com]
Re:disasters course (Score:4, Funny)
> has a disasters course as one of the non-technical electives.
...
> Supposedly this engenders a greater sense of responsibility into the
> engineers to be.
Perhaps, then, this should be a required class instead of an elective one. *shrug*
Bhopal? (Score:2, Redundant)
Re:Bhopal? (Score:2)
"In assembling this list of exemplary technological disasters, we've omitted the most familiar--those whose names have entered into the language, like Bhopal, Chernobyl, Three Mile Island, Titanic and Challenger--in favor of some with fresher tales to tell and lessons to impart."
Re:Bhopal? (Score:2)
"In assembling this list of exemplary technological disasters, we've omitted the most familiar--those whose names have entered into the language, like Bhopal, Chernobyl, Three Mile Island, Titanic and Challenger--in favor of some with fresher tales to tell and lessons to impart."
What a shameless and pathetic attempt at karma whoring...
Concorde? (Score:4, Interesting)
Disclaimer: I know nothing about airplane safety or testing, but this one set off my common sense alarm.
So, the tires on Concordes require to be changed alot - a chunk of titanium breaks of of another plane, and hits a tire on a Concorde, causing the accident - anyone else think that "Well gee, I don't think any kind of tire is designed to withstand titanium chunks slamming into them." Considering the condition of some of the commercial jets I've flown in, I'll take my chances with the Concorde. I'm sure there is more to it than just this, I thought it odd though.
Though not a "disaster" per se - the Navy's dead Windows NT ship is tops for the funniest in my book.
Navy's Dead ship (Score:5, Informative)
From the article And a little bit later in the article
GO ARMY!!!!!!!
Re:Navy's Dead ship (Score:3, Insightful)
Re:Navy's Dead ship (Score:2)
Re:Navy's Dead ship (Score:2)
Or did I miss something?
Re:Navy's Dead ship (Score:2)
Re:Navy's Dead ship (Score:2, Insightful)
http://www.sciam.com/1998/1198issue/1198techbus2.
Also, the publisher of the original GCN article backed away from the article a little characterizing some of the content as "early speculation" or something like that.
Re:Navy's Dead ship (Score:2)
Well, at least that way the ship was paid for ;-)
Re:Navy's Dead ship (Score:2)
Yes, but the operating system (Windows NT) should have caught a divide by zero exception, and terminated/restarted the offending application. The operator should have then been able to restart the application and proceed as normal. This bug should not have brought down the entire system!
Eng. on board and Devel. say it was not NT (Score:4, Insightful)
"Others insist that NT was not the culprit. According to Lieutenant Commander Roderick Fraser, who was the chief engineer on board the ship at the time of the incident, the fault was with certain applications that were developed by CAE Electronics in Leesburg, Va. As Harvey McKelvey, former director of navy programs for CAE, admits, "If you want to put a stick in anybody's eye, it should be in ours." But McKelvey adds that the crash would not have happened if the navy had been using a production version of the CAE software, which he asserts has safeguards to prevent the type of failure that occurred."
Re:Navy's Dead ship (Score:2)
What kind of calculator have they been using? All the ones I've seen give you 'E' and refuse to do anything until you clear it.
Re:Concorde? (Score:3, Interesting)
On the other hand, the failure in this case required 2 failures on the Concorde and bad luck with the fire, as well as hitting something that shouldn't have been there. There's a reason it took as long as it did for a Concorde to crash. I'm not sure exactly why this is in the list: in the other cases, the problem was that the makers were over-confident. The Concorde was supposed to be nearly indestructible, and it turned out that it could be destroyed once in a million times. So they fixed both of the things which contributed to that time. It's not the sort of thing you could say was just waiting to happen, or that you could say they should have found in simulation or testing.
funny? (Score:5, Interesting)
the Navy's dead Windows NT ship is tops for the funniest in my book.
Many psychologists have suggested that the emotion of humor has evolved as expressing relief from danger.
I find it truly frightening.
Breaking a few eggs and all that... (Score:3, Insightful)
Re:Breaking a few eggs and all that... (Score:2, Funny)
No, but I'm sure we could find a way to make reproduction much less intuitive. If we had the source code, that is.
Re:Breaking a few eggs and all that... (Score:2)
Carry through is important! (Score:4, Interesting)
Next time as a programmer you bitch about checking up on QA (assuming you are lucky to have a QA department) or on the users, just remember that your mistakes very rarely kill people. You've got it _easy_.
Also, on a side note, the local KC TV news organizations try hard to prevent people from getting to their archives of what happened. They don't want to present Kansas City in a "bad light". This is also very stupid. If we can't easily learn from our mistakes we are going to make more of them. 'Protecting' KC's reputation just makes Kansas Citians look more retarded than the screwup that was Hyatt Regency Skywalks.
Re:Carry through is important! (Score:4, Informative)
I lived in KC at the time, and I recall that there were more screw-ups than this short summery mentioned. The metal fabricator also changed the design of the beams. As designed, they were to be made of two "U" shaped channels welded together with a seam on the left and right sides of the beam. They didn't have those bits in stock, so they used two shallower "U" shaped pieces and welded them together at the top and bottom of the beam...and then drilled the holes for the threaded rod right through the welds!
Everyone involved was criminally culpable...and (to my knowledge) went to prison.
A good friend of mine was the first emergency physician on the scene at the Hyatt and performed the triage. He was recently interviewed by the BBC for a documentary about the Hyatt. They supplied footage to the BBC, but no...they don't have any reason to supply footage to random people.
Re:Carry through is important! (Score:4, Informative)
Teach me to actually re-read the thing when I preview it. What I meant to say was:
Everyone involved was criminally culpable...and (to my knowledge) *NOBODY* went to prison.
They were called 'skyWALKs' for a reason (Score:2)
They were designed for people to walk from one side to the other, perhaps to pause and
check out the view for a few moments before continuing on their way, but not for a huge
crowd to fill them, swaying in unison in rhythm to the music. I have a great deal of sympathy
for the people on the lower skywalk and those underneath them both, but the ones on the
upper skywalk contributed to their own injuries. I never saw any acknowledgment of this
distinction.
Re:They were called 'skyWALKs' for a reason (Score:2)
Read the article. It specifically says that dancing induced resonance was ruled out pretty early as an explanation for the disaster:
Re:Carry through is important! (Score:3, Interesting)
By admitting any wrong doing people can open themselves up to enormous lawsuits, that's whay many times teh injured parties or those seeking redress often have to seek the truth on their own with little to no assistance on the accused. Look at Enron and Andersen for a godo example of this.
The Enron and Andersen officials aren't being unhelpful because they want to be a pain in the ass, they are being inhelpful because they risk jailtime and possibly enormous fines. By not admitting to anything the jobis that much tougher to bring civil and/or criminal charges against them.
Like it or not, it's unconstitutional to force people to incriminate themselves.
Well, I read it, and I can't see any patterns... (Score:3, Insightful)
Am I missing something?
Yeah, sure "Don't cut corners" and "Don't trust management who would like to cut corners", but that's pretty obvious and we all still do it, right?
There's also some stuff like "Watch when retrofitting parts of an old system with new technology" and "pay attention to boundry conditions", but really I think this is just a laundry list.
So does anybody know of a good reference work out there which actually has some worthwhile analysis on stuff like this? Didn't Feynmann write something up after Challenger?
Re:Well, I read it, and I can't see any patterns.. (Score:5, Informative)
Yes, it appeared as an appendix to the Roger's Report. He also discussed it in his autobigraphy either "Surely your joking..." or "What do you care...", I can't remember which. The appendix is a good read, and can be found here:
http://www.ralentz.com/old/space/feynman-r
or any of a number of other googleable links.
Re:Well, I read it, and I can't see any patterns.. (Score:2)
Re:Well, I read it, and I can't see any patterns.. (Score:2)
You can read his lectures online [onlineethics.org]
Three Mile Island, Chernobyl. Is Tennessee next? (Score:3, Interesting)
Tennessee is just about to do something similar with a
nuclear power plant. [nytimes.com] This plant has been mothballed since 1985 but they want to bring it back online. Oh yeah, they also want to overclock it by 30%; it was originally designed for 1000 megawatts production but they are going to crank it up to 1300 megawatts.
The plant had caught fire in 1975, causing a series of problems leading to the shutdown in 1985. Now they want to extend it's orginal 40 year design for another 20 years. A nuclear-safety engineer for the Union of Concerned Scientists figures that a new plant would be safer and cheaper. From an engineering point of view, "It's like trying to dust off an eight-track tape player rather than buying a DVD system..."
First Three Mile Island. Then Chernobyl. Is Tennessee next?
Re:Three Mile Island, Chernobyl. Is Tennessee next (Score:5, Interesting)
> First Three Mile Island. Then Chernobyl. Is Tennessee next?
Sorry, Tennessee would have to get in line. One of the most spectacular examples of stupidity causing a nuclear accident was at a plant in Tokai-mura on September 30th 1999, and it is the greatest nuclear plant accident in Japan's history. Basically, they dumped all the safety precautions and mixed themselves up a batch of acidic nuclear soup in a big steel bucket and stirred. Instant hot fission! You can read the World Nuclear Association's writeup here (it has a nifty table of different levels of nuclear catastrophe that is a must read):
http://www.world-nuclear.org/info/inf37print.ht
The interesting thing is, Toho was filming on location at the Tokai plants for a Godzilla attack in the then upcoming "Godzilla 2000 Millenium". They were probably done with filming by the time the accident actually occured. In December 1999, the movie opened, with Godzilla heading over to attack the plants.
This wasn't the first one of Toho's monster movies to "come true", only one in a long history. Here are two other famous ones:
"Gojira" 1984: the Russians have a nuclear accident in the movie (in the original Japanese version, US version makes it a deliberate act). In 1986, the Russians had a real accident: Chernobyl.
"Mosura 3: King Ghidora Raisu" 1998: the King of Terror (King Ghidora) begins his attack on Tokyo by flying through the twin towers of a skyscraper. Office workers flee while talking on cell phones. The US version
Sonora:"New Godzilla reading. He's moving inward toward Tokai."
Shinoda: "The nuclear plants, I knew it.
Sonora: "Afraid so."
Yuki: "Well, that's just lovely. Another Chernobyl."
"Godzilla 2000" (US version dialog)
Re:Three Mile Island, Chernobyl. Is Tennessee next (Score:2)
What about Banqiao and Shimantan dams (Score:5, Informative)
I mean, not only was this the greatest technological disaster in human history with 80,000 to 230,000 dead depending on whose numbers you believe, but it also is sufficiently unknown that the author of an article on disasters doesn't appear to know of it!
Re:What about Banqiao and Shimantan dams (Score:5, Informative)
Since the original post mentioned this as if we should be familiar with it, here're [sjsu.edu] the details: A big dam in China failed, in large part because the Communist ideologues over-ruled the hydrologists. Many thousands died, but of course that's all right because the houses of the Party cadre were built on high ground. Click on that link for the fine print.
Re:What about Banqiao and Shimantan dams (Score:2)
For that matter, do you have any more information on it? I've never heard of this one either.
RISKS - assesment community (Score:5, Informative)
Every engineer should spend time reading there. Any _good_ engineer should subscribe.
-David
Re:RISKS - assesment community (Score:2)
http://catless.ncl.ac.uk/Risks/12.44.html#subj7
The RISKS digest has a lot of good material. Like any journal, mailing list, bulletin site, etc... that allows opinon there are going to be things that you might not agree with. I'll admit that that particular article wasn't one of the highlights of the list. The author does have good points, however. OSS is generally NOT put up to the same design methodology or testing standards as the software running on a Boeing 777. There is a big difference from using a Linux workstation to handin a CS assignment (upon which my life does not depend) and having Linux make sure flaps still work. After all, you aren't going to download and install the latest kernel patch for your flaps between takeoff and landing.
Re:RISKS - assesment community (Score:2)
No non-embedded software is, open-source or not. They slam GNU for "pretty much ignoring the
need for competence and expertise on the part of software developers", but tests on GNU utilities in 1990, 1995 and 2001 showed them to be more reliable than the equivelent utilities that come with Solaris. I won't praise the quality of all free software, but often ego and sufficent time to get it right beats the heck out of money and short deadlines.
Re:RISKS - assesment community (Score:2)
knowns
unknowns
unknown unknowns.
It's pretty hard to get competence and expertise for the "unk-unk"s.
Feed a GNU utility something you shouldn't be feeding it and if it barfs the wrong way, fix the utility so it doesn't go ape over small problems.
Re:RISKS - assesment community (Score:2)
That's probably because it's the ACM Forum On Risks To The Public In Computers And Related Systems. That's ACM, as in Association for Computing Machinery. So, yeah, it's a little computer slanted.
But the mention of RISKS is appropriate in relation to this article, as computers are (well duh) prevalent components of many currently emerging systems, and thus future technology disasters are increasingly likely to be computer-related failures.
--Jim
K-Boat (Score:3, Insightful)
See http://www.brisray.co.uk/misc/mind.htm [brisray.co.uk] (scroll down) for more info.
Re:K-Boat (Score:2)
Imagine a closed-cycle internal combustion engine with a big oxygen tank nearby--one oxygen leak and if a fire breaks out the result would be a horrible disaster. In fact, that's exactly what happened in (I believe) 1956 when a large number of submarine crew was killed by fire onboard such a sub, and there would have been much more deaths had not the captain got the sub surfaced and managed to get a number of crewmen off the sub.
When the corporation goes unregulated... (Score:5, Insightful)
The lowest bidder cannot be trusted to create products that are safe.
In these cases, it is good to still have some government oversight.
Re:When the corporation goes unregulated... (Score:2)
"the lowest bidder cannot be trusted to create products that are safe."
Crap! If the lowest bid is for an unsafe product, then it isn't a bid for the project... If someone accepts a bid for what is essentially something other than the project for which they requested bids (i.e., an unsafe version of the goal) then they are foolish; corporations running amuck have nothing to do with it.
It's easy to associate low price = low quality, but that simply is too simple. After all, many of the greatest foulups are when a nonlow bid is chosen for 'political' reasons.
Forget Ye Not the Therac-25 (Score:5, Informative)
Even if you never get near embedded systems of this type, you can't call yourself a responsible software engineer until you read and learn from An Investigation of the Therac-25 Accidents [vt.edu].
Executive Summary: Company introduces next-generation radiation therapy machine, replacing hardware-based overdosage safety interlocks with software-based mechanisms. Software fails. People are killed.
Schwab
Re:Forget Ye Not the Therac-25 (Score:2)
Because... (Score:2)
No Common Thread...but... (Score:5, Interesting)
Usually, the problem is
(a) Pushing Envelope without prior analysis (Vasa)
(b) Not exercising Due Diligence in design (Tacoma Narrows)
(c) Failure of communication between departments (Mars Climate Orbiter : remember the units SNAFU?)
(d) Insufficent redundancy design (Iroquis Fire)
(e) Failure to recognize likely failure modes (Concorde, Titanic)
and others of course.
I've once fucked up an expensive spacecraft component because of (c). I worked on the mechanical design of the component housing, some electronics guy worked on the electronics detector sitting inside my housing. We have an innovative design whereby some of my mechanical supports were designed to keep some of his electronics ICs in place without the PCB board. The SNAFU : both of us thought the other is suppose to apply anti-vibration gell (layman's term here, we call it RTD...).
So the part was fab-ed, electronics put in, and the whole thing was sent to a vibration table for testing..
Result : a loose IC, clanking around the housing for 2 minutes at about 600Hz. The whole thing was toast.
Re:No Common Thread...but... (Score:2)
Re:No Common Thread...but... (Score:2)
Re:No Common Thread...but... (Score:4, Insightful)
Another problem I have seen was where TWO different bugs mostly functionally cancelled each other out causing new intermittent problems.
I made a realization regarding strict-type checking languages versus dynamic typed languages.
Typically, people who are used to java and c++ complain about languages like python - saying that the compiler should catch static type problems at compile time and that languages that do not do this are inherently unsafe.
Then I realized that ALL of these people must not be running any real tests on their code! If they were running real tests on all your code (every line must be executed in your tests), then these dynamic typing errors would be easily caught ! those would be the easiest bugs to find.
Too often I have seen C and C++ coders compile their project.... No errors! Ship it!
Another issue I have been thinking about is the relationship between code reuse and unexpected behaviours. Code reuse (and object class reuse) is fine as long as all of the functionality and limitations of the object/code are known.
However for more complex class hierarchies I have seen people say '"I'll just inherit from this class publicly and change the public interface to match what I need for this project." - And then they are surprised when other pre-written code interacts funny with it. I'm not saying object-oriented is bad - I'm saying it is so common for programmers to break the basic concepts of OOP.
I had one manager who was adamant that for any medium sized project there ought to be NO time spent on making the code re-usable. Every line of code should be directly related to specific aspects of the customer's requirements/specification document. At first I thought he was crazy.
But after I saw some projects expand into massive class hierarchies just for the sake of the illusion of increasing the reusability of the code in other projects, I am starting to side with him a bit more.
Extreme Programming has at least some very good points about it. ie: don't add features until you know you need them. Otherwise they probably won't be tested properly and won't be a good match for the new use. You can't predict every environment that the code may be reused in. It is harder to do than it sounds.
So for high reliability systems I think one should have simple non abstracted code that can be measured, prodded, and always predictable. Then you can fashion your unit tests accordingly.
--jeff++
P.S.: scary thought/rant for today: How much C++ code do you see that is striving to be exception safe so that memory full errors will be caught properly? How many C++ coders understand that the default linux kernels and libraries will almost NEVER cause malloc() to return 0 and will almost NEVER cause operator new() to throw? Only virtual memory space is allocated. Real memory pages are only allocated as they are being used. Once all physical and swap pages are used, blammo goes your app (and possibly other apps on your system). In semi-critical systems, this is a real problem that is often overlooked.
Where is the real problem in this case? Part of the problem is that the c++ environment running on the default linux kernel does not conform to the standard.
The other part of the problem is that it is little known. If it were commonly known, people would be able to design around it (or change the kernel options). So people rely on what the documentation says, instead of properly testing the software limits.
massive class hierarchies (Score:2)
Crazy guys give good advice. (Score:3, Interesting)
I had a guy who thought dynamic memory allocation should be avoided at all costs, and you should never use a data structure more complex than an array.
I still think he's crazy, but now I see his point. I mean, he was terrible for global variables and giant functions, but his programs never leaked memory and very rarely wrote to bad pointers. If you don't need dynamic memory allocation, you shouldn't use it, and when you do need it, you should only have one malloc and one free (or equivalent) for every dynamic data structure. Often, you only need one or two, even in a relatively large and featureful program. That way, I can write a good page of error handling code and comments on memory consumption for each dynamic memory access, and it saves me a lot of grief.
I don't like reusing code, either, unless you can make a good case for it being a part of the underlying system. I like the analogy of an architect stapling someone else's blueprint of a fully-equipped foundry and machine shop to his design because the inhabitants will need a screwdriver. Reuse means bloat, and bloat is bad. Every extra line you add is another place for a bug to hide.
Re:No Common Thread...but... (Score:2)
There's no substitute for going over all of your code and going "Yup, yup, yup, yup...." Strict typechecking eliminates one type of error, automatic garbage collection eliminates another type of error (double free and mem leaks). But these assume you know what you're doing. If in Java you keep all objects global, persistent and available then you are in effect disabling the garbage collector. That's why it's always best to start with C++ and move to Java, because then you know that these additional limited safety checks are just that and not "divine intervention - computer takes care of it". Jackasses still won't be able to program in Java because "it puts you in a padded room."
When a good coder codes, he'll think, "Yeah, the line I've just written should give a compile error, let's just check... <compile>... Error. Yup as I expected. Perl taint should throw an exception at this line... Yup."
Re:No Common Thread...but... (Score:2)
I saw the Vasa in its museum the other week in Stockholm - they retrieved the ship from the bottom of the harbour and it is now on display, with very interesting exhibits about how it was built. Worth a visit if you are ever in Stockholm.
Re:No Common Thread...but... (Score:2, Interesting)
So some gel is supposed to hold the thing together? I hope it was a vcr or something and not a jumbo jet.
Tacoma Narrows (Score:2)
Re:Tacoma Narrows (Score:2)
Re:Tacoma Narrows (Score:2)
But in fact, I don't believe anybody was killed or injured, making it trivial compared to many other bridge collapses and disasters. The bridge was new so it didn't even disrupt life that much. It's an an interesting failure and a cool film, but was not a disaster nor is it unknown.
Things that are much greater omissions include things in this thread, like Halifax, the Chinese dams, Tenerife etc.
Digiscents (Score:2)
At least the air freshener industry would benefit for the next 20 years as we attempt to de-stink the world
Also in the dead-tree magazine (Score:2)
Challenger? (Score:2)
Re:Challenger? (Score:2)
-Restil
Concorde (Score:3, Interesting)
For me, an aerospace buff, that crash was as big as the Challenger.
I remeber when the transcripts from the Concorde crash were released, it was really chilling, thinking about those pilots, knowing something bad is happening, and trying with all thier might to abort to Le Bourget, and that big Delta is stalling and Christian Marty can only say "Too late".
Good summary (Score:3, Insightful)
- Admiral Hyman G. Rickover
Every software project by UK government (Score:2)
Phillip.
DMCA (Score:2, Insightful)
I could think of a few more... (Score:2)
Saw a rather interesting documentary on the Triangle Shirt Waist Factory fire in New York (I think) near the turn of the century.. Essentially, a sweat shop went up in flames, and the owners had padlocked all the emergency exits. Whoever didnt burn to death plunged to the ground below, diving out of windows.
A couple people have probably mentioned the Hindenburg. The Hindenburg didnt crash because of sabotage, because of any engineering errors, or even because it was filled with hydrogen. Neither one of those are valid reasons, especially the hydrogen thoery. The hydrogen gas inside the blimp was doped with a substance that smelled like garlic, so the engineers and crew could smell hydrogen leaks if they occured. None were reported. A blimp like the Hindenburg contained pure hydrogen. Pure hydrogen by itself is NOT flammable -- An adequate mix of hydrogen and oxygen inside the ship would have been needed in order for it to ignite, and that mixture wasnt present. Besides, the footage of the accident clearly shows that there was no explosion -- It was only the outer skin that caught fire. The outer skin of the Hindenburg was coated with a combination paint and sealant that was both highly flammable, AND electrically conductive -- The prevailing theory on why the Hindenburg crashed is that the blimp collected so much static electricity during its descent into New Jersey (in a brief window inbetween thunderstorms, even..) that the charge eventually arc'ed, and ignited the outer skin of the craft. The Hindenburg crashed to earth not because of fire, but because of hydrogen loss.....all because of a poorly chosen paintjob, oddly enough..
Cheers,
Well mod me down and call me karmawhore (Score:3, Funny)
That's like Windows, right?
Re:Well mod me down and call me karmawhore (Score:3, Funny)
MS Outlook (Score:2, Flamebait)
Vasa (Score:2)
It's now a massive visitor attraction. However, that's not without its own unfortunate side effects: I heard a report a few week back on the BBC that the wood is now rotting again in places due to the humidy in the air from the visitors' breath, perspiration, damp outer clothes on rainy days, etc.
More information at the Vasa Museum [vasamuseet.se].
The Swedish ship was recovered... (Score:2)
What About /. (Score:3, Funny)
Re:From a luddite point of view: (Score:3, Funny)
graspee
Re:From a luddite point of view: (Score:2)
Re:From a luddite point of view: (Score:2)
Zeppelins were certainly used as bombers in WWI.
Re:Darth Cliffy said so. (Score:2)
...or animals!
Re:From a luddite point of view: (Score:2)
Re:haven't read it yet (Score:3)
You mean the Tacoma Narrows Bridge collapse? Didn't make the list, though it certainly could have. That's still one of my favorites - I always thought of concrete as an inflexible material until I saw that footage.
I saw another example one time in the 1980's: an NFL football game where the fans at... I think it was Buffalo... were stamping their feet in unison and the upper deck of the stadium was oscillating up and down with an amplitude of a couple of feet (as compared to the stationary points of reference beneath the deck). It was a bit scary when they showed it on TV - I was afraid I was about to see a stadium collapse on live TV. Fortunately, the only thing that collapsed was the Bills, and the fans soon stopped their rowdy and dangerous behavior.
--Jim
Re:haven't read it yet (Score:2)
Re:haven't read it yet (Score:2)
Not really. Engineers have learned from it, and build much more dampening in bridges now. They won't resonate as much anymore.
Re:haven't read it yet (Score:2)
There is one bridge on the list [techreview.com]
Re:haven't read it yet (Score:2)
Re:AT&T: missing break statement (Score:2)
Re:AT&T: missing break statement (Score:2)
Why? Only because the creators of C chose it to be. There are many other languages - pretty much every non-C based descendent of Algol - where case labels are clearly control statements and clearly end the block.
Re:AT&T: missing break statement (Score:3, Insightful)
Example:
case ch of
'A': WriteLN('Choice capital A');
'B'..'Z', 'a'..'z': WriteLN('Another letter');
else WriteLN('default case');
end;
Re:Power failures? (Score:2)
Re:The Greatest Disaster Ever In History (Score:2)
--jeff++