Yes there are moral rights. I take your work and plagerize it (pretending it is my own), or I alter it to construe a statement you did not intend (and attribute that to you) I have infringed on those rights which include attribution and control over your own speech.
Of course, commercial rights are distinct from moral rights both in law and common thought.:-)
IANAL, of course. And moral rights laws are especially weak in the US....
Eyewitness reports suggest that the plain did indeed stall when it reached the place where it finally hit the ground. Total drop appears to have been less than 10 feet.
Which is probably as good as could be hoped for under the circumstances.
The news stories say this is a scenario that pilots don't train for. I was not rebutting your point in this regard.
My main point is that the may not train for this scenario relating to a 777, but they *do* train for it in other aircraft.
"slow down as much as possible" was also a misstatement. I meant to say "hit the ground as slow as possible" which is usually just above normal landing speed. I suppose I clould have been more clear about this:-) IANAP but you are so I will defer to you on this area.
fuel supply issues could have been a factor but are currently being categorized as unlikely. (What *is* a likely cause of the first crash landing of a specific model of aircraft in over a dozen years of operation?)
Now, current information suggests that the engines basically ended up stuck in idle mode. THis does not suggest fuel starvation.
Fuel supply issues could include however fuel contamination. However: jet fuel and water are immiscable. It seems to me that this would have been quickly identified as a problem because any surviving fuel tanks would have water or sludge sitting in the bottom. I think that were this the case, we would have known already.
engine line control electronics is not likely because the engines are controlled on independant systems.
pilot error could be a factor but seems unlikely to me since the error first occurred when the plain was on autopilot.
There is a redundant computer system which does provide commands to the engine line control electrinics. If an unforeseen error condition occurred relating to system input, that could have caused failures in all redundant nodes (this would not be the first time on a 777, but it would be the first time it caused a crash).
Finally, I would take issue with the idea that this scenario is not something that pilots train for. I have known a number of pilots who have said that they train for engine failure-based crash landings on other forms of aircraft (usually light aircraft) and while this is not the exact same scenario, the same principles apply (keep control of the aircraft as long as possible, and slow down as much as possible). The one point I would make however, is that this is a far more touchy situation and a 777 is going to be harder to control into such a soft crash-landing in that sort of scenario than, say, a Cesna due to the much higher stallspeed of the former. Hence the pilots while using procedures taken from general pilot training applied these procedures flawlessly and deserve recognition for superb handling of the crisis.
However that is only possible within certain parameters of hardware function.
Things get interesting when unforeseen electrical faults start occuring in the electrical and electronics systems which feed and power these processing systems. I maintain that you *cannot* guarantee bug-free operation of software on failing hardware, even if the failure is a sensor external to the system because you cannot predict and prepare for every possible failure condition (including miscalibration) of such a component with perfect confidence.
I would add that I have worked out another possibility in my arm-chair engineering relating to Mars missions.
If you have a light, re-entry vehicle which gradually decelerates from modest drag, you should have minimal heat. It also means you have a *very* long re-entry trajectory.
Drag generates the heat. If you have a low terminal velocity because you have high drag, you will generate a lot of heat. If you have a light-weight vehicle (small acceleration due to gravity, not a lot of gravity-induced kenetic energy to bleed off, and it has the right shape it should be able to re-enter without heating up much at all. The basic idea is you could use lift to slow down the decent and thus trade heating intensity for duration.
My ideal shape for a low-temp re-entry vehicle would be a large light-weight lifting body which was able to decend to earth over a period of hours.
The right and left engines are controlled by different computers. The only single points of control are the pilot and a central engine control system. Thus in the absence of pilot error, the only single point of failure is that specific avionics system.
Now the root fault may be due to some sensor or processing system failing and causing a cascade failure to other portions of the system. This sort of thing *has* happened in other 777's (an accelerometer failing in a way as to cause a cascade error into flight control software). In the end the most careful proof of software accurate operation must make certain assumptions about unerlying hardare states. Once hardware starts to go bad, all bets are off (for example, sensors could fail in such a way as to provide apparently valid but wildly inaccurate data to the software which would then return incorrect results (and hence take wrong actions).
Unless you are travelling exactly half-way around the world, there are only 2 great circles that connect the source and destination points.
This means that there is the most efficient great circle arc(goind directly towards your destination) and the less efficient great circle arc (going the other direction around the world until you reach your destination....
Perhaps you have a non-standard definition of 'great circle?'
I think a single software glitch is unlikely to be the cause of the failure. However, best guess at the moment is that the engine issues were software initiated.
You can only mathematically prove that software is bug free given some basic assumptions about hardware performance. If those assumptions fail, then your bug-free software is now buggy because the hardware is buggy and it can't sort out valid from invalid information.
TFA mentions another avionics glitch where a failed accelerometer caused a near accident on a 777 in Australia. The software inappropriately responded to the failure because the failure condition wasn't foreseen.
Most likely the root cause is hardware-related, not software-related. For example, maybe water-based corrosion on some contacts somewhere where the seal was damaged, or a short circuit on some sensor somewhere else. The issue is that this may have triggered failure conditions that were not previously foreseen in the software design.
The 777 has an impressive safety record. However incidents where, say, water gets into circuitry and causes problems, or some previously unforeseen failure situation arises, there will be problems.
As for the "first of its kind" remark-- this is not the first software initiated problem in the 777 if indeed that is the case. It *is* however, the first 777 crash ever. Which ought to make one a little less inclined to question previously unforeseen problems.
It may not be just a software bug. It may be that the software cannot handle some unforeseen hardware state, as happened on the Malaysian Airlines incident a few months ago (that incident was a near-miss but did not result in a crash-- the problem was that the software was unable to handle properly bad data coming in from an accelerometer). Whether this counts as a "software bug" or a "hardware failure" I don't know....
You can prove that the software is bug free for any set of foreseen inputs. The question becomes whether there are unforeseen inputs which can cause problems. Suppose for example, that a sensor fails in an unexpected way-- for example shorting a circuit instead of breaking it, or by sending incorrect data to the computer. In essence you not only have to handle valid inputs from sensors, and normal sensor failures, but you also have to handle sensors which fail in unexpected ways, and you also have to handle every possible electrical fault as well. And then you *still* have to make some assumptions about the underlying communictions between the remaining components.
How, here is the real issue:
Software exists only to process information on underlying hardware. When you have failures in that hardware which cause the information to be corrupted, you cannot count on any results on the software. Hence you software can only be proven bug-free within a reasonably limited set of circumstances. Or, in simpler terms, garbage in? garbage out.
AA was developed as an experiment to help developvideo-game-based training simulations to give people a leg up on army training. It is not the same a Halo, GTA, etc.
The real question I have is when al'Qaeda will discover that the US Army is handing them training material....
1) Avionics resulted in a near miss relating to a 777 a few months ago operated by Malaysian Airlines. The problem was a combination of a software bug and a dead sensor (i.e. the software didn't properly handle sensor errors and a sensor went dead). 2) Despite this problem, the 777 still has an impressive safety record. Only one crash in the history of operating that aircraft and that didn't result in fatalities?
In a plain like the 777 basically, you have three possibilities: human error, electronics failure, or mechanical failures. I think this case seems unlikely to be the result of other human or mechanical failures, so we are left with electronics issues and the primary suspect.
I am guessing that the real lesson here is that nothing is infallible, but that the 777 is pretty-darn good.
My suspicion is that we will eventually find that the 777 needs regular maintenance to portions of it which have not received as much attention in the past. It could be a similar issue to the MA failure-- a dead sensor sending information the software was not prepared to handle, it could be an electrical short circuit (for example, caused by water corrosian or even condensation) as we saw recently with the ISS. The point is that only now, thirteen years after the planes entered operation, we are running into these problems. I don't think that software alone could have caused the problem. More likely it is a combination ofhardware failure triggering bugs in software.
ANd no it is not really a step backwards for databases. It is actually something which offers a niche solution for large-scale single-purpose, semi-accurate databases.
This is almost but not entirely unlike what Codd had in mind when he wrote his seminal paper: "A Relational Model of Data for Large Shared Data Banks."
If it were a paradigm shift, it would be a step backward. However, as "one more tool in the toolbox" it is useful in some cases where RDBMS's are not.
Hmmm.... ISTM that the basic critiques come down to:
1) No indexing.
Which means
2) Certain types of constraints probably don't work (such as UNIQUE constraints)
Which also means
3) Referential integrity checking and other things don't work.
This leads to the conclusion that the idea is good for certain types of data-intensive but not integrity-intensive applications (think Ruby on Rails-type apps) but *not* good for anything Edgar Codd had in mind....
There are a couple of things you can do to figure this out. First, you can check if you system ever shocks you when it is not plugged in and running off the battery. No. never. Also:
1) Never shocked me in the US. 2) Shocked me frequently when plugged into any of about 4 wall plugs in this one house only 3) Shocked me less frequently when plugged in elsewhere in that house. 4) Never had it happen when plugged in at a hotel or other commercial building.
I suppose there could be some other issues relating to grounding in the AC adapter which might cause this. However, the root cause appeared to be building wiring, which suggests *some* sort of connection between the building earth ground and the laptop case. Note that Indonesia uses 240V with EU-style adapters (with 2 earth ground leads on the exterior of the socket).
Customer's shocked by Dell's high-performance Laptops!
Actually, on one of my trips to Indonesia I had a similar problem with my (three-prong) Compaq Armada. If I touched any exposed metal on the case, I might (or might not, depending on the circumstances) receive an electric shock.
In that case though the problem was not due to the laptop but rather faulty building wiring. My guess is that either the earth ground was not attached to the wall socket properly or somewhere else a lot of electricity was being dumped down the earth ground, changing its electric potential.
A stripped down strict-only build would help with the administrative control issues I mentioned. Unfortunately it still doesn't address the software distribution issues. What is needed there is some sort of a keyword on table creation to fail with an error when the requested table type does not exist.
Something like:
CREATE TABLE foo ( bar int auto_increment primary key, baz text not null) TYPE=INNODB ONLY;
That Jazz musician probably has a drivers license with a primary residence listed on it. At least this provides a location to begin attempting to contact the person. So yes, it exists.
Re:To NULL or not to NULL
on
Sun Buys MySQL
·
· Score: 1
The only thing I would add is that there are certain times when even the rules I have argued need to be broken.
Consider the following issue: Queued jobs.
Every queued job has an id, a time created, and a time finished. The time completed may be NULL if the job hasn;t completed yet because we don't know yet when the job will complete.
Ok, now suppose we want to track success or failure. So we add a success code. true if success, false if failure. when the job completes, we force the success code to be not null.
So now we have: create table jobs ( id int primary key, -- contrived artificial data, no natural primary key time_entered timestamp not null, time_completed timestamp, -- default is null success bool, -- default is null CHECK ((time_completed IS NULL AND success IS NULL) OR (time_completed IS NOT NULL AND success IS NOT NULL)) );
Ok so now we want to add an error condition. On success, the data really doesn't exist, but on failure it does. The only way to actually constrain this data without using a trigger is to put it into the main table by adding the following lines:
error_condition text, --default is null CHECK ((error_condition IS NULL AND success IS NOT FALSE) OR (error_condition IS NOT NULL AND success IS FALSE))
This complex set of "this value requires this other field, and the other field may not exist when the value does not exist" requires very complex dances to get around when it comes to avoiding NULLs. Unfortunately the current RDBMS's are not designed to handle these situations well because (IMHO) Codd made a minor and forgivable error in giving NULLs an ambiguous meaning.
Slashdot Mirror
Yes there are moral rights. I take your work and plagerize it (pretending it is my own), or I alter it to construe a statement you did not intend (and attribute that to you) I have infringed on those rights which include attribution and control over your own speech.
:-)
Of course, commercial rights are distinct from moral rights both in law and common thought.
IANAL, of course. And moral rights laws are especially weak in the US....
According to the reports I have read, the engines were stuck in "flight idle" which meant spinning but not really delivering any real thrust.
Eyewitness reports suggest that the plain did indeed stall when it reached the place where it finally hit the ground. Total drop appears to have been less than 10 feet.
Which is probably as good as could be hoped for under the circumstances.
The news stories say this is a scenario that pilots don't train for. I was not rebutting your point in this regard.
:-) IANAP but you are so I will defer to you on this area.
My main point is that the may not train for this scenario relating to a 777, but they *do* train for it in other aircraft.
"slow down as much as possible" was also a misstatement. I meant to say "hit the ground as slow as possible" which is usually just above normal landing speed. I suppose I clould have been more clear about this
Duke Nuke'm Forever is just waiting for HURD 1.0....
fuel supply issues could have been a factor but are currently being categorized as unlikely. (What *is* a likely cause of the first crash landing of a specific model of aircraft in over a dozen years of operation?)
Now, current information suggests that the engines basically ended up stuck in idle mode. THis does not suggest fuel starvation.
Fuel supply issues could include however fuel contamination. However: jet fuel and water are immiscable. It seems to me that this would have been quickly identified as a problem because any surviving fuel tanks would have water or sludge sitting in the bottom. I think that were this the case, we would have known already.
engine line control electronics is not likely because the engines are controlled on independant systems.
pilot error could be a factor but seems unlikely to me since the error first occurred when the plain was on autopilot.
There is a redundant computer system which does provide commands to the engine line control electrinics. If an unforeseen error condition occurred relating to system input, that could have caused failures in all redundant nodes (this would not be the first time on a 777, but it would be the first time it caused a crash).
Finally, I would take issue with the idea that this scenario is not something that pilots train for. I have known a number of pilots who have said that they train for engine failure-based crash landings on other forms of aircraft (usually light aircraft) and while this is not the exact same scenario, the same principles apply (keep control of the aircraft as long as possible, and slow down as much as possible). The one point I would make however, is that this is a far more touchy situation and a 777 is going to be harder to control into such a soft crash-landing in that sort of scenario than, say, a Cesna due to the much higher stallspeed of the former. Hence the pilots while using procedures taken from general pilot training applied these procedures flawlessly and deserve recognition for superb handling of the crisis.
However that is only possible within certain parameters of hardware function.
Things get interesting when unforeseen electrical faults start occuring in the electrical and electronics systems which feed and power these processing systems. I maintain that you *cannot* guarantee bug-free operation of software on failing hardware, even if the failure is a sensor external to the system because you cannot predict and prepare for every possible failure condition (including miscalibration) of such a component with perfect confidence.
I would add that I have worked out another possibility in my arm-chair engineering relating to Mars missions.
If you have a light, re-entry vehicle which gradually decelerates from modest drag, you should have minimal heat. It also means you have a *very* long re-entry trajectory.
Drag generates the heat. If you have a low terminal velocity because you have high drag, you will generate a lot of heat. If you have a light-weight vehicle (small acceleration due to gravity, not a lot of gravity-induced kenetic energy to bleed off, and it has the right shape it should be able to re-enter without heating up much at all. The basic idea is you could use lift to slow down the decent and thus trade heating intensity for duration.
My ideal shape for a low-temp re-entry vehicle would be a large light-weight lifting body which was able to decend to earth over a period of hours.
The right and left engines are controlled by different computers. The only single points of control are the pilot and a central engine control system. Thus in the absence of pilot error, the only single point of failure is that specific avionics system.
Now the root fault may be due to some sensor or processing system failing and causing a cascade failure to other portions of the system. This sort of thing *has* happened in other 777's (an accelerometer failing in a way as to cause a cascade error into flight control software). In the end the most careful proof of software accurate operation must make certain assumptions about unerlying hardare states. Once hardware starts to go bad, all bets are off (for example, sensors could fail in such a way as to provide apparently valid but wildly inaccurate data to the software which would then return incorrect results (and hence take wrong actions).
Unless you are travelling exactly half-way around the world, there are only 2 great circles that connect the source and destination points.
This means that there is the most efficient great circle arc(goind directly towards your destination) and the less efficient great circle arc (going the other direction around the world until you reach your destination....
Perhaps you have a non-standard definition of 'great circle?'
I think a single software glitch is unlikely to be the cause of the failure. However, best guess at the moment is that the engine issues were software initiated.
You can only mathematically prove that software is bug free given some basic assumptions about hardware performance. If those assumptions fail, then your bug-free software is now buggy because the hardware is buggy and it can't sort out valid from invalid information.
TFA mentions another avionics glitch where a failed accelerometer caused a near accident on a 777 in Australia. The software inappropriately responded to the failure because the failure condition wasn't foreseen.
Most likely the root cause is hardware-related, not software-related. For example, maybe water-based corrosion on some contacts somewhere where the seal was damaged, or a short circuit on some sensor somewhere else. The issue is that this may have triggered failure conditions that were not previously foreseen in the software design.
The 777 has an impressive safety record. However incidents where, say, water gets into circuitry and causes problems, or some previously unforeseen failure situation arises, there will be problems.
As for the "first of its kind" remark-- this is not the first software initiated problem in the 777 if indeed that is the case. It *is* however, the first 777 crash ever. Which ought to make one a little less inclined to question previously unforeseen problems.
It may not be just a software bug. It may be that the software cannot handle some unforeseen hardware state, as happened on the Malaysian Airlines incident a few months ago (that incident was a near-miss but did not result in a crash-- the problem was that the software was unable to handle properly bad data coming in from an accelerometer). Whether this counts as a "software bug" or a "hardware failure" I don't know....
You can prove that the software is bug free for any set of foreseen inputs. The question becomes whether there are unforeseen inputs which can cause problems. Suppose for example, that a sensor fails in an unexpected way-- for example shorting a circuit instead of breaking it, or by sending incorrect data to the computer. In essence you not only have to handle valid inputs from sensors, and normal sensor failures, but you also have to handle sensors which fail in unexpected ways, and you also have to handle every possible electrical fault as well. And then you *still* have to make some assumptions about the underlying communictions between the remaining components.
How, here is the real issue:
Software exists only to process information on underlying hardware. When you have failures in that hardware which cause the information to be corrupted, you cannot count on any results on the software. Hence you software can only be proven bug-free within a reasonably limited set of circumstances. Or, in simpler terms, garbage in? garbage out.
AA was developed as an experiment to help developvideo-game-based training simulations to give people a leg up on army training. It is not the same a Halo, GTA, etc.
The real question I have is when al'Qaeda will discover that the US Army is handing them training material....
Not so sure.
I read a number of articles on it and:
1) Avionics resulted in a near miss relating to a 777 a few months ago operated by Malaysian Airlines. The problem was a combination of a software bug and a dead sensor (i.e. the software didn't properly handle sensor errors and a sensor went dead).
2) Despite this problem, the 777 still has an impressive safety record. Only one crash in the history of operating that aircraft and that didn't result in fatalities?
In a plain like the 777 basically, you have three possibilities: human error, electronics failure, or mechanical failures. I think this case seems unlikely to be the result of other human or mechanical failures, so we are left with electronics issues and the primary suspect.
I am guessing that the real lesson here is that nothing is infallible, but that the 777 is pretty-darn good.
My suspicion is that we will eventually find that the 777 needs regular maintenance to portions of it which have not received as much attention in the past. It could be a similar issue to the MA failure-- a dead sensor sending information the software was not prepared to handle, it could be an electrical short circuit (for example, caused by water corrosian or even condensation) as we saw recently with the ISS. The point is that only now, thirteen years after the planes entered operation, we are running into these problems. I don't think that software alone could have caused the problem. More likely it is a combination ofhardware failure triggering bugs in software.
Not really.
ANd no it is not really a step backwards for databases. It is actually something which offers a niche solution for large-scale single-purpose, semi-accurate databases.
This is almost but not entirely unlike what Codd had in mind when he wrote his seminal paper: "A Relational Model of Data for Large Shared Data Banks."
If it were a paradigm shift, it would be a step backward. However, as "one more tool in the toolbox" it is useful in some cases where RDBMS's are not.
Hmmm.... ISTM that the basic critiques come down to:
1) No indexing.
Which means
2) Certain types of constraints probably don't work (such as UNIQUE constraints)
Which also means
3) Referential integrity checking and other things don't work.
This leads to the conclusion that the idea is good for certain types of data-intensive but not integrity-intensive applications (think Ruby on Rails-type apps) but *not* good for anything Edgar Codd had in mind....
Interesing. That is 60Hz AC, suggesting it is coming from the wall socket, either through a fault in the rectifier or somewhere else....
1) Never shocked me in the US.
2) Shocked me frequently when plugged into any of about 4 wall plugs in this one house only
3) Shocked me less frequently when plugged in elsewhere in that house.
4) Never had it happen when plugged in at a hotel or other commercial building.
I suppose there could be some other issues relating to grounding in the AC adapter which might cause this. However, the root cause appeared to be building wiring, which suggests *some* sort of connection between the building earth ground and the laptop case. Note that Indonesia uses 240V with EU-style adapters (with 2 earth ground leads on the exterior of the socket).
In general you are correct. However, this never occurred anywhere else, and it seemed related to the specific plugs I plugged it into.
I didnt check the plug (and that laptop has long-since fallen apart) but that would seem to support an earth-grounded case.
MySQL is FAST:
Free
And
Sorta
Transactional.
The MySQL development team has also traditionally been sorta ACID-resistant.
Being RIGHT is more importan than being fast.
Customer's shocked by Dell's high-performance Laptops!
Actually, on one of my trips to Indonesia I had a similar problem with my (three-prong) Compaq Armada. If I touched any exposed metal on the case, I might (or might not, depending on the circumstances) receive an electric shock.
In that case though the problem was not due to the laptop but rather faulty building wiring. My guess is that either the earth ground was not attached to the wall socket properly or somewhere else a lot of electricity was being dumped down the earth ground, changing its electric potential.
A stripped down strict-only build would help with the administrative control issues I mentioned. Unfortunately it still doesn't address the software distribution issues. What is needed there is some sort of a keyword on table creation to fail with an error when the requested table type does not exist.
Something like:
CREATE TABLE foo (
bar int auto_increment primary key,
baz text not null) TYPE=INNODB ONLY;
And you had better hope that the requirements don't change so that suddenly your magic values have normal meanings ;-)
That Jazz musician probably has a drivers license with a primary residence listed on it. At least this provides a location to begin attempting to contact the person. So yes, it exists.
The only thing I would add is that there are certain times when even the rules I have argued need to be broken.
Consider the following issue: Queued jobs.
Every queued job has an id, a time created, and a time finished. The time completed may be NULL if the job hasn;t completed yet because we don't know yet when the job will complete.
Ok, now suppose we want to track success or failure.
So we add a success code. true if success, false if failure.
when the job completes, we force the success code to be not null.
So now we have:
create table jobs (
id int primary key, -- contrived artificial data, no natural primary key
time_entered timestamp not null,
time_completed timestamp, -- default is null
success bool, -- default is null
CHECK ((time_completed IS NULL AND success IS NULL) OR (time_completed IS NOT NULL AND success IS NOT NULL))
);
Ok so now we want to add an error condition. On success, the data really doesn't exist, but on failure it does. The only way to actually constrain this data without using a trigger is to put it into the main table by adding the following lines:
error_condition text, --default is null
CHECK ((error_condition IS NULL AND success IS NOT FALSE) OR (error_condition IS NOT NULL AND success IS FALSE))
This complex set of "this value requires this other field, and the other field may not exist when the value does not exist" requires very complex dances to get around when it comes to avoiding NULLs. Unfortunately the current RDBMS's are not designed to handle these situations well because (IMHO) Codd made a minor and forgivable error in giving NULLs an ambiguous meaning.