On 07/02/2014 12:18 AM, Patrick J. LoPresti wrote:
On Tue, Jul 1, 2014 at 5:09 PM, jdow j...@earthlink.net 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.
