The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: clemc@ccc.com (Clem Cole)
Subject: [TUHS] long lived programs (was Re: RIP John Backus
Date: Mon, 26 Mar 2018 21:08:11 -0400	[thread overview]
Message-ID: <CAC20D2P0RL_eAQYxp0p4zXt6v7r84MycBPpWtn1ax6S_UxfPzQ@mail.gmail.com> (raw)
In-Reply-To: <CABH=_VSQpX+wid5_nE3OUjTCJQ2njY+hWwBQQDXamu65HUqa9A@mail.gmail.com>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2632 bytes --]

On Mon, Mar 26, 2018 at 12:19 PM, Paul Winalski <paul.winalski at gmail.com>
wrote:

> ​... ​
> 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.


​Paul be careful here.   Yes, BSD did that.  I'll never forget hearing Joy
once saying he thought it was a good idea to make people recompile because
their code stayed fresh.

But as UNIX move from Universities to commercial firms, ​binaries became
really important.
DEC, Masscomp (being ex-DECies) and eventually Sun took that same promise
with them.

Linux has been mixed.  The problem is that UNIX is more than just the
kernel itself.  As the SPEC1170 work revealed in the late 1980s/early
1990's - there were 1170 different interfaces that ISVs had to think about
and agreeing between vendors much less releases within vendors was
difficult.

And here is an interesting observation ...

The ideas behind UNIX was (more or less) HW independant.   Just think, how
hard it was for DEC, Masscomp or SUN to keep VMS or Ultrix/Tru64, RTU,
SunOS/Solaris binary compatible.   It's part of why the whole UNIX
standards of API *vs.* ABI wars raged.   It was and is a control problem.

Linux (sort of) solves it by keeping the Kernel as their definition.   But
that really only partly works.   kernel.org streams out new kernels way
faster than the distros.  And the distros can not agree on the different
placements for things.   Then you get into things like Messaging stacks.
 It why Intel had to develop 'Cluster Ready.'   I will not say to protect
the guilty, but one very well known HPC ISV had a test matrix of 144
different linux combinations before they could ship....

Just to give you an idea .. if they developed say on IBM/Lenovo under RHEL
version mumble, but tried to release a binary on the same RHEL but on say
HP gear, it would not work, because IBM had used Qlogic IB and HP Mellanox
say.   Or worse they both had used the same vendor of the gear but
different releases of the IB stack (it gets worse and worse).

The issue is that each vendor wants (needs) to have some level of control.


Clem
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180326/20c7d5d0/attachment.html>


  parent reply	other threads:[~2018-03-27  1:08 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
2018-03-26 16:41               ` Arthur Krewat
2018-03-26 19:53                 ` Larry McVoy
2018-03-27  1:08               ` Clem Cole [this message]
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=CAC20D2P0RL_eAQYxp0p4zXt6v7r84MycBPpWtn1ax6S_UxfPzQ@mail.gmail.com \
    --to=clemc@ccc.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).