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