[TUHS] long lived programs (was Re: RIP John Backus
clemc at ccc.com
Tue Mar 27 11:08:11 AEST 2018
On Mon, Mar 26, 2018 at 12:19 PM, Paul Winalski <paul.winalski at gmail.com>
> 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
DEC, Masscomp (being ex-DECies) and eventually Sun took that same promise
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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the TUHS