On 2014-07-01 08:16, Patrick J. LoPresti wrote:
> On Tue, Jul 1, 2014 at 6:17 AM, Lamar Owen <[log in to unmask]> wrote:
...

>> That's part of the
>> reason the CentOS team has changed the statement '100% binary compatible' to
>> 'functionally compatible' since they do mean different things, but the
>> latter is more indicative of reality than the former ever has.
>
> The *goal* of CentOS used to be binary compatibility, even if it was
> never 100% achieved. Since the acquisition by Red Hat, that is no
> longer even the goal, for obvious reasons.

Pat, this is nominally impossible with modern compilers as I discovered a
long time ago. The compilers I am used to embed a time stamp in the various
files compiled. This time stamp will differ between machines used to compile
the code. So when you perform the binary compare you will hit errors. The
compiler on which I discovered this first (Microsoft C7) the embedded dates
were not even the same length. So once I hit that difference the binary
compare was broken for the rest of the file. If GNU C has this same feature
prattling about binary identity and so forth is nonsense.

...

>   - Pat
>

It is good that some of these issues are being aired. But some of the issues
raised smokescreen other more pertinent and substantive issues such as RHEL
traceability. (In the hardware world I infested long ago all test equipment
had to be calibrated in a manner traceable to NBS (now NIST). That issue was
solved.) This RHEL traceability issue is significant as is traceability back
to creators for non-RHEL code replacements for RHEL proprietary software and
for any add-on software provided by sources in the path from SL back to RHEL.
Fussing about binary compatibility is needless obfuscation.

The issue at its base is "who do you trust"? It helps to know who is asking
you to trust when you make that decision.

{^_^}   Joanne