Cluster Poll Results (tangent into OS choices)

Robert G. Brown rgb at
Tue Nov 4 08:26:39 EST 2003

On Mon, 3 Nov 2003, Greg Kurtzer wrote:

> On Mon, Nov 03, 2003 at 04:51:41PM -0700, Mike Snitzer told me:
> > Rebuilding RHEL3 into a freebie-ripoff version doesn't pass the smile-test
> > for corporations trying to coexist and actually work with Red Hat.  Why
> > not focus that questionable rebuilding effort on a more worthwhile task?
> > E.g. porting Fedora Core to support amd64, ia64, etc; adding features to
> > Fedora Core that are relevant to clustering, etc.
> I guess what some would consider a worth while task others would consider a
> waste of time. From what I see, Fedora core is an unreasonable solution for me
> and I will not be contributing to it while RH holds every seat on the steering
> committee and rules all directions. Not that I have anything against RH, it is
> just that there is a major conflict of interest, don't you think?
> If Fedora gets too good, won't it take business from RHEL?

It already is, but it is mostly business that RHEL will never get

Basically, it will be a cold day in hell before Duke or any other
University starts paying Red Hat a million dollars a year for access to
a linux distribution consisting of 99% GPL/free packages and 1% logos,
given that we do NOT consume RH "support", but are rather a net
contributer (we run a primary RH mirror, for example, as well as several
GPL projects some of which have in the past de facto shamelessly
promoted RH and which now will shamelessly promote fedora just by
existing with that as their primary base).

Remember also that RH >>needs<< fedora, or something like it.  They
CANNOT release RHEL in rawhide (like I'm not only going to pay RH order
of $100/seat, but I'm going to get and install beta-level software for
that price and help debug it?  Oh yeah.)  One reason RH has been, for
the most part, rock-solid as largish linux distributions go is because
all the squishiness in each new release has been squeezed from the rock
in rawhide.

There are several other reasons that fedora will likely work just fine
and not be subverted by RH.  One is that (as we've been discussing on
the list) it is by no means clear that RH can legally restrict even the
reinstallation of binary RPM's whose primary content is GPL software in
any way.  I personally, after reading the GPL carefully yet again, think
that this is the case.  In fact, I think that if they do something like
mix a lot of "trademark" logos in with e.g. GPL/gnome icons that are
required by GPL packages in e.g.  redhat-artwork that redhat-artwork de
facto inherits a GPL -- the GPL is explicitly written to keep free
software free as in air.  Note well that I >>cannot<< make a GPL package
"proprietary" in any way -- certainly not by adding a header that says
something like "this package is copyright and trademark and belongs to
rgb".  Not even by actually writing something that adds value that IS
copyright rgb.  Add to the GPL base, become part of the GPL base -- that
is the rule.  The only packages RH can legitimately constrain the
reinstallation of are: packages containing proprietary Red Hat code with
no full GPL (or equivalent) components or library dependencies and
packages containing strictly RH logos and trademarks, ditto.

Nobody cares about either one.  I don't think there are any of the
former (I could be wrong) and the latter is advertising.  Like I should
pay RH enormous sums of money for installing their advertising on my

Finally, one REASON that RH is splitting out fedora is to GET more work
out of "the community".  It costs them a fair bit to keep up the RHL
releases for years after they are obsoleted.  They'd like to have their
developers working on RH 10, but they're still supporting RH 7, 8 and 9
and have to constantly fix bugs, backport security patches, etc.

So they're putting fedora out there in part to armtwist US into keeping
old releases up (or not), as a tacit acknowledgement of the realities of
the GPL (which apply to RHEL whether or not they like it and frankly
whether or not one rebuilds the source rpm's -- there isn't any way to
restrict the installation or redistribution of a BINARY package of GPL
code as I read the license), and to maintain the absolutely essential
community involvement in the rawhide process that leads TO a "RHEL" that
they can market with some degree of success to corporations.

As I've noted and will continue to note again, I think that we are on
the verge of a paradigm shift in linux anyway, and that this is going to
likely kick it over the edge.  The existence of yum AND apt-tools
finally make it natural to consider merger, and completely alter the
scaling paradigms at the institutional support level.  We are seeing the
very last releases of RH where CD ISO's are in any way relevant, for
example.  The future is going to focus completely on the network and the
concept of "the repository", on cross-distribution standardized package
metadata, on fully automated rebuilds from source packaging.  Yum
conceivably makes the entire concept of "a distribution release"
obsolete -- we'll have to wait and see, but I suspect that this will be
the case.  

Instead of upgrading systems on a timescale with granularity of years,
we may be entering a universe where systems are microincrementally
updated nightly, with immediate feedback and repair, and with a
user/admin determined lag relative to the primary repositories to insure
a level of institutional stability deemed locally acceptable.  In a way
this is DEMANDED by security anyway -- security requirements are a major
driver of the paradigm shift.  RH will eventually be making its money
from RHEL by inserting themselves into this stream with a FIXED delay
and a certification process required by e.g. banks and other
corporations that have due diligence and government audit laws to
satisfy.  Everybody else will ride the wave (and generally be more
secure than said banks, but it will take years for lawmakers to catch up
to the new paradigm.

> Now I do want to mention that I think that RH's new direction is what is
> needed for Linux to become a suitable Enterprise solution. This move however
> left a vacancy in the community which is why projects are emerging or changing
> direction to fix this. It is OSS evolution (see:

It be VERY interesting to see what the proliferation of community
efforts produces.  Perhaps they'll one day merge.  Perhaps not.  Open
source is a rich environment for the evolution of new ideas, and these
will be "interesting" times indeed:-)


Robert G. Brown	             
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb at

Beowulf mailing list, Beowulf at
To change your subscription (digest mode or unsubscribe) visit

More information about the Beowulf mailing list