Might be inherited from
Wasn't Spanair owned by SAS at the time? a few years ago when the Q400 was having lots of gear collapses, all the aircraft with failures (or signs of imminant failures) were owned and maintained by SAS, no other operator's aircraft were affected. IIRC it was eventually found that SAS were not maintaining them properly (though they still junked the Q400 fleet and tried to blame the manufacturer)
need to know
What operating system were they using?
maintenance on Windows probably
"Modern avionics systems have at least three different computer control circuits built into them which are self monitoring - not to mention other safeguards - I find it hard to believe that a groundside computer running windows of all things would be responsible for the *entire* maintenance and troubleshooting of an airlines fleet..."
The aircraft itself certainly wasn't running Windows, but I certainly expect that the maintenance system does. Big fail there, folks.
I *do* hope that Lloyds increases their premiums enough that the PHBs see that getting serious about security (start with chucking Windows) is less expensive than the increased premiums. That's all the PHBs understand, so this is the way to get them to improve both safety and security.
Time to declare writing trojans as "information terrorism?"
it is clear from the number of SCADA-affecting viruses and trojans (Conficker comes to mind) that a change in tactics is called for, in the form of an international declaration that writing or distributing any malicious software targeted at these systems is classed as information terrorism.
At the very least it would free up more resources to deal with this threat, which has the potential to cause massive loss of life (think power grid shutdowns, etc) and cause untold long term harm to the fabric of society.
I'd also like to see the RIPA Act extended to increase the penalty where the "key" being withheld has to do with the control of botnets, to life without parole.
Its AC, Jim but not as we know it
The change in tactics
should be to keep those systems *OFF* the Internet. Period. Oh, it's convenient, yes. Security is inconvenient, *good* security is fscking inconvenient, and so a decision to do something like making SCADA systems accessible from anywhere "because it's convenient" should be shot down because of those three words alone.
A proposal to run such a system on Windows should be chucked out too. Including the proposer, and preferrably from the board-room floor of the main office.
Actually, i'd not be surprised if the claim WERE false. However, by pushing it anyway any government(s) would be able to label malware writers as domestic terrorists. Then perhaps they could really being out the big guns to track people down. I suppose if one is losing the fight, bring on the heat.
Read the article guys?
"There are specialized OSes for this kind of thing, like Green Hills Integrity OS."
Correct. And the Intel(WindRiver) equivalent. And maybe others. And for some relatively lightweight things, maybe no real OS at all, except maybe a scheduler. But so what, it's not immediately relevant here, once you've read the article.
What the article actually says is that a central maintenance/logging computer - at HQ, on the ground - was infected. So the picture is not quite as bad as you thought, although if people died as a result, it is clearly bad enough, and will hopefully cause some serious thinking in various IT departments. (But I'm not holding my breath, because most IT departments are clueless).
"Modern avionics systems have at least three different computer control circuits built into them which are self monitoring"
Maybe so. But supposing they are all based on identical requirements and all run identical software and there ends up being a common mode failure - a failure in the design or build process, rather than a random component failure?
Or suppose some management genius has said we don't need to test this stuff in the actual target environment, we'll instrument the source and only test that - after all, it's so much quicker and cheaper testing on a PC with a different processor and different compiler. Actually building it with the real tools into the expensive target system and driving that through the relevant sequence of tests takes ages and costs a fortune.
Supposing the compiler (be it Green Hills or something else, maybe something gcc-related, maybe Gnat perhaps?) has an off day and the not-quite-correct compilation results end up on the aircraft, untested? [Ada compilers can be validated but that doesn't guarantee they always produce correct code]. In the current regulatory environment this is not a theoretical possibility, it is a near certainty in the next few years.
"Surely a plane has a log book that pilots should look at."
That would seem very sensible, but actually I'm not sure it happens. There has been a massive move towards getting rid of paper in the cockpit (see, for example, "Electronic Flight Bags", which replace a whole load of paper documents). An article describing Boeing's EFB is at
Page 2 has a picture of it, and one item on the display says "LOGBOOK", and logbooks are also mentioned in the description. So maybe it replaces paper logbooks? Anyone know the current status of paper logbooks on modern commercial aircraft?
It gets worse. Page 8 seems to say their EFB runs both WIndows and a DO178B-certified (look it up) Linux. Go read the PDF (it's a reprint of a magazine article so may not be 100% correct, though it was written by a Boeing employee), see if it makes sense to you. Then contact your MP, or the CAA, or whoever, and tell them how worried you are about the way things appear to be going in the industry.
Air travel looks less and less attractive year by year, and not just because of the ridiculous "security theatre" at the airports.
What OS ran the central computer? What executable file format?
before you blame windows
I've never seen windows run an airplane. I think it was a human screw up.
As has been said a few times,
the trojan-infected computer was in the airline's maintenance centre, not aboard the plane. But some airlines actually do run Windows aboard airplanes; a Lufthansa crewbeing once told me that their in-flight entertainment systems were running on NT 4.0 at the time. Of course, that system is not connected in any way with the flight control logic, which typically runs on a proprietary RTOS.
Time for a beer or three.
@all Windows(R) posts
Years and years ago, for a thesis I wrote the software for a concept cockpit display which would show certain in-flight hazards... on windows 3.11 (for workgroups). At the time we were "eagerly" awaiting windows 98 as it was supposed to be the greatest thing coming. I did a lot of searching around on the internet at the time on a Mac, using the Lycos (how cool, a spider that doesn't make a web) search engine. This tells you pretty much which time I'm talking about.
Anyways, after we presented all our research, and did a demonstration and simulation of said display, one person in the jury of our dissertation asked me what would be next step for me with the software...
I told him that apart from some kind of strict code review, it might be a good idea to port the software to a stable platform for use in an aircraft. Like Unix. Not Windows.
They all kind of smirked at me, asking me "why? A lot of avionics software is running on Windows right now".
I had no reply to that as my jaw was on the floor. Never felt the same way flying after that one.
You might want to have a closer look at the avionics bay in any major airliner and check the server-racks.
This one was a jury penal consisting of NASA (they have a civil aviation research branch), FAA, MIT, and NTSB mind you.
Re: before you blame windows
I've also seen a trend of the management doing anything and everything to avoid making it look like a pilot has screwed up, if at all possible.
As an aircraft maintainer, I see numerous examples of pilot idiocy in small things, and sometimes not so small things, and get reamed out if I write up the crew idiocy in the maintenance logs, rather than something generic and bland about how the fault went away after testing it (for the 47th time, even when the recurring fault is expressly caused by crew doing something stupid...)
The reporting of malware as the cause of a crash seems to be a LARGE stretch to me, considering just how redundant the systems are on these planes.
I haven't worked a MD-82, but still, for it to have passed FAA airframe certification as a commercial aircraft, as well as whatever the EU certifying authority requires, I can't imagine that it's running anything that would have any flavor of Windows on it, nor that there weren't indications and warnings available to them.
More likely, I suspect that there were faults with the warning system, and it was disabled, or just ignored due to repeated false alerts, even when it was reporting critical info at that point.
It wouldn't be the first time such has happened, and likely not the last either.
Helicopter for the obvious attempt at sweeping the whole mess under the carpet and shuffling a couple of easy patsies off to pave the way...
But I heard Windows is a human screw-up.
Yes, it's a human screw up but
People are quick to blame pilots in such cases - they have forgotten to set the flaps for take off.
But these pilots were on the same plane as the passengers, they would not have intentionally been cavalier about the plane configuration as it affected them as much as the rest of the pax. They would also not just forget that the flaps need to be set - that's a basic flight issue, you just don't forget that planes need high-lift devices for t/o and landing.
But with all that the pilots still failed to set the flaps, they failed to catch this in their pre-take off check lists, the aircraft automation failed to warn the pilots about that, the pre-flight checks failed to identify that the aurual warning has been turned off by maintenance, the company procedures allowed the critical systems in the head office to be infected with malware and so on and so forth. There is never one single reason behind such a catastrophic event and the pilots cannot be blamed for this.
Pilots are human and they behave as humans - they miss things when they become distracted or overloaded or placed in a situation which has deviated from routine for whatever reason. Humans in the cockpit need a backup in the automation and organisational systems. When those systems fail the "naked" human on the front-end will likely fail as well.
Is the standard aircraft avionics (IE the fire by wire stuff) is written to. It's a US standard so US mfg aircraft *must* adhere to it.
It's equivalent has been adopted world wide.
As others have pointed out it would be *very* strange that the actual *embedded* systems were infected. *Why* someone would write something which killed the warning from central maintenance logging the plane had 2 faults already would be a bigger question.
As would *why* the warning hooter was switched off (or disabled, which implies some kind of sabotage).
And of course lastly WTF the pilot and co-pilot didn't notice *anything* wrong with their aircraft handling.
Before you blame the pilots...
The complaint is that the system that logs pilot comments should have flagged up a problem requiring more extensive investigation after the third note was entered.
So, the pilots tried to take off without flaps etc and no warning sounded. People are saying "What idiot tried to do that?"
We have no idea what the logged errors were. Maybe the previous post-flight comments were along the lines of "the flight check warning klaxon appears to be broken", or "the command to set flaps had to be repeated four times before the system responded correctly", or "the flap position indicator appears to require recalibration"
Hence the importance of the logging system.
I misread the article, and i'm relieved. MD wasn't crazy then 8-).
As for "information terrorism". Phbbbt. I don't like this trend to call everything "terrorism". Terrorism is terrorism and everything else isn't. If whoever wrote these trojans were tracked down they'd be in big big trouble already, probably manslaughter even, but they were not terrorists. Terrorism laws are strict, and it's far too easy to fall into a police state by labelling more and more things terrorism until jaywalking as "terrorism by obstructing flow of commerce". I do think someone should get some competent infosec guys together to track down some of these guys so though, especially the bank trojan ans scareware ones.
If need a mission critical safe system why run Windows
We never know why they ran Windows and not Linux but why wasn't the system's check, I am sure they must of had some virus software. Obvious there is many failures within the maintenance of this plane but again I have to agree Linux should be ran on system were lives can be affected.
Windows systems are made to make money that is the bottom line
to those blaming windows...
If some numbnut secures steel bars to a truck with bungee cords instead of ratchet straps, does everyone rail about how incompetent the makers of bungee cords are, for making bungie cords too stretchy? No; that's absurd. It seems that the basic level of coherent thought required to come to that conclusion is sorely lacking in the IT field.
Any safety-critical system needs to be running qnx or a similar hardened rtos. And even running on an insecure os, any such software should watchdog itself to prevent these failures. Windows has plenty of failings, but blaming microsoft for this is just absurd.
To those blaming Windows
Absolutely. Also, assuming for a moment that the story is largely correct, and a malware-infection is to blame for this (something most commenters seem to agree with), I am utterly puzzled by the fanbois of various denominations frothing at the mouth at the chance to bash Windows.
Clearly, blame has to be laid at the door of the coders of the malware, rather than the operating system? This is something I find sorely lacking throughout this discussion. Fact is that all operating systems have bugs, but that doesn't give anybody permission to hack them, or absolve them from the consequences of their actions. The problem is the juvenile mindset of some programmers, who consider it an achievement to wreck systems with scant regard to what they are used for.
Unless programmers develop a sense of morality and ethics, and start to think about the possible consequences of their actions, nothing will change.
Read the EULA
Indeed, and if anyone bothers to read the WIndows EULA they would see that WIndows should not be used for mission-critical uses, or words to that effect. If developers are then too f'ng lazy to learn or develop on a mission-critical OS, then they are the ones to be shot. A safety management system for an airline, although not interfacting directly with an aircraft, is still mission critical and should not be sitting on Windows. Full stop / period !
Swiss Cheese Model
They took off without setting the flaps.
As basic an error as starting to drive a car with a door left open.
The Master Config alarm had had its circuit breaker pulled by the Engineers.
The holes in the cheese lined up...
Clearly pilot error
Unless there were some other factors that the article failed to mention, the primary cause of the crash has to be put down to the failure of both captain and first officer to set flaps for takeoff (normally 11 degrees for the MD80, but wind and loading could change this). This should have been done quite early in the taxi to the runway phase AND the setting (amongst others) checked prior to engaging takeoff thrust.
Anyway should some trojan code somehow manage to find its way into the onboard flight management computer, probably the worst thing that would happen is that the flight gets diverted VIA GRA (beacon GRA in Southern Italy would be the most likely for a European flight)
I am an airline pilot, so please let me add something to the debate.
No-one runs laptop-based Maintenance Manuals, as these manuals are what the regulators audit regularly and/or use to prosecute licensed pilots/engineers if things go wrong. If they were electronic, they could be tampered with to cover things up, so they won't allow this.
The story is that this aircraft had a huge history of slat/flap problems that the central maintenance computer should have picked up and alerted the engineer controllers to bring it into the hangar and rectify. It did not and here is where the Trojans/OS issue is brought up.
The end result was that the pilots were trying to keep to schedule (long day, close to limits for duty time, etc) when the flaps would not extend. So they taxied back to the stand (more delay) for the engineer to rectify it. He over-rode some of the protections (and warnings) to get the job done, it appears. In their rush to recover the delay, the pilots forgot to run the flaps for take-off, there was no warning any more, people died.
So yes the ultimate blame lies with the pilots, but then the pilots are usually the last line of defence against systemic problems with the operation - an operation in this case possibly affected by Trojans! The Trojans didn't directly cause the crash, but crashes are usually caused by many little errors/conflicts and they were one part of that.
Just so you can enjoy your next flights, aircraft do not run Windows or similar commercial ("non-critical" OSes)
It might be the translation but...
A 'Trojan' steals stuff with as little interference as possible. Much more likely scenarios are screw-you-up malware or botched security or 'blame something else for our lack of sysadmin competence'. However as we don't know the link between the nature of the faults and the causes of the accident (and at first sight it seems peculiar) it is difficult to 'put the blame on malware'.
"three independent computers" - citation needed
Some people here seem to think that critical decisions on aircraft are made by three independent computers taking a majority vote. I understand that principle, I just don't believe that triple modular redundancy (TMR), with or without independent designs, happens in reality at the level of aircraft computer systems, and I wonder where these people get their information.
Two of three voting can and does happen at aircraft sensor level but even that can have problems.
A far more realistic scenario is two identical control systems built with completely identical electronics and with completely identical software (based on completely identical requirements specifications). Now, do you see any fundamental problems with that? Some people might, but as it's lives that are at stake, rather than (say) secure financial transactions, it doesn't get much coverage.
Temporarily ignoring the issue of a common mode fault in requirements or implementation or electronics... These systems self check by simply talking to each other and saying "are you sure?" If only one says "I'm not sure", it is marked as failed and the other one takes over till end of flight. If both say "I'm not sure" then either they change to "limp home safely mode" till end of flight if possible, or there is a bigger problem.
Find me an example of a modern TMR system on a modern commercial aircraft and I'll happily be proved wrong (for that specific case). But you won't generally find TMR on (for example) a FADEC (full authority digital engine control) system. The cost-benefit analysis done by the beancounters says it's too expensive.
But the chances of two things failing independently at the same time are negligible aren't they?
Well, I guess it depends what you mean by negligible, actually. Go read about the AF447 crash a couple of years ago. A commercial aircraft on a transatlantic flight, with three airspeed sensors (Pitot rubes) from two different vendors, as was (still is?) industry standard practice. By design, if there is a disagreement between sensors, the flight control systems trust the majority (*this* is the level at which the two of three redundancy applies, if it applies at all).
On AF447, the two same-design sensors from the same vendor failed at the same time in the same way and produced the same erroneous results. The flight control system trusted the failed sensors and their identically erroneous results. Over two hundred people died as a result.
So these are not hypothetical possibilities, these are real matters of life and death.
Incidentally, there's a nice new nuclear reactor being built at Olkiluoto in Finland. European nuclear regulatory policy for the last ten years or so has been that there must be a control system for routine control of the reactor, and a separate independent one for safety shutdown of the reactor. Sensible enough, right? Well one of the many reasons Olkiluoto is disastrously late and over budget is that the suppliers Areva, despite knowing of this regulatory policy, proposed a single integrated system for control and shutdow, and are stuck in discussions with the regulators on whether that's acceptable or not. You'd have thought the policy would have been a stong hint, wouldn't you.
Incidentally that's the same Areva that has been using Siemens' WinCC SCADA package, the one whose vulnerabilities you may have read about here in the last few weeks (though you may not have noticed the WinCC name). Do you think they might have been proposing WinCC? How would you know? Would you be happy if they were?
Pinto syndrome. It wasn't just for cars, and it hasn't gone away. Spread the word.
I hate computers
Re the reactor - computerised safety shudown?
What ever happened to a big fucking lever on the wall - held up by some latch and safety wire, that when pulled dropped the moderator rods into the core or the piles out of it?
Fuck the remote control and all the bullshit - I am pulling the plug from the wall - cause OFF means OFF, not standby or hibernation or some other fucking crap.
Who is the idiot who runs an airplane with standard PCs running XP?
"The airline's central computer which registered technical problems on planes was infected by Trojans"
What? Windows on a airplane? As far as I know, the licence agreement explicitly prohibiths anything like that. In bold letters.
Who is the idiot who runs an airplane with standard PCs running XP?
Blame the airline's admin team
Lots of yelling and bitching about Windows again which is a big yawn, if indeed the airlines "central computer" was actually running windows). But the problem here isn't Windows, it's the folks maintaining the systems who are to blame. Why weren't they ensuring the highest levels of platform hygiene in such a critical system. i.e. patching and ongoing detection.
We run a load of Windows and Unix boxes, these machines are internet facing and so baring their arses to all sorts of break in attempts 24hrs a day.
Over the past five years we've had two machine hijackings, neither of these were on the Windows platform. The machines involved were running Linux and the cause was that the boxes weren't being patched correctly. This is human error, not the fault of the OS.
Yes MS have had a lot to answer for over the past 15 years, but since 2003-2004 they've pulled their finger out and Windows 2003 and 2008 are pretty secure operating systems and as a hoster I should know.
It truly grips my shit when I see some of the ill-informed crap spewed by some of the anti-Windows league. Sorry guys, go get a real job running a real platform that has to weather the endless storms of saboteurs trying to breach your security before opening your mouths with all that crap.
LOL ROOLY - MS FAN BOI?
"It truly grips my shit when I see some of the ill-informed crap spewed by some of the anti-Windows league. Sorry guys, go get a real job running a real platform that has to weather the endless storms of saboteurs trying to breach your security before opening your mouths with all that crap."
I dunno MS Fan Boi - Ill informed? Which BSOD are you not looking at today?
IF MS made secure, sane software, that wasn't just hastily repackaged money making cash cows, same soap, different package, then perhaps there would not be millions of insanely angry and frustrated NON MS fan bois.
10 different versions of the OS, and only the professional version +, has the tools to fix the problems in it, that come with the OS, while the home users get forced to eat shit.
Ubuntu = one standardised OS for all.
MS ARE a corrupt and deceitful company run by a corrupt and deceitful management.
@Tool of Lucifer
Platform agnostic actually.
We run Windows and Linux, we've had more compromises due to insufficient patching on the Linux environments because our Windows admins make bloody sure those boxes are locked down/patched timeously, Linux folks live in this complacent world of "can't happen here"...sadly it does...and that's the facts of the matter from our experience.
FYI: I haven't had a BSOD on any of our 300 or so Windows boxes for five years now. When we did get them they were usually caused by hardware or third party driver issues.
Personally I run Ubuntu, OSX and Windows in the house so can hardly be considered a 'fanboi' of anything, except my Android phone.
Your whiny utterances about MS and their corruption/deceit just sounds like the noise of a 15 yr old boy living in his basement spending too much time reading slashdot. How about checking out the Oracle/Google spat about Java, now there's a couple of companies that smell strongly of deceit and corruption.
Anyway, stop being a twat and try getting a real job managing and securing 60 racks of internet facing kit then you'll maybe learn a thing or two before criticising.
The airline's central computer?
Did you mean "the airliner's central computer"? Was it connected to the internet then?
Pilot error first - equipment second
First and foremost the pilots didn't set the flaps prior to takeoff. They were not following procedure and they were not paying attention, a bad combination in a cockpit.
Second, the plane had numerous minor mechanicals that included a disabled warning system. None of them would have prevented the plane from flying if the pilots had not committed error number 1 above. Nevertheless the properly functioning systems would have caught the problem and prevented the crash.
Third, the screwed up central computer that should have caught on to the grocery list of minor mechanicals on that plane and grounded it until they were repaired. That brings up an interesting question, who or what is the final arbiter of the plane's airworthiness, usually it is the pilot. Did the crew know the full list of mechanical issues? Did they know the alarm's were disabled? Did they decide to fly anyway? What about the maintenance crew at the airport? Did they have the information or were they solely dependent on what the mainframe told them? At this point it gets to be a mess of reporting, company policy and trojan-riddled computers.
But in the end the pilots forgot to extend the flaps on takeoff which is as fundamental & possibly lethal a mistake as one could make in a cockpit.
..is always involved (check it out - the 'holes' can line up). But in this case, the failure of any feasible system to detect that two arguing pilots have tried to take off fully-loaded, without checklists, slats, and flaps, and with the warnings of same curiously disabled, does seem to make the 'Trojan' holes rather minor.
More likely pilot error
It wasn't 'tin wiskers" that caused the Toyota crashes it was driver error/incompetence/stupidity/lack of skills.
It could be the same issue or a mechanical issue with this airplane crash. It's extemely unlikely malware was the true cause of the crash but if people can escape accountability, then they will try any theory.
Before you all blame Windows
Ask yourself this.
Why was the Airline's computer in a position to *have* a trojan. Surely any computer that is responsible for running systems that can put people's lives at risk should have all possible entry points for a trojan locked down.
What I mean is it should be on a private (ie not accessible to the internet) network and have all all ports and all removable drives disabled or removed. Also any rights to run *anything* apart from the software used for monitoring the other systems should be removed from everyone apart from the administrator. The Administrator account (which should use a non-standard name, not "Administrator") should have a suitably strong password. You also may need a good virus checker (updated regularly from a secure internal server), but get the access restrictions tight enough and the need for a virus checker goes down massively.
Remember than *any* os can be compromised by a trojanm be it Windows, Linux, OSX or something Unix based. They all have flaws, and the threat from those flaws can be reduced massively (if not eliminated) by following the above advice.
Perhaps planes should run on Macs, until they tell us not to "fly it that way".
"any such software should watchdog itself"
How does a watchdog help in general ? Surely a basic watchdog only helps in a failure mode where the computer system is basically unresponsive for some reason (or had you something else in mind)?
Watchdogs in general are for the nice simple brainless failure modes e.g. where a component such as a power supply fails and the watchdog consequently says "better switch the standby into master". Yes you can use the same hardware mechanism to cause a transfer of control if the software decides all is not well, but how does it define "all is not well"?
Watchdogs in general are token gestures, cosmetic offerings, often promoted and accepted by people in positions of authority who don't understand (or prefer not to think about) the actual more troublesome failure modes in modern safety-related computer systems.
Watchdogs are relics of the time when hardware was unreliable and software was simple. Those days are long gone (though hardware does still break), but industry practice hasn't necessarily caught up yet with the level of complexity in many modern software systems in planes, trains, automobiles, etc.
How does a watchdog help in (for example) the failure modes where the system requirements or design or autocoder or compiler or config manager or whatever got something slightly but catastrophically wrong, and nobody noticed till it was too late?
***NOT*** a mission-critical system, folks!
The malware infection happened on the central airline server which was logging fault tickets. This is not a mission-critical system.
Sure, after the fact we can find that since this was the third issue on that plane, the plane would have been pulled. That's absolute coincidence though, and has zero relevance to the crash. But no - umpteen idiots jump on the "don't use Windows on a critical system" bandwagon.
The cause of the crash was massive pilot incompetence, pure and simple. It was compounded by an equipment failure which didn't warn them how totally stupid they were being.
Blaming this for a failure where the pilots were massively incompetent is totally missing the point.
Fail for the pilots. Fail for the company who's not maintained their planes properly. And MAJOR FAIL for the "don't use Windows on a critical system" f***ing morons.
"the pilots tried to take off without flaps "
Can't things like flap actuators etc be checked visually without relying on computers etc?
Actually, maybe that's not a fair question.
If (as TRT ponders) there was an *intermittent* fault with the flaps, an initial visual check may have said "all OK", and yet a later flap-setting request may have failed. In which case why wouldn't the earlier-noted intermittent flap fault be reason to ground the plane immediately?
Lots of questions, not many answers (and a post submitted on Saturday still awaiting moderation?)
@RPF: "maintenance manual" vs "logbook"
Thanks for the insight on what actually happened.
Can you (or anyone else in the know) expand on the difference between "maintenance manual" (which you say must be paper for anti-tamper reasons) and a "logbook" (which the earlier Boeing reference seems to say can be part of an "electronic flight bag", which can in principle be an ordinary laptop?).
Google seems to think that the term "maintenance manual" is mostly used (by Boeing) for what UK car owners might call the "Haynes manual" of how and when to maintain things - a fixed document, mostly unchanging. The fault and service history is presumably frequently updated and therefore in a different document?
@RPF: "maintenance manual" vs "logbook"
Manual is what the mechanics read when they maintain and fix the thing, logbook is where the pilots log flights and any special events occurred during them.
(Not an airline pilot but a night-rated private one myself.)
Nice to see someone actually understand a bit about these incidents. Indeed it's a grave pilot error to attempt take-off with flaps retracted but that does happen. If the take-off configuration warning isn't operational then there's nothing to tell the pilot that something's wrong until rotation, and by that time it may already be too late (going to fast to stop, too slow to fly with clean wing). The ground roll doesn't "feel" any different.
crappy "forum" software hiding recent posts?
To anyone who like me normally only reads the most recent page of posts:
The "most recent page of posts" doesn't necessarily contain the most recent posts.
Because of this insanity, you may have missed out on some very relevant info on any multi-page topic e.g. here you may have missed the important posts from Brian Morrison, which El Reg's crappy forum software hides on the first page.
Because of this feature, readers wishing to reply to an "old" post and wanting their contribution to actually get read may prefer to ignore the "reply" button and instead just tack the post on at the end of the thread, quoting where necessary.
Re: crappy "forum" software hiding recent posts?
I think you're asking for an un-threaded view, so that each post regardless of whether it's a reply to another or a "new" one appears in strict chronological order.
Noted. In the immediate term, while far from ideal, the (Atom) feed for each forum does provide that.
As is almost invariably the case in all catastrophic failures
there is no single root cause of the problem. There were MULTIPLE points of failure:
- air service crews
- IT staff
- IT planners (Windows is a real-time system, and as a lowly help desk worker I help support it in my work environment but it shouldn't be in the control tower.)
All of them are equally guilty of killing 174 people.
Jeeeezers - came back as Goatse.
I like computers - I like it when they work.
I however do not like them in aircraft - as the PRIMARY means of controlling it and staying in the air.
I like HARD mechanical systems - like hydraulics, "open valve, close valve, open valve, close valve, open valve, close valve" like what the retard Homer Simpson enjoys.
I also do not like aircraft that are designed to be 99.9999% efficient - and ONE little thing goes astray and they become like a dart in a pub fight.
An infectable operating system on the aircraft?
Using Microsoft ANYTHING on a fucking aircraft?
Yeah Yeah - lets just reboot and run a 10 scans for spyware and malware and trojans and christmas tree lights and what ever else the fuck runs on Windows.
Lets just hope the wings don't break off at Mach 1.2, for an aircraft that was designed to run at Mach 0.9... as we spear towards the ground from 30,000 feet.
You fuck up the lives of millions of people - Hang them - Straight out.
"insufficient patching on the Linux environments"
Tell me, o wise one, was it the Linux OS that was needing patching, or was it perhaps PHP or SQL or some Adobe software or whatever? Not saying the Linux OS never needs patching, that would be silly. But I too watch vulnerabilities and patches for both Linux and Windows. And I see a lot more failures for the Windows OS than I do for the Linux OS.
@AC - 11:47
These were linux kernel vulns allowing privilege escalation.
CVE numbers or it didn'ae happen
Oh, right. Privilege escalation meaning you already needed to be a locally authenticated user. And how many other Linux OS exploits were there allowing remote code execution (ie on *your* system) by unauthenticated users?
How many of that class of exploit has Windows had? How many does Windows *still* get?
How many authenticated users would there be on a typical Web-facing system of the kind you were talking about, o wise one? If users aren't authenticated to log on locally, how many remotely-accesible exposures are there in the Linux OS (excluding PHP, SQL, etc).
Sorry, Bill loses, on web-facing systems and elsewhere, on security and on reliability and elsewhere. Not my words, ask the folks who run real Internet-facing systems, as polled by Netcraft.
http://news.netcraft.com/archives/2010/08/11/most-reliable-hosting-company-sites-in-july-2010.html (top ten: all running *nix/BSD apart from one still running Windows Server 2003 at number 5)
http://news.netcraft.com/archives/2010/08/11/august-2010-web-server-survey-4.html (Apache with twice as many servers as Microsoft).
Windows is not intended as flight critical software. Nor Linux. Nor solaris.
Ahem. Someone is lying.
From my now dusty memory of commercial avionics there are 18 fiery hoops to be leapt through to make flight critical software. None of them begin with 'insert tour off your windows/linux/solaris dvd into a dvd drive.
It is not likely to be true that the as intended design was to override needed maintenance. Lots of engineers earn their pay calculating the impact of maintenance and maint intervals on the probability of Aunt Millie getting killed in a crash.
Those calcualtions assume warning sytems, pre flight checks of critical components.
That are checked on every takeoff. They are commanded up. And down. Except in Spain. Now someone wants to blame the erp system at least until they can make their getaway.