[COLUG] Re: colug] Binary Compatibility - was Open Solaris and the Borg

[R P Herrold]

On Wed, 1 Nov 2006, Stephen Potter wrote:

> <quote who="R P Herrold">
> [This was me, Steve, not Steve, Currie]  ;-)

namespace collisions abound   ;)

>> on a distribution that expressly advertises itself as
>> experimental and NOT suitable for SLA's, you expected ... ?
>
> Ok, so using FC as an example was probably not the best.  I'll grant you
> that one.  ;-)  Even so, is it really that much to expect common, simple
> things like IMAP will continue to work without me having to spend an hour

wow -- having been on the IMAP standards RFC group mailing 
list for like a decade, I assure that that standard, and Mark 
Crispin, its lead proponent, and Larry Osterman, the former 
representative from Microsoft (with their radically different 
implementation approaches (mbox vs. a database) have the welts 
and scars on interpretation of the dark corners of the 
protocol to prove their dedication to interop -- several 
extensions and optional behaviours -- a real snake's nest.

> fixing the configuration file because the format changed and it doesn't
> provide proper error reporting?

sounds implementation specific -- Red Hat's move to the new, 
partial, and immature 'dovecot' was a triumph of political 
will over demonstrated functionality.

> However, my point still stands that I can't trust upgrading Linux boxes
> without going through a fairly lengthy process of retesting, fixing, and
> recertifying.

How does that differ from any other upgrade?  ANY change will 
trigger requalification needs, and Change Control involvement 
-- the 'guestimation' that it will be a minor vs. a major 
headache is just that (and drives the level of pre-roll out 
testing resource allocation - sometimes wrong, sometimes all 
right) -- a guess, until it gets deployed;  then one gets to 
see how well the reversion plan works ;)

>>>  Linux 2.4 to 2.6 was a completely incompatible change.
>>
>> The kernel change may have been completely incompatible for
>> you on a binary basis ... dunno .. but FOSS is about available
>> source, and being able to port and build
>
> I have 8000 Solaris servers running thousands of applications.  Imagine
> how much effort it would take to go through all of those servers and
> recompile the binary, test it, port the changes that someone made on a
> whim without any engineering thought, recompile (again), test (again), and
> redeploy.

*cough* testing harnesses, suites, and such -- the LSB test 
suite will absolutely detect use of non-standards based 
extensions beyound its assured availabilities; the response 
when a 'violation' probably depends on the relataive market 
power of the vendor and the purchaser -- layres 8 and 9 of the 
ISO stack.

>> A single infinitely backsupported
>> 'binary compatability, through a set of static linking
>> libraries, addained by dragged around a la the 68000 -> PPC,
>> and now PPC -> x86 approaches of Apple, are (to me) just a
>> symptom of a sick, non-source available culture.
>
> I don't expect binary compatibility to be maintained if the major
> underlying architecture is changed.  But, Apple provides service to its
> clients by easing the change from one architecture to another.  This saves
> their clients real time and real money not having to go through the
> process I outlined above.

a false economy -- deferring staying with the changes makes 
the ultimate effort to merge the fork from current harder, and 
more expensive.  There is a breakeven equilibrium point saddle 
with the sweetspot to find, but the outliers of todays' 
release, and 5 years ago are not where it lies.

> Why shouldn't that be possible from one fairly
> minor kernel version to another?

ummm --- kernel level ABI, and matching compiler and glibc are 
part of the Red Hat Enterprise offerings -- How about NO fixup 
and change needed for up to their present seven year span?

Given that a given hardware lifecycle from Dell, HP/Compaq, 
are tied to 3 year hardware availability assurance, and 5 year 
SCSI warranted drive life cycles, the OS is not going to be 
the constraining factor before the end user community start 
calmoring that 'they are stuck with the old stuff.'

- Russ Herrold