Slashdot Mirror

It is correct to assume that a disclaimer, or a warning, or a "terms of
agreement" document such as is commonly found in software packages, is no
protection against a lawsuit or a judgment against the developer. It is up to
a judge or jury to decide whether the warning was adequate, whether it was
relevant to the damages, and even whether it was presented to the user in a way
that was likely to have actually "warned" the consumer about the use which
produced the damages.

It is correct to assume that a disclaimer, or a warning, or a "terms of
agreement" document such as is commonly found in software packages, is no
protection against a lawsuit or a judgment against the developer. It is up to
a judge or jury to decide whether the warning was adequate, whether it was
relevant to the damages, and even whether it was presented to the user in a way
that was likely to have actually "warned" the consumer about the use which
produced the damages.

Sadly, this is nothing new.

Every software developer needs to read Peter Neuman's book Computer-Related Risks , and keep up with the Risks digest (comp.risks).

Learning from other's mistakes is much less painful.

There was a good discussion of this event some months ago; the current issue has blurbs on topics ranging from computer viruses to aircraft cockpit management.

There was a good discussion of this event some months ago; the current issue has blurbs on topics ranging from computer viruses to aircraft cockpit management.

This report is mistaken. The first large-scale spamming of Usenet preceeded this one by nearly two months. I remember it well, as I used Usenet pretty heavily at the time.

It wasn't lawyers hawking green cards who really got the ball rolling. It was a religious nut warning us all about the end of the world. On January 17, 1994, Clarence L. Thomas IV (not the Supreme Court guy) spammed all known Usenet groups with a message titled Global Alert For All: Jesus is Coming Soon .

You can see the original message in Google's archives. And you can read about some of the after-effects in RISKS 15.49, from February 1994.

Canter & Siegel, the green card spammers, certainly earned their awful reputation. But they were only ripping off someone else's idea.

See my site on the issue in Canada, including international reports: Paper Vote Canada.

Actually there are two possible types of ad hominem one of them is valid and the other is a fallacy.

A valid ad hominem occurs when a protagonist has made a statement of the type "I am an X and therefore my experience allows me to state Y", to which the valid response is "You are a flawed X in some manner and therefore you can't state Y".

An invalid ad hominem would occur if the respondent were to counter instead with "You are a flawed Z (where Z has no relationship to X at all) and therefore can't state Y".

See this link for a better description.

There is an element of valid ad hominem in the response to ESR when it is said that ESR is "out of touch". The truth of this is arguable, but the form of the argument is a valid ad hominem.

I'm amazed you convinced BMW of the problem, like you said, not only did it required high temperature, but reformulated fuel for a few tanks AND a different firmware version. It also points to the dangers or risks in safety software that self-learns (and the firmware in the Mini definitely counts in my book as safety-critical).

Digressing...
At the same time, I wouldn't be surprised if the company that made the firmware also supplies other companies. The car industry is funny that way, they're quite happy to have a wiper supplier provide to both BMW and Ford subtly different versions.

Well, when I looked at this recent article on electronic copyrights in the most recent RISKS digest I was reminded of the Ellison story.

The author of this article objected because the stolen version was corrupted, and, in his opinion, inferior, to his original. And additionally because his original was unattributed.

A consumer OS (linux is a consumer OS, BTW) should NOT be controlling fly-by-wire... human life is at risk.

So a non-consumer OS should be used?

Here is an example of custom software causing a crash.

With aircraft systems becopming more and more complex, it does give one pause as to what could happen if there was a "blue screen" or "kernal panic".

IMHO, it doesn't matter what software is used. If it is engineered poorly, it will perform poorly. One would hope that any critical system that relies on software would "fail gracefully", but with budget pressures on a project anything can happen.

A well-tested "consumer" OS can be a lot better than completely untested custom software.

Poor software, like poor concrete, will crumble, no matter where it comes from.

Be careful what you wish for!

Just to be clear, the pilot (actually, the Captain) Michel Asseline lived. He was convicted of manslaughter and sentenced to prison, but it is unclear whether he served any time. January 30, 1990 Risks Digests indicates he lost his French Pilot's license for 8 years and was flying in Australia at the time (1/30/90).

It also looks like he saw a UFO in 1975 (Google Translation)

See Re:Traditional Boeing vs. Airbus debate for links to the accident reports. There is some controversy over whether someone tampered with the black boxes.

I tried to determine if Michel Asseline was ever a test pilot, but did not find evidence of that. Googling for michel asseline "test pilot" results in 3 hits, only one of which is relevant, which leads to http://www.geocities.com/landroval.geo/airbus-j.ht ml, which is not found, but the Google Cache says:

COLMAR, France, March 14 (Reuter) - A French court on Friday sentenced the pilot of an Airbus airliner which crashed at a 1988 air show, killing three people, to six months jail for manslaughter with another 12 months suspended.

The verdict vindicated Airbus Industrie , the plane's makers, blaming human error and irresponsibility by operators Air France for the disaster.

The Air France A320 ploughed into a forest and exploded into flames on June 26 1988 after a very low altitude pass over an airfield at Habsheim, near the eastern city of Mulhouse, killing three of the 130 passengers.

At the trial, pilot Michel Asseline blamed the cockpit computer displays and said the flight recorders had been tampered with. But the prosecution said he and co-pilot Pierre Mazieres had recklessly endangered the passengers' lives.

Mazieres was given a one-year suspended sentence.

The prosecutor called Asseline ``a reckless daredevil who tried to prove out of pride he was as good as a test pilot''.

The defence failed to show that the flight data and voice recorders had been rigged. Experts testified that the plane crashed because it was pushed beyond its mechanical limits.

Three other officials, including Air France's director of flight operations at the time, the state-owned airline's then security director and the organiser of the air show, received suspended prison terms of six months or less.

Asseline and Mazieres declined to comment on the judgment or say whether they planned an appeal as they left the court.

Air France was declared liable for the accident and ordered to pay undisclosed damages to victims of the crash.

The prosecution said Air France had regularly run low-altitude demonstration flights with passengers aboard in violation of civil aviation regulations.

``Airlines should be transporters, not circus performers,'' expert witness Michel Bourgeois told the court.

Jean-Claude Boetsch, a spokesman for an association representing victims and their families, said he thought the sentences were misguided and too heavy.

``As far as the court is concerned, the verdict is clear and the case has been proven, but in our view there is no proof. The plane is still partially in question, but the stakes are so high that they preferred to make one man pay rather than the system,'' Boetsch said.

The association supported the pilots' accusations of a shortcoming in the aircraf

When you get right down to it, this idea has some fundamental problems. Would I fly on such a a plane equipped with a system that could over-ride the pilot no matter what? Probably not.

In fact, once you have something like this, why bother with pilots at all? Obviously, the've been declared redundant and useless.

When you get right down to it, this idea has some fundamental problems. Would I fly on such a a plane equipped with a system that could over-ride the pilot no matter what? Probably not.

In fact, once you have something like this, why bother with pilots at all? Obviously, the've been declared redundant and useless.

Be smart, and play it safe. Use a 5, or better yet, 10 digit year. What's a few bytes?

So maybe I'm an April Fool, but it seems to me that the Y10K issue is worth a little serious thought.

There are areas of human endeavor in which 8000 years is not an extreme time span. At present, we deal with these long time spans only in modeling things like geological and cosmological events. But it is not unreasonable that within the next century, we may begin to build very high technology systems with mission durations of thousands of years - for example, a system to contain radioactive wastes, or a probe to another star system.

Y2K issues have raised our consciousness about timer overflows, but it's quite possible that this may fade in succeeding generations. There's no reason not to start setting standards now.

Perhaps all time counters should be bignums?

Propenents of Open Source solutions for electronic voting systems should be concerned about this. I see no mention of this at Boxer's website, so it's hard to say exactly how this might be worded. But clearly, the process of performing and verifying such a vetting could be problematic for a distributed, volunteer development effort. Would it be just the "official" maintainers who would be subject to such constraints, or would such requirements require that patches submitted by non-vetted contributors be rejected purely on those grounds? My concern is that voting software should be evaluated and put into use on technical grounds, and in the pursuit of using the best available methods, we shouldn't be placing barriers into place which preclude the selection of well-written software.

Diebold's attitudes toward their voting machines make me wonder about their ATMs

Keyboards that occasionally type "www.belkin.com" when they detect you're typing a URL.

You laugh, but what about the welcome datacomp case of this keyboard?

You seem to like spamcop reports and have entertained the thought of automatically banning people by parsing the spam reports you receive. This should be treated with a great deal of caution unless you want to be responsible for fiascos like this or this.

Relying upon some of the kooks who use spamcop to make the determination as to which of your users should be "killed" is not wise and I think your management has made the right decision. Certainly automating the process of sorting the complaints into wheat or chaff and cross referencing them to user accounts is worthwhile, but this should be an aid to human review and not an end in itself.

Having scripts which automatically hit the kill button is open to abuse - so it will be abused.

Well specified, straightforward, easy to get right, user interfaces for medical devices might be a better idea.

Here are the programs you need to have a k-133t windows system.

1. AOL- DUH, they are the greatest ISP ever.

2. Webshots - Impress your friends with your changing wallpaper!

3. Hotbar - Skin Internet Explorer and Impress your friends!

4. AOHell This program will make you l33t!

5. Incredimail This makes your e-mail look k00lah then everyone elses.

6. Microsoft Outlook because all the anti-virus tools work with it. You don't want to use another e-mail client, you might get a virus!

7. Comet Cursor. Makes your cursor R0x0r.

8. Intruder Alert 99 You need a firewall, the internet isn't a safe place!

9. Gator Gator is an awesome program that helps u remember ur passwords. This way u don't have to fill out stupid forms!

10. BO Server The guys in my gaming clan sent me this, they said it would improve my FPS, and make windows run faster. I think it did!

Sorry, forgot the link. (So sue me!)

On the expansion of substances, true, liquids and solids expand little compared with gases, but the rate of expansion with temperature for solids that make up the earth's crust are about two orders of magnitude less than that of water. And given the average ocean depth of about 3800 meters, only a small amount of expansion is necessary to raise the sea levels by a noticable amount. I confess that it never occurred to me to take into account the affect of the expansion of the earth's crust, but since below 100 ft or so its pretty much determined by the heating from the core, and it's rate of thermal expansion it negligible compared to water it wouldn't seem to be a significant factor. (A correction, the link in my OP was posted with a space, so I give it again here. Also, I referred to the bulk modulus and I should have said the coefficient of thermal expansion, which is related to the dependence of the modulus on temperature.)

I agree that there are many factors to consider in global warming modelling. You'd be surprised at how many factors are considered. (IANACM)

Actually, you have a good point. There is a problem currently with doctors not sanitizing enough in hospitals. Of all the people I've known who have had surgery, a large percent of them have developed some kind of infection like staph.

This website discusses how common the infection may really be. The bacteria is often best spread through contaminated instruments during things like surgery.

You're still assuming that if the scanner "recognizes" a email as containing Sobig, it really does contain Sobig. The Risks Digest contains a number of past incidents where legitimate email is bounced because a virus scanner has incorrectly identified it as containing a particular virus. If scanners start dropping instead of bouncing mail, that problem becomes worse.

That's not to say they must carry on regardless, the situation really has become intolerable. But it is worth recognizing that the bounce behaviour is there for a good reason, even if that reason is no longer good enough.

this one debunks the FORTRAN bug "urban legend"

Paul has dug into several cases treated previously in RISKS and in issues of
the ACM Software Engineering Notes, and has been able to resolve several
mysteries. In particular he considers the case of Mariner I, about which
various inaccurate stories have been told. Intended to be the first US
spacecraft to visit another planet, it was destroyed by a range officer on 22
July 1962 when it behaved erratically four minutes after launch. The alleged
missing `hyphen' was really a missing `bar'. I quote from Paul's book, pp.
202-203:

During the launch the Atlas booster rocket was guided with the help of two
radar systems. One, the Rate System, measured the velocity of the rocket as
it ascended through the atmosphere. The other, the Track Ssytem, measured
its distance and angle from a tracking antenna near the launch site. At the
Cape a guidance computer processed these signals and sent control signals
back to the tracking system, which in turn sent signals to the rocket. Its
primary function was to ensure a proper separation from the Atlas booster and
ignition of the Agena upper stage, which was to carry the Mariner
Spacecraft to Venus.

Timing for the two radar systems was separated by a difference of forty-three
milliseconds. To compensate, the computer was instructed to add fourty-three
milliseconds to the data from the Rate System during the launch. This
action, which set both systems to the same sampling time base, required
smoothed, or averaged, track data, obtained by an earlier computation, not
the raw velocity data relayed directly from the track radar. The symbol for
this smoothed data was ... `R dot bar n' [R overstruck `.' and `_' and
subscript n], where R stands for the radius, the dot for the first derivative
(i.e., the velocity), the bar for smoothed data, and n for the increment.

The bar was left out of the hand-written guidance equations. [A footnote
cites interviews with John Norton and General Jack Albert.] Then during
launch the on-board Rate System hardware failed. That in itself should not
have jeopardized the mission, as the Track System radar was working and could
have handled the ascent. But because of the missing bar in the guidance
equations, the computer was processing the track data incorrectly. [Paul's
EndNote amplifies: The Mariner I failure was thus a {\it combination} of a
hardware failure and the software bug. The same flawed program had been used
in several earlier Ranger launches with no ill effects.] The result was
erroneous information that velocity was fluctuating in an erratic and
unpredictable manner, for which the computer tried to compensate by sending
correction signals back to the rocket. In fact the rocket was ascending
smoothly and needed no such correction. The result was {\it genuine} instead
of phantom erratic behavior, which led the range safety officer to destroy
the missile, and with it the Mariner spacecraft. Mariner I, its systems
functioning normally, plunged into the Atlantic.

Every form of communications, from talking to someone in the next cubical to receiving pictures from interplanetary space probes, is bound by Shannon's Theorem, which describes the relationship between a channel's bandwidth and signal-to-noise ratio and how much information you can communicate on that channel.

Galileo was equipped with a high-bandwidth communications link capable of doing a much better job with image transmission, but its antenna failed to deploy. Because higher-bandwidth channels have a higher noise floor, a consequence of Shannon's Theorem is that higher-bandwidth wireless communications requires higher effective radiated power. Without the high-gain antenna, the normal image-transmission link was useless. As a result, the project engineers had to reconfigure a low-power, low-bandwidth auxiliary link to do the same job.

It was actually really cool (and really lucky) that they could do that at all.

Search for Mercuri at http://catless.ncl.ac.uk/Risks/search.html and you will see lots of problems with computerized voting.

The whole point of RSS is that, unlike email, it is not push.

In fact, "push" vs "pull" is not very descriptive. You have a newsletter, a publisher who controls the content, and subscribers who read it. There is only one important question: where is the subscription recorded?

There are effectively three models:

1. The subscription is recorded in the subscriber's brain. The subscriber has to make a point of going after the content. This is the model for web pages. I am "subscribed" to publications like The Risks Digest and Crypto-gram because I make a point of viewing the web pages regularly. This model is of little value to a lot of publishers, because their content is not valuable enough that users will make a point of keeping up in this way
2. The subscription is recorded in the publisher's system. This is how email newsletters work. It's fine for the publisher, but unsatisfactory for the reader as he can get subscribed to things he doesn't want. Separating bona-fide subscribed content from spam is very difficult for filtering systems, and the result is that delivery failure rates are rising. This is where we are now, this is where we want to get away from.
3. The subscription is recorded in the subscriber's software. This is the ideal. I can choose to subscribe to something, and no-one can make me subscribe to anything I don't want. The subscribed content will appear in front of me without my needing to remember it or pick it out of a list of a hundred browser bookmarks. RSS falls into this category.

My pet theory is that there is another method that fits in the third category: email retrieved directly from the publisher's system by the subscriber's system using POP3. I subscribe to the content by adding an account to my mail client with the publisher's POP server, and a username of my choice. Doing a "get email" on my mail client will bring down the newsletter along with my other email. (IMAP or NNTP could be used the same way). The advantage of this over RSS is that the clients are already widespread, although ideally they would be enhanced to support this model more smoothly.

It's a sober and informed discussion of engineering safety (mostly but not entirely computer related) that's been going on for almost twenty years.

Try entering "shuttle" in the search form. I did just now and found the brief, grim announcement of the Challenger explosion.

If you prefer to curl up with a dead tree by the fire, read moderator Peter Neumann's Computer Related Risks. It is also available in Japanese translation.

Now, few of us are likely to ever risk our lives flying in space shuttles. Maybe some of us might write the code or design the machinery the astronauts will trust with their lives. But all of us depend on computers every day for our livelihood, and many of us depend on them for our lives more than you would feel comfortable with if you understand the implications of it.

Fly on an airplane lately? Anything a little more modern than a DC-3? Do you know what fly by wire means? Ever write code with a stack overflow or heap corruption? What do you suppose that means for the embedded systems that run today's commercial aircraft?

Does your car have antilock brakes?

Read RISKS. It will make you a better programmer. Because it will put the fear of God into you.

It's a sober and informed discussion of engineering safety (mostly but not entirely computer related) that's been going on for almost twenty years.

Try entering "shuttle" in the search form. I did just now and found the brief, grim announcement of the Challenger explosion.

If you prefer to curl up with a dead tree by the fire, read moderator Peter Neumann's Computer Related Risks. It is also available in Japanese translation.

Now, few of us are likely to ever risk our lives flying in space shuttles. Maybe some of us might write the code or design the machinery the astronauts will trust with their lives. But all of us depend on computers every day for our livelihood, and many of us depend on them for our lives more than you would feel comfortable with if you understand the implications of it.

Fly on an airplane lately? Anything a little more modern than a DC-3? Do you know what fly by wire means? Ever write code with a stack overflow or heap corruption? What do you suppose that means for the embedded systems that run today's commercial aircraft?

Does your car have antilock brakes?

Read RISKS. It will make you a better programmer. Because it will put the fear of God into you.

It seems to me that people *need* a certain amount of flexibility in the law.. Something this rigid is bound to fail...it simply goes too far against human nature.

Indeed. In fact, this is not the first time that such a rigid enforcement scheme has been proposed in the UK. Others have pointed out the folly, and very real risks, of trying to enforce arbitrary speed limits at all times, regardless of traffic conditions.

It seems to me that people *need* a certain amount of flexibility in the law.. Something this rigid is bound to fail...it simply goes too far against human nature.

Indeed. In fact, this is not the first time that such a rigid enforcement scheme has been proposed in the UK. Others have pointed out the folly, and very real risks, of trying to enforce arbitrary speed limits at all times, regardless of traffic conditions.

My objection is that it's not always possible to tell where one invention that's used in a program leaves off, and where another begins. Because it's often possible to re-order the lines of code in a program without altering its behaviour, it could easily happen that someone else's patented algorithm is mixed in to your program in a way that makes it difficult or impossible to find.

Please read:

• Algorithms Have Unclear Boundaries

If, by sacrificing the entire HF radio spectrum, we could actually wire every home in the USA for economical broadband Internet access, I honestly wouldn't oppose it.

While this might be sensible if all that was affected was amateur radio hobbyists I might agree too. But since HF is still an important backup and emergency communications infrastructure I do not agree with such an idea. Sure it has lots of downsides compared to other high-tech solutions. But those high tech solutions are expensive and require extensive infrastructure to be work. But you start cutting trans-atlantic or trans-pacific cables, how quickly and how well can satellite communications scale to handle the increase traffic load? Space weather affect satellite communications, or did you forget about
Galaxy IV malfunction as well as countless other satellite problems (e.g. AO-40).

I will say that I don't believe that power-line distribution makes sense for broadband Internet.

I think you are right, this will be more important than HF users (especially amateur radio operators) complaints. I doubt there is little to no advantage of BPL over other broadband methods, such as various DSL technologies (such as G.lite), cable modems, and DSS like DirectPC.

I know RISKS discussed beneficial viruses a long time ago. I am still searching for that discussion. My recollection though was that the consensus opinion was that it was a bad idea...

areolus is what you meant?

Anyways, I'd say that would still fit indecent as far as general public goes. If you feel the need to be displaying your breasts to other folks, do it at home or a private place. Not in general public.

In case of an emergency onboard an aircraft I will literally bet my life on the instincts of a human being over the computational prowess of machine.

Some people have had to make that bet, and lost.

You may remember the July '02 collision between a DHL cargo plane and a Russian airliner that killed 71 people.

As described in RISKS Digest, in that crash the TCAS (Traffic alert and Collision Avoidance System) correctly ordered the pilot to ascend; the (relatively) uninformed ground controller told the pilot to descend. The pilot obeyed the ground controller, with catastrophic results.

Having someone chop off my finger so they can fake an ATM into thinking it's me is a Bad Idea (tm)

Actually something similar has happened in a prison that used Biometrics for their new high tech electronic locks. During the riot the prisoners attempted to remove the guards hand or fingers, so they could open the lock.

See the RISKS digest archive for the story.

From the latest Risk Digest: stun guns, cattle prods or other interesting toys. Consider it an oblique way of showing that not all bizarre hobbies are bad ;-).

Gorman's work and the access he used is vital - if I'm paying for two links that should be separate, I need to know that I can really check that we have separated physical facilities.

There are a lot more backhoe operators than terrorists - and historically, the chances of a backhoe impact on infrastructure are pretty high.

Gorman's work and the access he used is vital - if I'm paying for two links that should be separate, I need to know that I can really check that we have separated physical facilities.

There are a lot more backhoe operators than terrorists - and historically, the chances of a backhoe impact on infrastructure are pretty high.

Especially do not claim that safety-critical systems are hack-proof, since even people who wouldn't normally try to hack them will try.

It does not even need evildoers to defeat safety-critical systems of some complexity. Consider for instance the 1993 Warshaw accident of a Lufthansa A320 (see also this report). Amongst its causes was a safety system meant to prevent deployment of reverse thrust and spoilers unless the plane had its wheels down on the runway. Which makes sense in principle because trying to stop a plane in mid-air is not a good idey, but turned out to be, uh, not quite helpful when this accident happened.

Now one may argue that this particular problem, or any particular problem, could be fixed by improving the systems' design. However, complexity of the system, and of the problem to be solved, makes it unlikely that even the smartest engineers will get it right soon. Now add evil minds to your considerations.

In the case discussed here, an obvious weakness is the need for location-awareness. What if the plane "thinks" it is elsewehre? This issue is addressed in the article, but I do not really see how they are going to solve it. What if the plane "thinks" it is inside such a soft wall, or surrounded by no-fly zones? What if the plane is Air Force One and has an actual reason to enter a no-fly zone? What if the plane just "believes" it might have been Air Force One in a former life? Not to mention the fact that such a system does not prevent the root problem: planes can still be hijacked. Maybe the next hijacked plane hits airport buildings then, killing as many people as the WTC attack did?

A quick summary:

A single engine light aircraft was flying in heavy cloud and moderate turbulence when it apparently entered a thunderstorm cell. A severe downdraught caused an abrupt descent, followed by wind shear causing a stall, and further descent. The pilot broke free from the base of the cloud, still descending, and saw lots of trees. He pulled back VERY HARD on the controls, recovered control of the aircraft, but felt it was performing strangely, so he landed at the first opportunity.

Subsequent examination of the aircraft showed:

a) eucalyptus leaves in the undercarriage, presumably from tree skimming.

b) the wings had undergone permanent deformation, with the tips being now some 30cm higher than normal. The main spar had bent in two places. This was attributed to 'G' forces in excess of the flight envelope of the aircraft.

Leave the decision making in the hands of the pilot; that's what they're paid for. If I die in an airplane crash, I want to know that the pilot did everything in his power to save my life, and paid for his failure with his own. I'd not be nearly as happy about dying in such a crash and knowing that somewhere some programmer is cheering his software that prevented the pilot from violating some FAA regulation at the expense of the aircraft.

So, what kind of "innovations" has been created by Microsoft? Maybe Clippy. But that's it, and we all know how helpful that is...

Never, ever, forget the badness that was M$ Bob. According to reports, Bill's future wife was the project manager. I have no idea what that says about either of them. The illusion of security through not even trying to be secure.

These Guys can. If anything, we know better now how to make bronze than they did 4000 years ago. Just because they could make it then doesnt mean that it was better than now. Its hard to make good bronze with a wood fire and goatskin bellows.

I can't help you with getting the attention of law enforcement or the service provider, but when all is said and done, I bet Peter Neuman at the ACM RISKS Digest would love to publish your story. The RISKS readers would be interested in the original hijacking, and just as interested in the lackadaisical response by those who could do something about it. The risks posed by both problems are the forum's reason for being.

A computer, properly programmed, can be relied upon to do the right thing.

You have high confidence in programmers.

As for Airbus jets: most airplane crashes occur due to pilot error. Others occur due to mechanical failure. Very few accidents of any sort have ever occurred due to computer failure. Therefore, I would think that a computer, which probably has a much better grip on the situation, given that airplanes have hundreds of sensors that a pilot could not possibly monitor simultaneously, is better prepared to make certain decisions.

Isn't one accident, one too many? I'm not insisting that the computer not have a part in the system--I'm suggesting that these fly-by-wire systems should not be so rigid as to completely lock-out the human factor.

When pilots can recount a few stories (enough to merit an entire television program) where they had to fight with the computer to either get it to recognize that either its input or actions were wrong, I'd say the system has some serious design flaws (linked article is long, but very informative).

And until we (as the human race) have acheived complete infallibility, the system will continue to have design flaws.

A computer, properly programmed, can be relied upon to do the right thing.

You have high confidence in programmers.

As for Airbus jets: most airplane crashes occur due to pilot error. Others occur due to mechanical failure. Very few accidents of any sort have ever occurred due to computer failure. Therefore, I would think that a computer, which probably has a much better grip on the situation, given that airplanes have hundreds of sensors that a pilot could not possibly monitor simultaneously, is better prepared to make certain decisions.

Isn't one accident, one too many? I'm not insisting that the computer not have a part in the system--I'm suggesting that these fly-by-wire systems should not be so rigid as to completely lock-out the human factor.

When pilots can recount a few stories (enough to merit an entire television program) where they had to fight with the computer to either get it to recognize that either its input or actions were wrong, I'd say the system has some serious design flaws (linked article is long, but very informative).

And until we (as the human race) have acheived complete infallibility, the system will continue to have design flaws.