Re: Public sector IT
"I think I've found the problem"
I think you've found two.
42665 publicly visible posts • joined 16 Jun 2014
"a lack of will by the Government Digital Service under Kevin Cunnington's leadership"
Was that all that was lacking?
Latest example of GDS's efforts: go to site to make an appointment suggesting several different slots which,according to the online diary, were available. A few minutes later there's a call back to say none of them were available; the office diary isn't linked to the GDS online version which is consequently out of sync with reality.
"When stuff like tellies in the home were too expensive to buy, people got them on the never never instead."
Your ability to pay off the TV loan didn't rely on your watching the TV so it can be assessed on your earning history.
The ability to pay off an R & D cost relies on the outcome being successful to create future earnings. That means there's no history on which to rely. You won't be able to go to a hire purchase company for that. The people who'll be lending money on that scale in that sort of way are going to want your first-born a slice of the company. It's called venture capitalism and the pre-IPO spin and PR are also factors in the VCs being able to get their money back. They won't see R&D and PR as alternatives, they'll see them as complementary.
In order to perceive distance you first have to perceive the objects in the visual field. That in turn involves edge detection. Then you have to correlate the relative positions of the objects as seen from the two eye points and the feedback from the muscles controlling the eyes. It's all massively parallel - some of the processing seems to be done in the retina itself. And none of it is conscious so I'm not sure that the I bit of AI applies.
The precedent that it "should" work is that it is how us humans do it.
The way we humans (and bats) do it is by having massively parallel processing available. You're right to point out that it's not only distance but also speed that matters. Both of those give timing and that matters even more. You don't mind occupying the same piece of road that another car will occupy but you really don't want to occupy it at the same time.
"it is freedom from the ECJ that tends to get emphasised at the moment."
That's the easier one for her to deal with. ECHR raises issues with the Good Friday Agreement. But with the two sectarian parties supposedly sharing government in N Ireland falling out and all sorts of questions over the border she might be able to weasel out of that one as well.
"So... because we might want to fly in the EU, we should adopt their regulations? That makes no sense whatsoever. What rules we follow domestically does not dictate the rules we follow in other countries."
IFAICS what you're saying is that instead of having one set of regulations we could have two? That'll simplify things, take back control, cut red tape and [insert pro-Brexit slogan of your own choosing].
"I dont understand where the problem is. Before the EU we wrote our own regs. Our own regs are so good the EU adopted a number of them. How is this a legitimate problem? Or do you have some kind of xenophobic problem that people in the UK are too thick to function?"
From TFA: "The [UK's Civil Aviation Authority, the CAA] hasn't got the capacity or the expertise to provide an effective standalone aviation regulatory organisation. It did have, 20 years ago, but we've sacked three quarters of the people. And the expertise... has gone to join EASA,"
Of course we could try offering suitable salaries to tempt them back. Repeat that over and over for each situation where that happened and see how much change is left over from all that money we save by not paying into the EU budget.
the often quoted "90% of NHS Trusts still running XP".
And that in its turn seems to have come from a survey - I think a year or two ago - of trusts running at least one copy of XP. The fact that this might actually be just one is beyond the grasp of our mighty national newspapers.
" In addition to being resilient to attack a VM can run on modern hardware, it's not limited to antique machine like native XP."
You do realise, don't you, that in some cases you're dealing with real time S/W that twiddles bits directly on specialised H/W?
"But the problem is not so much that support was stopped for XP, it's that hardware like this should never have been based on XP in the first place. It isn't Microsoft's fault; it's the fault of the developers of the hardware."
The developers were probably in a bit of a bind themselves. The introduction of commodity H/W and S/W killed off the minis and Unix workstations that were used previously. Even if it hadn't it would have enabled competitors to have undercut any who still used such kit.
What would have helped would have been the certification authorities requiring long term support. That would have either required MS to offer it or, if they didn't, would have levelled the playing field and allowed specialist workstation manufacturers to survive. That in turn would have needed the certification authorities to have anticipated the situation we now have.
"To provide full support for all its old systems MS would have to have large numbers of programmers trained up in those systems (no one person can know more than a small part of code that big)."
They could save money. They could ship better code in the first place.
And your general thesis founders on a single fact. They have already issued a fix.
"So how do they open source the code without revealing 80% (guess) of their code still used?"
They can't open source it in the FOSS sense which I think is what the OP meant.
What they can do is put the source code, including patches, into escrow. If the vendor turns their toes up or if they cease support then the source can be released to specified interested parties wrapped up with whatever conditions were mutually acceptable when the original transaction was entered into. I've seen that made a condition of an RDBMS installation.
Another option would be to make the source available to interested parties all along under NDA conditions. I've had one gig where part of the source was exposed like that, the user interface being the main part that was concealed. It served the vendor well as they got free debugging.
"However you cannot expect a vendor to continue to support the product indefinitely since it is in no way a cost-free activity."
We're looking at a fault which should never have been present in a shipped product. Are you saying that if they manage to get away with it for x years they get a free pass if it brings the house down in the future?
"Yes it is slightly more complicated, but once you've worked out the details you can semi-isolate lots of similarly challenged pieces of kit. (Perhaps the chaps at http://www.nhsbuntu.org could help you set it up.) Yes, it isn't perfect isolation, but it is a perfectly valid component in a layered defence. Yes, it is a pain in the butt,"
And yes, it it impinges on any certification the original machine requires than either you've got to hold off for a few months while that's sorted out or simply shut down for that period.
"Those PCs were sold with Windows 7 Professional + downgrade rights to Windows XP, so there weren't even any licensing issues about upgrading and getting continued support."
The PC and its OS in such a situation is likely to have been only a component in a larger system, a system which required XP because some client/server application were the client end won't run on a later version.
You inevitably end up having to consider a more complex situation where simple solutions don't work. Yes, tou could argue that the original system shouldn't have been put together that way. Maybe it wouldn't have been if the original developers only knew what a later OS version was going to break.
The real world is much more complex than all these "simple" solutions everyone keeps coming out with can handle.
Another characteristic of the real world is that evaluating each "simple" solution for each individual case takes time. Half a dozen individual installations with unique, complex requirements could take a lot longer to update than a large office of routine desktops with a common build.
"Of course 16 years is too long to expect a company to support a product"
There's a difference between supporting a product in terms of adding new functions or drivers and fixing a defect which was present when the product shipped.
But let's not lose sight of the fact that when the shit finally hit the fan MS made a fix publicly available within hours.
If they were under no obligation, it was too long to expect them to do it etc then why did they do it?
I can think of three explanations:
1. It was to mitigate a PR disaster.
2. Events brought it home to them that they had a moral rather than a commercial responsibility.
3. They anticipate legal action and are attempting to mitigate any penalties.
I don't think the last one flies - it simply points out the fact that they'd held back something that could have been made generally available.
But let's not lose sight of the fact that for whatever reason they have done what lots of commentards have said they didn't have to do.
"OTOH should we also be looking at the suppliers of MRI scanners etc which are often blamed for being the cause of 'staying on a known OS'. They ought to be obliged to release software for newer versions of their chosen OS (whether that's MS/OSx/*nix/*BSD/....) for the expected lifetime of the machine (probably more than the expected life actually)"
A recent post by an engineer who's worked on such kit suggests that this is by no means straightforward and you could actually brick the instrument by getting it wrong. At the very least you'd have to re-certify the new combination.
"The lawyers have more chance of getting Comey his job back that getting MS to admit to anything."
It's not the lawyers' job to get their clients' opponents to admit anything. Their job is to get a court decision in their clients' favour. An admission might be useful but not essential.
"I agree completely. Your last point is interesting though - if this were OSS or M$ had decided to open source the code at end of life, then governments & corporations around the world would have had the *option* to build their own in-house support for the product."
It wouldn't be necessary to open it in the FOSS sense but to place it in escrow. The terms for release from escrow could place an NDA on whoever then took up maintenance. This would be a sensible provision where it's been incorporated in a product whose reasonable life expectancy exceeds the support life of the product. It's maybe something that regulatory authorities could require for medical equipment in the future. If an OS vendor was unwilling to do this then the equipment supplier would be obliged to go elsewhere.
Microsoft could agree or not as it pleased. If it judged the market too small to bother about that would be their commercial choice. If they chose not to remain in that market the equipment makers would be free to look elsewhere. Give or take proprietary drivers FOSS fits this bill automatically. There would be scope for someone to offer support well beyond the normal life of an LTS distro as a commercial proposition. An existing proprietary embedded Unix derivative such as QNX or VxWorks might also be a good fit.
"It's possible that the patch was built in February as part of the general build process but not pushed through QA because it was unsupported code. Or perhaps it was only available to those paying for extended cover"
The second comes as has been said already. But if it was only available to paying customers why release it publicly now? The only two explanations I can think of are that they realised it was the responsible thing to do or that it's an attempt to remedy a PR disaster. You can take your pick butin reality it's a case of better late than never but better never late.
"I disagree: the principle operation of the product was to provide an O/S, which it did (rather well at the time as it happens)"
One of the functions of an operating system is to provide a degree of security.* It's not like arguing that a lock is a subsidiary function of a car. And that gains even more force when one of the products was a server rather then the desktop OS.
*Or are my expectations being warped here, coming from a Unix background?
"Supporting former customers for free is a sure-fire method to increase your expenses and reduce your profits with no gain for you."
Letting stuff like this fester until it manifests itself by large scale damage is a sure-fire way to make people ask whether they should become future customers. That's not exactly a gain especially when those "former customers" are also your current and hoped-for future customers.
Car analogy: Vehicles were sold 15 years ago and their brakes are knackered. Customers are told "you can only get them fixed if you pay a mechanic"
Car was sold 15 years ago with an egregious design fault..
We're repeatedly told here by commentards that the product was supported for 13 years. So why during those 13 years was it not found and fixed? In all conscience 13 years ought to have been long enough. It sounds like the sort of thing that any static code analysis tool should have highlighted.
"don't expect those companies to open source a lot "
No, but they do need to place their code in escrow so it can be picked up by others should they decide they don't want to support it, be taken over by someone else who doesn't want to support it or even just disappear without trace. That should be a regulatory requirement.
"2)Did it even need Windows or could it have just had a GUI that looked and worked enough like Windows that healthcare staff felt comfortable using it (IOW who cared if it couldn't run Office?)"
Originally makers of complex kit that needed to be computer driven had a number of choices. Some would be embedded controllers with their own specialist libraries. Another would be a mini such as a PDP8 or a Nova (I remember our lab having a Nova driving the X-ray fluorescence analyser on an SEM). Back in its glory days of being an instrument maker HP made an amazing variety of these for its own products.
The arrival of commodity computers and commodity OSs rendered that uneconomic. Any manufacturer taking the traditional route would have been priced out of the market. Even if they had they'd have ended up shipping kit that had even less long time support life - where are DEC and DG these days?
The trouble is that as the market for complex instrumentation matures the expected life of the product exceeds that of the computing side. Back in the '70s that XRF attachment might have become obsolete before the Nova was EoL, now a piece of equipment which represents a major investment might be expected to last well beyond the period for which the OS supplier is prepared to support their S/W and the computer H/W may outlast the S/W and yet not be supported by newer OS versions. In such instrumentation systems computer H/W is liable to be closely integrated with the rest of the instrumentation. I think the XRF was using the Nova's memory to replace what might have been an array of discrete counters in an earlier generation and the post by a_builder in a previous thread detailed some of the issues in medical imaging.
Perhaps a solution, at least with medical equipment, lies with the regulatory bodies. They could require a code escrow agreement for the OS code in order to gain approval. That would have required MS to escrow their code if they wanted to sell into that market so that someone else could take over support at EoL. For the most part FOSS already complies with that although vendors supplying drivers as binaries would need to comply or shut themselves out of that market.
For kit that needs certification upgrades are another problem. Any upgrade to S/W that operates the instrument would need recertification. Routine OS upgrades couldn't be applied without testing against a real instrument. Such S/W needs to be buffered against the wider hospital network.
This last event and the earlier attacks on US hospitals point to a need to reevaluate the way medical systems are certified. One aspect of this would be to require information systems, including the network facing aspects of imaging systems etc, to be re-certified every few years and part of that would be to require them to be running of S/W which was still within support life for the duration of the next certificate. That, had it been the norm, would have long ago weeded out system that still require ancient versions of IE; it would have driven suppliers to write standards compliant S/W from the start.