The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: paul.winalski@gmail.com (Paul Winalski)
Subject: [TUHS] long lived programs (was Re: RIP John Backus
Date: Mon, 26 Mar 2018 12:19:44 -0400	[thread overview]
Message-ID: <CABH=_VSQpX+wid5_nE3OUjTCJQ2njY+hWwBQQDXamu65HUqa9A@mail.gmail.com> (raw)
In-Reply-To: <D51BFDAA-889B-4A9F-BAA4-8A961FFB7F8D@tfeb.org>

On 3/26/18, Tim Bradshaw <tfb at tfeb.org> wrote:
> On 23 Mar 2018, at 19:28, Bakul Shah <bakul at bitblocks.com> wrote:
> Retail banks are risk-averse so they like to avoid the risks associated with
> porting the thing to new platforms.  And since there's no development most
> of the developers leave.
>
> And then ten or twenty years later you have this arcane thing which no-one
> understands any more running on a platform which is falling off the end of
> support.
>
After grad school (1978) one of my first job interviews was for a job
as system manager for an insurance company.  Their data center took
the "don't risk porting software" to an extreme.  As new technology
came out they bought it, but only to run new applications.  Existing
applications were never ported and continued to run on their existing
hardware.  Their machine room looked like a computer museum.  They had
two IBM 1400s (one in use; one was cannabilized for parts to keep the
active machine going), two System/360 model 50s, with a drum and a
2321 data cell drive.  Their only modern hardware was a System/370
model 158.

Operating systems seem to have taken one of two policies regarding
legacy programs.  IBM's OS and DEC's VMS emphasized backwards
compatibility--new features mustn't break existing applications.  VMS
software developers called the philosophy of strict backward
compatibility "The Promise" and took it very seriously.  Unix, on the
other hand, has always struck me as being less concerned with backward
compatibility and more about innovation and experimentation.  I think
the assumption with Unix is that you have the sources for your
programs, so you can recompile or modify them to keep up with
incompatible changes.  This is fine for research and HPTC
environments, but it doesn't fly in corporate data centers, where even
a simple recompile means that the new version of the application has
to undergo expensive qualification testing before it can be put into
production.  Which philosophy regarding backwards compatibility is
better?  It depends on your target audience.

-Paul W.


  reply	other threads:[~2018-03-26 16:19 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.21.1521314548.3788.tuhs@minnie.tuhs.org>
2018-03-17 20:14 ` [TUHS] " Paul McJones
2018-03-17 22:27   ` Steve Johnson
2018-03-22 21:05     ` [TUHS] long lived programs (was " Bakul Shah
2018-03-22 21:35       ` Clem Cole
2018-03-23 19:28         ` Bakul Shah
2018-03-23 19:44           ` Larry McVoy
2018-03-23 21:23           ` Clem Cole
2018-03-23 21:36             ` Warner Losh
2018-03-23 22:02               ` Steve Johnson
2018-03-26 13:43           ` Tim Bradshaw
2018-03-26 16:19             ` Paul Winalski [this message]
2018-03-26 16:41               ` Arthur Krewat
2018-03-26 19:53                 ` Larry McVoy
2018-03-27  1:08               ` Clem Cole
2018-03-26 19:04             ` Bakul Shah
2018-03-27  1:21             ` Steve Johnson
2018-03-27  1:46               ` Clem Cole
2018-03-23 10:43       ` Tim Bradshaw
     [not found]         ` <CAC20D2P1CZwaD0uJpMhWg11muDeH9rEn3X+AUjXvwMKsNjs7ng@mail.gmail.com>
2018-03-26  0:53           ` [TUHS] Fwd: " Clem Cole
2018-03-23  2:53 [TUHS] " Doug McIlroy
2018-03-23 18:27 ` Bakul Shah

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CABH=_VSQpX+wid5_nE3OUjTCJQ2njY+hWwBQQDXamu65HUqa9A@mail.gmail.com' \
    --to=paul.winalski@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).