SCIENTIFIC-LINUX-USERS Archives

January 2016

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:
Nico Kadel-Garcia <[log in to unmask]>
Reply To:
Nico Kadel-Garcia <[log in to unmask]>
Date:
Fri, 1 Jan 2016 11:50:27 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (110 lines)
On Tue, Dec 29, 2015 at 9:57 PM, Yasha Karant <[log in to unmask]> wrote:
> On 12/29/2015 02:42 PM, Connie Sieh wrote:
>>
>> On Tue, 29 Dec 2015, Yasha Karant wrote:
>>
>>> On 12/28/2015 01:37 PM, S A wrote:

>>> I am confused.  As I thought I understood the current EL situation, Red
>>> Hat owns CentOS and distributes EL full source, per GPL, Linux, etc.,
>>> licenses, through CentOS for all non-RH rebuilds (e.g., Oracle) to use
>>> (sans Red Hat logos, services, etc.).  In this case, two questions:

Give credit where it is due. Red Hat goes well beond the minimum
required by vairous licenses, and engages in genuine free software as
a policy where possible, in open source when free software is not
possible, and in closed source only where absolutely necessary to
handle a very real customer demand, and does their very real best to
free up encumbered licenses. The result has been free rebuilds of RHEL
base software such as Whitebox Linux, CentOS, and Scientific Linux.
It's unfortunately been abused by Oracle to make their so-called
"Unbreakable Linux", but the rebuilders of that have been nowhere near
as open and generous with developers and non-buisiness uers.

>>> (1) Is Fermilab/CERN not funded well enough to have the same
>>> rebuliding/packaging resources as Oracle just to rebuild from the RH
>>> CentOS sources, and thus is delayed in production binary (RPM) release
>>> compared to Oracle?  Both Fermilab and CERN are funded through their
>>> respective governments that support fundamental research.

Oracle sells their "Unbreakable Linux" as a product. Scientific Linux
does not, and it's left them free to provide direct links to third
party repositories which would be legally problatic in the US.
Repoforge and RPMfusion, in particular, have softwrae that can and
have included MPEG and DECSS software which would be awkward or even
illegal to publish without permission of the patent or DVD lmedia
license holders.

For the exact relationship between CentOS, RHEL, Oracle's Linux, and
Scientific Linux, take a good look at the licenses. There are some
similar weird things happening with SLES and OpenSuSE, which is still
not completely straightened out, and RHEL hiring some of the key
CentOS developers and using git.centos.org to publish source code,
instead of publishing SRPM's, makes it extra fascinating. I'm becoming
convinced that CentOS is filling the old niche fulled by the "free"
Red Hat releases which existed before RHEL was published.

> I did not know that CERN had stopped in the extra-CERN SL work -- was SL 6
> the last "public" joint Fermilab-CERN "supported" release? Is CERN still
> using EL (presumably 7) internally, or has CERN switch to something else
> (e.g., SuSE)?

That wouldn 't seem to be a "scientific-linux-users" question, that
would be more of a "scientific-linux-developers" question.  It's also
not one I'd personally worry about. as long as they're willing to
publish, especially with the extra development hooks, and I'm willing
to help out users, then they and I have a deal. Your approach to this
may differ quite a lot.

> May I assume from your response that Fermilab currently is not funded well
> enough to bring out RHEL production releases (presumably via RedHat owned
> CentOS) as rapidly as, say, Oracle?   Presumably, Oracle also is forced to
> use the CentOS source as Red Hat regards Oracle as a competitor,
> particularly because, unlike SL,

There is nothing preventing Oracle from buying a RHEL license and
maintaining a local RHEL SRPM and/or RPM mirror. I've long published a
tool to do just that at
https://github.com/nkadel/nkadel-rsync-scripts/blob/master/reposync-rhel.sh.
I've used it for maintaining a local yum mirror of RHEL, similar to
the rsync based ones I use for SL and CentOS, because doing yum
updates against a remote mirror can be a serious bandwidth burden.

The licensing of individual packages inside such a local mirror may
prevent CentOS, SL, or Oracle re-publication of them, and our
faviorite upstream developers at Red Hat are clearly doing their best
to unencumber such software for inclusion in RHEL. But it's hard to
stay caught up when clients demand a supported feature. Their efforts
allow rebuilds like CentOS and RHEL, and I'm very happy with their
efforts.

Such an SRPM mirror can also be noticeably safer than a locally cloned
git repository. SRPM's are GPG signed and have much more certain
provenance than a local git clone can have without GPG signed git
tags, and git.centos.org still insists on parsing the text of git
logs, rather than using git tags, to publish specific software
releases. The ability to confuse or poison such log entries is left as
an exercise for developers, but I'll point out the relevant XKCD
cartoon, titled "Exploits of a Mob".

         https://xkcd.com/327/

> Oracle claims to offer the same "quality"
> support-for-fee that Red Hat claims, providing the same sort of "cradle to
> grave" support that many IT departments require.  (As an academic research
> unit, we are "self-supporting").  For those of us in the USA, would it help
> SL staffing to attempt to get earmarked funding through Congress?

US funding of Scientific Linux could create some real problems. They
could insist on pruning out RPMfusion, atrpms, or livna hooks atrpms
doesn't seem to be actively maintained anymore, but RPMfusion is my
friend for various codecs, and Livna and atrpms have been my friend
for the libdvdcss library in countries that allow the use of encrypted
DVDs on Linux. I've worked with clients in those countries, and I
really appreciate having straightforward access to it for VLC and
similar tools in Scientific Linux based hosts.

> Regards,
>
> Yasha Karant

ATOM RSS1 RSS2