rwessel (robertwessel.delete@this.yahoo.com) on January 31, 2017 12:29 am wrote:
>
> Well, given Linux's heritage, the dirty and referenced bits on S/360 are certainly odd
> (as they're attached to the physical page and not the TLB entry). Having some of the protection
> bits attached to the physical page probably also annoys the Linux kernel...
>
>

It was interesting to read the observation overhead, about the 'shadow' of the old Windows NT operating system, still remaining visible in the micro-architecture of the x86 central processing unit. Even though, certain things had been removed from the Windows NT kernel, which didn't operate very well inside that micro-architecture. It's interesting though, where these 'shadows' of older operating systems can sometimes appear - at both micro-architecture, and macro levels of things. It's becoming increasing important, from the point of view of software engineering and software architecture, as a whole, to understand this.

I was viewing a movie about an oil rig drilling in the gulf of Mexico in 2010 recently, and it brought me back to the evidence gathered from one of the electrical technicians who had managed to escape from that burning inferno - literally by diving off the platform with one working leg, and one working arm - and he somehow managed to swim clear of the fire and get picked up by a rescue craft. It was only his survival against the odds, which meant that we got to listen afterwards to what he had to say. His comments later on the record about the drilling system of that same vessel and his senior electrician who had worked for months, in order to try to deal with an old NT4 software to control the equipment, were illuminating about just how long these technologies can remain embedded into systems that are highly critical, and also very high risk. They'd actually tried to install a whole new operating system, servers the lot - but they couldn't get the old software that came with the original drilling package - to work on the new operating system. Hence, the senior engineer who didn't make it to safety, had been working on the old NT4 software, right until the end when the disaster had occurred.

I don't know at what point, that the discipline of software engineering is going to be able to admit a lot of this stuff to itself - and confront it, in the idea that it's an issue - and will probably need to branch off in the near future, into it's own sub-discipline of software engineering itself. Like, there's a lot of blustery talk around nowadays about the 'internet of things'. The gushing and euphoric explanations about household control devices, and things that connect back to Apple watches and the like. But what happens, when the 'thing' in question, happens to be an oil drilling rig for example? There seems to be no rush forward to try and tackle that challenge. It is a sobering, sobering realization, and I think that software at some stage is going to have to deal with it.

I will offer one suggestion, and it comes from observations in the heavy engineering area too, which is getting re-invented in many kinds of ways, for this new century. One can never overestimate, the level of over-confidence that decision makers at the top of the hierarchy, are will to place in technology that lies down at the bottom of how things work, and really isn't fit for purpose any longer. One can never under-estimate that. And this isn't getting better as we move forward, if anything it's getting a lot worse, as we throw more and more complexity into these systems - and expect them to leverage out more and more results and functionality - often beyond, far beyond the scope of what they were originally intended to do. Over and out.