Posts by Primus Secundus Tertius 1535 publicly visible posts • joined 31 Oct 2010
Who needs a backdoor when the authorities can demand the password on pain of imprisonment?
This happened in the UK a year or two back. An Islamist who had 'forgotten' his password realised he was facing prison, and then 'remembered' it. Too late though: the offence was committed when he refused the original demand, and to jail he went.
Blair wrote.
"You idiot. You naive, foolish, irresponsible nincompoop," Blair wrote of himself in his autobiography A Journey last year, recalling his adoption of the law, which took effect in 2005. "There is really no description of stupidity, no matter how vivid, that is adequate. I quake at the imbecility of it."
He could equally have been writing about the Yuman Rights Act passed by his Labour government.
@The Mole
You are right that a complete record must have that validity between fields that goes beyond checking for zero, not letter 'O'. (And date formats need to be enforced, essential fields must not be omitted...) But each field has to be validated first, which an XML schema can do. The next stage needs a program.
The kind of Excel input I was discussing can do that, of course. So can whatever program is on the receiving end after it has used a library function to capture the XML into a record in C, COBOL, or whatever.
@SD3
Some organisations use XML for data transfers internally or with suppliers and customers. The XML must be declared valid against a pubished schema, and that can be written into a contract. It should cope with the kind of input errors that you describe.
No, people don't write XML, software does. Excel can be provided with a template, designed by an XML guru, so you type in to a sensible form that will bellyache if you get it wrong, and then export the rigorous data.
Or so I understand. I have experimented with XML but not used it for real.
@McNasty
The fact remains that ten thousand people were affected with delays of up to a day, and politicians as our representatives are fully entitled to complain about that.
Yes, I agree with the comments that running a system at 99% capacity means that one small problem cascades into many bigger ones. There is a rule of thumb that systems should be run at 2/3 to 3/4 of capacity. But as others remark, try explaining that to beancounters or indeed to politicians who set our taxes.
Computer systems have always demanded high reliability from their components. Originally we needed valves that did not pop every few hours: the MTBF of a system with a thousand valves would be a few seconds.
Nowadays the problems are with the software: that is, with logic on a large scale. Not many people are very good at large scale logic, and at breaking down a large problem into smaller ones. You certainly don't find that ability by hiring the cheapest contractor.
People have complained, rightly, about the poor quality of machine generated TV subtitles. It would be useful to test the speech decoding of this MSFT system with those subtitles.
Even better if they could get it to take useful minutes of meetings comprising: subject discussed, principal arguments for and against, decisions taken, actions placed.
It seems that a faulty flight plan caused the FP server to fall over.
Looks like poor error checking of input data. But it takes a good programmer/designer to produce good error checking: he or she has to scope out a range of error cases surrounding what is valid input, otherwise bad data just crashes the program. Which is what may have happened here.
That means hiring a good designer/programmer rather than the cheapest contractor.
The phrase "Air Traffic Control" illustrates the control freak mentality behind the whole current setup. What we need are just two relatively simple functions: a collision avoidance function, and a priority function for take-off and landing. Let all the other details sort themselves out automatically.
With that approach, NATS could indeed be replaced by an iphone on every plane.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
