On 07/02/2014 12:18 AM, Patrick J. LoPresti wrote:
On Tue, Jul 1, 2014 at 5:09 PM, jdow <[email protected]> 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.

Reply via email to