SCIENTIFIC-LINUX-USERS Archives

July 2014

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Lamar Owen <[log in to unmask]>
Reply To:
Lamar Owen <[log in to unmask]>
Date:
Tue, 1 Jul 2014 09:17:13 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (90 lines)
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, IMHO.

ATOM RSS1 RSS2