On 07/02/2014 12:18 AM, Patrick J. LoPresti wrote:
> On Tue, Jul 1, 2014 at 5:09 PM, jdow <[log in to unmask]> wrote:
>> On 2014-07-01 08:16, Patrick J. LoPresti wrote:
>>
>>> The *goal* of CentOS used to be binary compatibility, even if it was
>>> never 100% achieved. ...
>> Pat, this is nominally impossible with modern compilers as I discovered a
>> long time ago.
> Incorrect.
>

If it's so incorrect, then why is it mentioned in the gnu.org GPL FAQ?

> No, "traceability" is the irrelevant side issue here.

In NTP terms, if I can have a stratum 1 source that's nice, but a 
stratum 2 may be enough for the job at hand.  If I truly need real 
stratum 1 then I need to pay for the proper number and types of 
refclocks to obtain real stratum 1 capability (I have this exact need 
here, and am building out the necessary number and types of refclocks to 
achieve that goal; for non-astronomical purposes stratum 4 or 5 is more 
than sufficient as long as those are traceable to stratum 1 sources, 
such as tick and tock and the various standards maintained by NIST). A 
single GPS-disciplined clock, such as an HP/Agilent/Symetricom Z3816A or 
Z3805 is just not enough by itself.

> Once again, the only relevant question is whether and how Scientific
> Linux can be a rebuild of Red Hat Enterprise *and not CentOS*,...

This remains to be seen.  It may not be possible.  But in order for the 
SL team to accomplish this, traceability to Red Hat of the sources will 
be required, since it is apparent that source RPMs on a public ftp 
server are not coming back any time soon, if ever.  If this traceability 
means that the SL team internally audits against upstream's source RPMS 
obtained via subscription, and they silently release SL7 without 
publicly revealing the results of that audit, will that meet your 
standards?  (My gut feel is that only a rebuild of subscription-obtained 
SRPMs publicly released would meet your standards, but that may not be 
something anyone is willing to do.)

> I trust the Scientific Linux team. Obviously, I do not trust Red Hat
> which includes CentOS. Time will tell how well my trust is placed.
If you don't trust Red Hat then why use their obviously different from 
upstream sources in the first place?  Any straight rebuild of Red Hat's 
sources cannot be more trustworthy than Red Hat's sources, unless every 
line of source code being rebuilt is completely security audited, which 
goes way beyond a typical rebuild.