Re: Clarity on current status of Scientific Linux build
Dear Yasha [...] From a query I posted on this matter to the SL list: 2. Evidently, Singh and other core CentOS team members actually are Red Hat employees, just as the core SL team have been Fermilab or CERN employees (presumably in some cases actually paid by the research collaborations funded by various government agencies through various universities -- e.g., in the USA, NSF or DOE with each PI typically holding a tenure-stream faculty position at a university). Will the core SL team or the core CERN linux team likewise become Red Hat employees? CERN linux team is and will be CERN employees: Our only relationship with Red Hat is that we are customers. To clarify little bit: Our primary mission at CERN is to provide support for linux platform for our customers - experiments and working groups - not to build linux distribution. (yes - we did it in last 10 years since in 2004 this was the only option) End question. Are Jerek Polok et al. now Red Hat employees, or still CERN employees? Yes we are CERN employees: the fact of using this or that linux version does not change it - why would it ? Additional questions: A. Will the SL/SLC source tree for RPM builds be a separate copy from the CentOS git, downloaded therefrom? I am speaking for SLC here: no: we are going to use CentOS. A.1 Will the SL/SLC source tree be compared to the original SRPMs that CERN seems to have under license from Red Hat to verify that the CentOS git source is in fact unadulterated RHEL 7 source, other than for obvious Red Hat logos and the like? Speaking for SLC here: yes, we could do it (so could SL and anybody else), but please note: this does not change anything for everybody else on this list: if somebody decides to distrust Red Hat and CentOS ... why would that person trust us ? ... B. Jarek states above: Whatever the case, there will continue to exist a linux of production quality and of free or affordable cost. That was actually a quote from Konstantin's post- but I fully agree with it. What is affordable cost and to what is this cost to be paid? Red Hat? CERN? Fermilab (technically, the consortium responsible for operating Fermilab as USA federally funded research facility) for USA-based university sites using SL 7? For us at CERN the affordable cost is dedicating some resources (manpower/hardware/network bandwidth/ .. etc) towards support/maintenance (and development only if needed) of a freely distributable linux version matching our computing platform requirements. I do not fully understand your question about the cost to be paid I'm afraid: What is your current cost of using SL ? Why would that cost change if you use CentOS (or SL built with CentOS sources) ? Best Regards Jarek __ --- _ Jaroslaw_Polok __ CERN - IT/OIS/WLS _ _ http://cern.ch/~jpolok tel_+41_22_767_1834 _ _ +41_76_487_9487 _
Re: Clarity on current status of Scientific Linux build
Jarek, good morning: I was unfortunately paged about someone else's hardware problem and happen to be up. On Tue, Jul 1, 2014 at 2:54 AM, Jarek Polok jaroslaw.po...@cern.ch wrote: Dear Yasha Are Jerek Polok et al. now Red Hat employees, or still CERN employees? Yes we are CERN employees: the fact of using this or that linux version does not change it - why would it ? Yasha has occasionally been known to spend a great deal of thought in some very elaborate models of how things work procedurally, that do not always match what is actually going on. Reviewing or clarifying the situation can sometimes reveal some interesting points, so it's not something to begrudge him. Additional questions: A. Will the SL/SLC source tree for RPM builds be a separate copy from the CentOS git, downloaded therefrom? I am speaking for SLC here: no: we are going to use CentOS. There are, for me and for clients I encourage, some very useful features of SL that CentOS never has and, I think, never will support. These especially include the various yum configurations for third party repositories, such as EPEL, repoforge, and rpmfusion. A.1 Will the SL/SLC source tree be compared to the original SRPMs that CERN seems to have under license from Red Hat to verify that the CentOS git source is in fact unadulterated RHEL 7 source, other than for obvious Red Hat logos and the like? Speaking for SLC here: yes, we could do it (so could SL and anybody else), but please note: this does not change anything for everybody else on this list: if somebody decides to distrust Red Hat and CentOS ... why would that person trust us ? ... Because you're aware of the possibly of HTTPS git repositories being surreptitiously replaced and poisoning all downstream builds. GPG tags would help that, GPG signed RPM's and SRPM's also help that. Why would that cost change if you use CentOS (or SL built with CentOS sources) ? Best Regards Jarek For me, at least, I'd lose SL's clear separation of 'vendor' and 'non-vendor' code, and the ease of access to and management of the 3rd paty repositories.
Re: Clarity on current status of Scientific Linux build
All members of the SL user community (including systems users, not just endusers) should be very thankful to Jarek for his clear candor. From Jarek: I am speaking for SLC here: no: we are going to use CentOS. End quote. At this point, unless Fermilab is planning something else, it appears that SL fundamentally is dead. SL is going to be CentOS, so the SL non-CERN community might as well switch to CentOS or to license real Red Hat EL for fee. CERN is no longer willing to invest the resources (human and machine) to support a separate distro. Does Fermilab have the resources to go it alone? SLC evidently will be CentOS with specific additional hardware drivers and software applications to meet the needs of the CERN LHC collaborations, including running the LHC detectors and data reduction and analysis environment. The second point also is in this quote from Jarek: Speaking for SLC here: yes, we could do it (so could SL and anybody else), but please note: this does not change anything for everybody else on this list: if somebody decides to distrust Red Hat and CentOS ... why would that person trust us ? ... End quote. Unless the SRPMs distributed by Red Hat are a misrepresentation, a build from these SRPMs should yield RPMs that are identical (bit for bit, e.g., under a real binary compare) to the installable RPMs provided by Red Hat. Once this is verified, one knows that a build of SL derived from these SRPMs in fact will be a functionally faithful clone of RHEL (specific release and versions in the SRPMs -- functionally faithful because the actual logos, etc., will be different). Red Hat is a for profit corporation, providing source, etc., back to the not-for-profit community only because of a marketing model and/or GPL, etc., restrictive covenants (licenses). However, the for-profit competitors of Red Hat, notably Oracle, are using RHEL source to build a competitor linux distro that Oracle evidently distributes without fee. Thus, Red Hat now is using CentOS. Will CentOS be a faithful copy of RHEL? I personally fear that it will not be to stymie Oracle and the like. The git, etc., mechanism that Red Hat is using presents no obstacle to deep pocket (well capitalized) for-profits such as Oracle, but only an inconvenience. Thus, this model only will work if CentOS lacks some vital feature, or else Red Hat has elected this path for no clear reason. However, if CERN and/or Fermilab actually do compare the CentOS git to the real Red Hat EL SRPMs -- a tedious task unless it can be automated -- there is no reason in my opinion not to trust the CentOS EL source. I do trust that CERN and/or Fermilab personnel will do an honest compare. I am not being paranoid -- I am simply applying the way for-profit USA corporations (such as Red Hat, Oracle, Microsoft, and many others) operate -- and this operation is not in the interest of the commons. [Aside: The closest I have found to such a USA corporation recently operating in the interest of the commons is the apparent promise of Tesla (electric battery automobiles) to release the fundamental energy storage and propulsion technology it uses to competitors at no charge. However, Tesla corporation seems to be the rare exception, not the rule.] Please pardon any statements of societal philosophy -- the practical question is very simple: can we bet the farm that the new CentOS SL will be a reliable production system in a hostile (under attack) environment? If I understand Jarek, CERN is so betting, presumably to save the cost of RHEL 7 licensing to the governments (and perhaps private philanthropy at some of the universities participating in the CERN LHC collaborations) that are funding the experiments. Yasha Karant On 06/30/2014 11:54 PM, Jarek Polok wrote: Dear Yasha [...] From a query I posted on this matter to the SL list: 2. Evidently, Singh and other core CentOS team members actually are Red Hat employees, just as the core SL team have been Fermilab or CERN employees (presumably in some cases actually paid by the research collaborations funded by various government agencies through various universities -- e.g., in the USA, NSF or DOE with each PI typically holding a tenure-stream faculty position at a university). Will the core SL team or the core CERN linux team likewise become Red Hat employees? CERN linux team is and will be CERN employees: Our only relationship with Red Hat is that we are customers. To clarify little bit: Our primary mission at CERN is to provide support for linux platform for our customers - experiments and working groups - not to build linux distribution. (yes - we did it in last 10 years since in 2004 this was the only option) End question. Are Jerek Polok et al. now Red Hat employees, or still CERN employees? Yes we are CERN employees: the fact of using this or that linux version does not change it - why would it ? Additional questions: A. Will the
Re: Clarity on current status of Scientific Linux build
On 07/01/2014 03:40 AM, Yasha Karant wrote: At this point, unless Fermilab is planning something else, it appears that SL fundamentally is dead. SL is going to be CentOS, so the SL non-CERN community might as well switch to CentOS or to license real Red Hat EL for fee. CERN is no longer willing to invest the resources (human and machine) to support a separate distro. Does Fermilab have the resources to go it alone? SLC evidently will be CentOS with specific additional hardware drivers and software applications to meet the needs of the CERN LHC collaborations, including running the LHC detectors and data reduction and analysis environment. ??? That is not at all what I got from his reply. What I got was that CERN will still be committing resources, but instead of duplicating effort they're joining up with the CentOS effort. I even get the impression that it's the same amount of resources as was put towards the separate SLC distribution, which will likely now be a SIG of CentOS. This is good for everyone, since here is a dedicated team that is not comprised of Red Hat employees vested in CentOS. Unless the SRPMs distributed by Red Hat are a misrepresentation, a build from these SRPMs should yield RPMs that are identical (bit for bit, e.g., under a real binary compare) to the installable RPMs provided by Red Hat. The rebuilt RPMs have never been 100% bit-for-bit identical with the Red Hat binary RPMs; that's not what binary-compatible means. 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. Red Hat is a for profit corporation, providing source, etc., back to the not-for-profit community only because of a marketing model and/or GPL, etc., restrictive covenants (licenses). That is inaccurate; Red Hat is not obligated to provide source to the public, nor is anyone who receives source from Red Hat obligated to share it publicly. Red Hat is being as close to a good member of the community as is possible within the constraints of a publicly traded corporation, and they are going above and beyond the letter of the GPL (but perhaps not as far as the spirit of the GPL) in providing source (including timely updates) that is publicly accessible. No one yet in this thread has provided a public, no login required, link to up-to-date sources for SLES 11. The newest publicly available sources for SLES 11 that I have been able to find are nearly a year old. However, the for-profit competitors of Red Hat, notably Oracle, are using RHEL source to build a competitor linux distro that Oracle evidently distributes without fee. Oracle's support is not without fee. Oracle and Novell both seem to be attempting to provide direct support not necessarily for their own distributions, but for actual RHEL itself, too. This was the cause of many pieces of formerly open information (including bugzilla entries) to go private, to make it more difficult for RH's competitors. The community was unfortunately negatively impacted by that, too, but it's a balancing act between openness and business sense. I personally wish things could be completely open; but I also know that the community is heavily, almost entirely, dependent upon Red Hat's business survival. However, if CERN and/or Fermilab actually do compare the CentOS git to the real Red Hat EL SRPMs -- a tedious task unless it can be automated -- there is no reason in my opinion not to trust the CentOS EL source. I do trust that CERN and/or Fermilab personnel will do an honest compare. Now this is interesting. You're trusting a third party to compare Red Hat's product to Red Hat's community edition (essentially) but not trusting Red Hat to do that itself? If you don't trust Red Hat to provide and continuously verify the contents of git.centos.org themselves, then how in blue blazes can you trust Red Hat to provide the source code you're using? Whether Red Hat says they're doing it or not, it's a really good bet that a Red Hat engineer is tracking git.centos.org continuously to make sure the upstream sources remain unblemished. While I would prefer Red Hat to state that plainly, at the same time I believe it is strongly implied by the presence of Red Hat employees other than the CentOS team on the centos-devel mailing list. I am not being paranoid -- I am simply applying the way for-profit USA corporations (such as Red Hat, Oracle, Microsoft, and many others) operate -- and this operation is not in the interest of the commons. At this I have to take exception. Red Hat has many times proven its commitment to the community in both word and deed. can we bet the farm that the new CentOS SL will be a reliable production system in a hostile (under attack) environment? Here you really *are* being paranoid,
Re: Clarity on current status of Scientific Linux build
[...] ??? That is not at all what I got from his reply. What I got was that CERN will still be committing resources, but instead of duplicating effort they're joining up with the CentOS effort. This is what I meant. I even get the impression that it's the same amount of resources as was put towards the separate SLC distribution, which will likely now be a SIG of CentOS. Actually we (SLC) are putting these resources in CentOS Core SIG. (and in the future perhaps in other SIGs too - Cloud / Virt / ..etc) - as a matter of fact - little bit less than 'same amount' - since we still continue building SLC6 and SLC5 in-house. This is good for everyone, since here is a dedicated team that is not comprised of Red Hat employees vested in CentOS. [ ... ] Jarek __ --- _ Jaroslaw_Polok __ CERN - IT/OIS/WLS _ _ http://cern.ch/~jpolok tel_+41_22_767_1834 _ _ +41_76_487_9487 _
Re: Clarity on current status of Scientific Linux build
And in case I haven't already thanked you (and I think I did, Yes, you did (more than once actually ;-)) but it bears repeating) thanks for sticking with IA64 up to SLC 5.4; As you know we had to stop this effort .. I believe by now we do not have any IA64 systems remaining at CERN .. it made my job of rebuilding CentOS 5 packages on IA64 much much easier, and SLC 5.4 is still my startup distribution for bootstrapping an Altix before pointing to my C5 rebuild repos (I haven't spun ISO's as yet, just rebuilt the packages). Do you have your rebuild available somewhere to the public ? Regards Jarek -- __ --- _ Jaroslaw_Polok __ CERN - IT/OIS/WLS _ _ http://cern.ch/~jpolok tel_+41_22_767_1834 _ _ +41_76_487_9487 _
IA64 C5 rebuilt packages (was: Re: Clarity on current status of Scientific Linux build)
On 07/01/2014 10:06 AM, Jarek Polok wrote: it made my job of rebuilding CentOS 5 packages on IA64 much much easier, and SLC 5.4 is still my startup distribution for bootstrapping an Altix before pointing to my C5 rebuild repos (I haven't spun ISO's as yet, just rebuilt the packages). Do you have your rebuild available somewhere to the public ? Not at the moment, as the packages are unsigned, and I haven't been exactly speedy on keeping up with updates. If demand were to ramp up, I would be willing to make them available, after I set up signing infrastructure, doing the signing, and setting up some automation for the builds. I would not be willing to make a 'timeliness' commitment on updates, though, since it is very much a secondary effort here right now. But my gut feel is that there is very little demand right now.
Re: Clarity on current status of Scientific Linux build
On Tue, Jul 1, 2014 at 6:17 AM, Lamar Owen lo...@pari.edu wrote: ??? That is not at all what I got from his reply. What I got was that CERN will still be committing resources, but instead of duplicating effort they're joining up with the CentOS effort. Whatever. The relevant questions are: (1) Will SL's goal continue to be creating a re-spin of Red Hat Enterprise and *not* CentOS, since Red Hat's clear goal in acquiring CentOS is to create divergence between the two; and (2) what mechanism(s) will SL use to achieve that goal? (Specifically, will SL compare the git sources against actual SRPMs obtained via subscription?) 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. Red Hat is being as close to a good member of the community as is possible within the constraints of a publicly traded corporation, Disingenuous claptrap. Red Hat is blatantly violating the clear intent of the license that the authors of the code placed on their work. Why Red Hat does this is frankly irrelevant. No one yet in this thread has provided a public, no login required, link to up-to-date sources for SLES 11. Yes, you keep bringing this up as if it were an argument. No one has provided a public, no login required link to an up-to-date photo of my bare rear end, either, which would be precisely as relevant. We are talking about Red Hat; the actions of SUSE, Oracle, Microsoft, Tesla, and your cat have zero bearing on the discussion. Nobody cares about SUSE because nobody cares about SUSE. - Pat
Re: Clarity on current status of Scientific Linux build
On 07/01/2014 11:16 AM, Patrick J. LoPresti wrote: On Tue, Jul 1, 2014 at 6:17 AM, Lamar Owen lo...@pari.edu wrote: ??? That is not at all what I got from his reply. What I got was that CERN will still be committing resources, but instead of duplicating effort they're joining up with the CentOS effort. Whatever. Well, apparently I understood Jarek's post correctly. The relevant questions are: (1) Will SL's goal continue to be creating a re-spin of Red Hat Enterprise and *not* CentOS, since Red Hat's clear goal in acquiring CentOS is to create divergence between the two; It would be detrimental to their bottom line to do so, since so many people are out there who could potentially blow the whistle on any such divergence. and (2) what mechanism(s) will SL use to achieve that goal? (Specifically, will SL compare the git sources against actual SRPMs obtained via subscription?) If the SL developers want to reply, they will. I trust Connie and all the rest are working on the situation, and I trust their judgement for their project. The *goal* of CentOS used to be binary compatibility, even if it was never 100% achieved. What matters is what they intended it to mean, which has never been 'bit for bit identical.' What does 'binary compatibility' really mean? (I take it to mean that all software compiled and linked for one will run on the other; and that doesn't require the packages to be anywhere close in terms of a binary compare; the CentOS test includes more than that.) The following post from 2011 points to the info on how the CentOS project has historically done the binary compatibility test: http://lists.centos.org/pipermail/centos/2011-April/109483.html (the actual script has been moved to vault; see http://vault.centos.org/4.9/build/distro/tmverifyrpms for the actual script, dated March 10, 2011). Further, '100% binary compatibility' to me means that 100% of the software built for one will run absolutely unmodified with identical behavior on both systems (the binaries built on one are 100% compatible with the other). Compatible doesn't mean and has never meant identical at the byte for byte compare level. ... No one yet in this thread has provided a public, no login required, link to up-to-date sources for SLES 11. Yes, you keep bringing this up as if it were an argument. It's a valid counter-example. If the violation of not publicly releasing source RPMS and tying subscription status with continued access were so egregious then SuSE would have been sued into oblivion long ago, and the absence of such suits makes it more difficult for the argument to be made that Red Hat, which is making up-to-date sources available, is violating where SuSE is not (which does not make up-to-date sources available).
Re: Clarity on current status of Scientific Linux build
On 07/01/2014 11:54 AM, Yasha Karant wrote: From: http://en.wikipedia.org/wiki/GPL#Copyleft Conversely, if one distributes copies of the work without abiding by the terms of the GPL (for instance, by keeping the source code secret), he or she can be sued http://en.wikipedia.org/wiki/Lawsuit by the original author under copyright law. End quote. From the gnu.org GPL FAQ: Does the GPL require that source code of modified versions be posted to the public? The GPL does not require you to release your modified version, or any part of it. You are free to make modifications and use them privately, without ever releasing them. This applies to organizations (including companies), too; an organization can make a modified version and use it internally without ever releasing it outside the organization. But /if/ you release the modified version to the public in some way, the GPL requires you to make the modified source code available to the program's users, under the GPL. Thus, the GPL gives permission to release the modified program in certain ways, and not in other ways; but the decision of whether to release it is up to you. ... If I know someone has a copy of a GPL-covered program, can I demand he give me a copy? No. The GPL gives him permission to make and redistribute copies of the program /if he chooses to do so/. He also has the right not to redistribute the program, if that is what he chooses. ... Does the GPL allow me to sell copies of the program for money? Yes, the GPL allows everyone to do this. The right to sell copies is part of the definition of free software. Except in one special situation, there is no limit on what price you can charge. (The one exception is the required written offer to provide source code that must accompany binary-only release.) Does the GPL allow me to charge a fee for downloading the program from my site? Yes. You can charge any fee you wish for distributing a copy of the program. If you distribute binaries by download, you must provide “equivalent access” to download the source—therefore, the fee to download source may not be greater than the fee to download the binary. ... If I distribute GPL'd software for a fee, am I required to also make it available to the public without a charge? No. However, if someone pays your fee and gets a copy, the GPL gives them the freedom to release it to the public, with or without a fee. For example, someone could pay your fee, and then put her copy on a web site for the general public. ... End of quotes. This last point is the real meat, and is the issue which is so controversial. And that issue of 'does a vendor have to right to draw up a terms of use for a means of access to software that makes not redistributing materials obtained via that means a condition for continued use of that means of access?' There's an old posting that somewhat addresses this, but not for this current exact situation: http://linuxmafia.com/faq/RedHat/rhel-isos.html I am not a JD (or equivalent in any nation-state), but I do teach the professional computer science ethics course my School (Department) uses to meet ABET accreditation. This includes an article by Stallman on the concepts of free software. This is laudable, and I'm glad someone is doing this. I am a member of a committee developing certification standards for accreditation of some computer-related educational fields, and having the ethics of various IT/IS/CS/CE/SE situations dealt with in depth is critical, and something I've lobbied for. I'm a very 'free' leaning person, actually, as it would be my preference for all software to be free in the freedoms 0-3 sense of the word free. I'm also a realist and I know that there are tradeoffs made in real life that idealists forget to their detriment. My understanding is that under the GPL the full source code must be made available -- full, including whatever is required to build the software application. Of course then you also know that that does not include certain pieces of the operating system, like the compiler and kernel used, although the exact versions of those must be noted (RPMs 'note' those versions through build and install dependencies). Thus, the statement that the actual binaries for non-Red Hat RHEL that are built (before the actual clone distribution that no longer uses the Red Hat logos, etc.): RH sometimes uses an unreleased version of bar in order to build foo. Rebuilders like CentOS and SL have to make do with the released version of the bar srpm in order to build foo. (From: Date: Tue, 1 Jul 2014 05:05:56 -0400 Message-ID: CAOdo=SzsNsJWn2c-u+sjE_tigvGhVe0_=_hy_5gcgej38kn...@mail.gmail.com Subject: Re: Clarity on current status of Scientific Linux build From: Tom H tomh0...@gmail.com ) End quote seems to violate the GPL as there is a (very important) bit of source code that is
Re: Clarity on current status of Scientific Linux build
On 2014-07-01 08:16, Patrick J. LoPresti wrote:
On Tue, Jul 1, 2014 at 6:17 AM, Lamar Owen lo...@pari.edu 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
Re: Clarity on current status of Scientific Linux build
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. 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. Incorrect. If GNU C has this same feature It does not, and it never has. See https://wiki.debian.org/ReproducibleBuilds or https://blog.torproject.org/category/tags/deterministic-builds or http://www.chromium.org/developers/testing/isolated-testing/deterministic-builds or just try a search of your own. prattling about binary identity and so forth is nonsense. Before accusing someone of prattling about a topic, may I suggest learning something about it? 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. No, traceability is the irrelevant side issue here. (Granted, binary reproducibility is also a side issue; just one where you happen to be wrong.) Once again, the only relevant question is whether and how Scientific Linux can be a rebuild of Red Hat Enterprise *and not CentOS*, when Red Hat's clear motivation and intention is to make those different things. The issue at its base is who do you trust? Whom. OK OK too pedantic. 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. - Pat
