On Mon, Mar 26, 2018 at 12:19 PM, Paul Winalski <paul.winalski(a)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
ᐧ