[TUHS] long lived programs (was Re: RIP John Backus

[bakul@bitblocks.com (Bakul Shah)]

> On Mar 26, 2018, at 6:43 AM, Tim Bradshaw <tfb at tfeb.org> wrote:
> 
> On 23 Mar 2018, at 19:28, Bakul Shah <bakul at bitblocks.com> wrote:
>> 
>> By now most major systems has been computerized. Banks,
>> govt, finance, communication, shipping, various industries,
>> research, publishing, medicine etc. Will the critical
>> systems within each area have as many resources as & when
>> needed as weather forecasting system Tim is talking about?
> 
> I think that this is indeed a problem: it just isn't a problem for the kind of huge numerical simulation that gave rise to this thread.  In general programs where

I started thinking about Fortran programs but soon expanded to
the more general problem.
> 
> - you continually are looking for more performance,
> - you are continually updating what the program can do (adding better cloud models, say),
> 
> are pretty safe.  But programs which get deployed *and then just work* are liable to rot.  So, for

Even here attention can flag over time.

> And if that was the only problem everything would be fine.  In fact, several times during the life of this thing, the bank wanted to offer some new kind of mortgage.  But no-one understood the existing mortgage platform any more, *so they deployed a new one alongside it*.  So in fact you have *four* of these platforms, all of them critical, and none of them understood by anyone.

This is the modification problem I was talking about. Running an
unchanged binary on an emulated processor is much easier.

> 
> To bring this back to Unix history, I think this is an example of a place where Unix has failed (or, perhaps, where people have failed to make use of it properly).  Half the reason these things are such a trouble is that they aren't written to any really portable API, so the bit that runs on Solaris isn't going to run on AIX or Linux, and it only might run on the current version of Solaris in fact.

1) This is when the OS doesn't live as long as the application.
2) The rate of change in open source technologies is far too high.
   Open source is often open loop. Hundreds of bugs remain unfixed
   while a new feature will be added.

> I don't know what the solution to this problem: I think it is essentially teleological to assume that there *is* a solution.

It is an interesting problem even if there is no clear solution.
But now I think may be it doesn't matter in the long run.  We
will let our new AI lords worry about it :-)