|
|
Subscribe / Log in / New account

RHEL clones: a surfeit of riches

By Jonathan Corbet
January 4, 2012
For better or for worse, Red Hat's Enterprise Linux (RHEL) is the standard form of Linux in many settings. Red Hat invests considerable resources into stabilizing RHEL and supporting it for many years after its initial release. That gives comfort to companies fearing the choice between a forced migration to a newer version of the distribution or having to take on the burden of maintaining it themselves. RHEL is the default choice in many situations where all software must come accompanied by a long-term support contract; it is telling that Red Hat's two closest competitors (SUSE and Oracle) both offer support for Red Hat's distribution.

RHEL is built with free software, and Red Hat fully understands both the conditions attached to free software licenses and the expectations of the development community. So the source for each RHEL release is promptly made available to the community. It is natural to expect that plenty of people would like to take advantage of the stability of and support behind RHEL without actually paying for a support contract; the availability of the source makes it possible to do exactly that. All that is needed is to rebuild those source packages, minus any Red Hat branding, and make the result available to the community.

Except that, in reality, the problem seems to be harder than that. Creating a proper build and distribution environment requires work and equipment. Quality control can be a lot of work, especially if strict binary compatibility with RHEL is desired. The security update stream must be followed constantly. And Red Hat does not always make the job of keeping up with their releases easy. So anybody wanting to make and support a proper RHEL clone must be prepared to invest a lot of time and infrastructure into the task.

Given that the desired end result of any RHEL rebuild effort - something that looks as much like RHEL as possible - is clear and unvarying, one would think that there would not be room for a large number of RHEL rebuild projects. There is not much space for ego or interesting new development, so it would make sense for everybody with an interest in this area to work together for the best end result. That is not how things have worked out, though. One need not look to far to find plenty of rebuilds out there:

  • Oracle Linux is the most notorious of the commercial rebuilds. For the most part, Oracle has been working from the RHEL base with an eye toward binary compatibility. Over time, the company has started to add in some features of its own, including a newer kernel.

  • CentOS is arguably the largest and best established of the free rebuild projects. Many commercial hosting providers offer CentOS installs, even if they have no other RHEL clones available. CentOS is clearly successful, but it is not the most community-oriented of projects. The project's leadership is jealous of its user base and seemingly unwilling to open things up to outsiders. At times the CentOS developers have failed spectacularly to keep up with Red Hat's releases, with the result that CentOS users have seen prolonged periods without security updates. That said, the rapid release of CentOS 6.2 suggests that the situation is improving.

  • Scientific Linux has a significant and growing user base; it also has a small core of paid developers. This distribution has arguably done a better job of staying on top of security updates in recent times, but, as of this writing, it has not caught up to the Red Hat 6.2 release.

  • Ascendos claims to be "is a free, community-supported, and professional-grade Linux platform". It is also vaporware, with no actual releases to date. Its development was initially led by Troy Dawson, who has also worked with Scientific Linux, but a job at Red Hat evidently put an end to that work. Troy's replacement, Douglas McClendon, stepped down in mid-December. Despite its claimed community orientation, Ascendos does not appear to have attracted many other developers, so the project now appears stalled.

  • GoOSe, on its surface, looks a lot like Ascendos. It, too, claims to be "all about the community", but has not yet created much of an actual development community. The project had hoped to get a 6.0 alpha release out by the end of the year, but that did not quite happen.

    There have been discussions recently about cooperation between Ascendos and GoOSe, but nothing has been announced yet.

  • ClearOS is a rebuild "built on source code from a prominent North American Linux vendor" offered by a group called "Clear Foundation." There is a lot of talk of community on Clear Foundation's web site, but "community" seems to consist mainly of access to a set of forums. By all appearances, ClearOS is meant to be a vehicle for a series of commercial support operations. The current ClearOS offering is based on RHEL 6.0, with a 6.2 release available as a beta.

  • Fermi Linux is a rebuild of Scientific Linux. Its current 6.1 release adds a number of packages and tweaks some settings.

  • PUIAS Linux is a rebuild published by Princeton University. It is currently based on RHEL 6.2 with a number of additional packages.

There are undoubtedly others, but, at this point, the picture should be clear: a lot of independent groups are putting a lot of effort into their own rebuilds of Red Hat Enterprise Linux. Some of them are more successful than others, but none are as good as they could be with a bit more focused effort.

Given the long list of existing distributions and the effort required to create and maintain a new one, anybody thinking of adding to the list should think long and hard about why that seems like a good idea. If the intent is to provide a Linux experience that is not possible with any of the existing distributions, perhaps there is an excuse for making a new one. But, in the case of RHEL rebuilds, there is simply no latitude for the creation of that new experience. The desired result is something that looks and acts like RHEL. Perhaps the various groups making their own RHEL clones would get better results if they were to build a single base distribution to work from. They could then compete fiercely to provide the slickest desktop theme, which is where all the interesting action is anyway.


to post comments

RHEL clones: a surfeit of riches

Posted Jan 5, 2012 6:16 UTC (Thu) by eru (subscriber, #2753) [Link] (3 responses)

That list just reinforces my impression that there are only two free RHEL rebuilds that matter: CentOS and Scientific Linux. Others should be ignored. These two also seem to have sufficiently different niches to justify both of them. CentOS (which I run on several machines) tries to be maximally RHEL-compatible, and Scientific Linux feels free to add interesting stuff, while keeping the RHEL base for stability.

RHEL clones: a surfeit of riches

Posted Jan 5, 2012 18:38 UTC (Thu) by filteredperception (guest, #5692) [Link] (2 responses)

"That list just reinforces my impression that there are only two free RHEL rebuilds that matter: CentOS and Scientific Linux. Others should be ignored."

The reason I chose to work on Ascendos, instead of being content with with 'the big two', was because they weren't meeting, or interested in meeting my needs/wants in an *el clone/fork. Specifically, I'm a paranoid sort that doesn't believe an 'enterprise linux' build has any business being done on an online system, or in a way that couldn't be reproduced by a military grunt from a simple recipe/instructions/documentations/script.

CentOS is very clear about not wanting to enable that, because were that possible, people could trivially fork/rebrand/rebuild. And then the ego stamped into the name/logos/theme of their rebuild would not be enough to keep them relevent as an organization (or so they appear to feel).

ScientificLinux on the other hand has the problem in my mind of being the output of an inexusably* unreproduable result of a manual[1] build process. Hopefully done on offline systems, but I wouldn't be surprised if that is not the case.

Thus I spent a lot of time trying to develop an 'el-build' script which
would simply

a) download upstream sources and minimal required bootstrapping environment
from mirrors.kernel.org/archive.fedoraproject.org.

b) apply a few megabytes of deltas/patches to transform the collection of
srpms into a newly forked/rebranded set

c) build into a mirrorable distro.

The key being to encapsulate the entirety of the differences from upstream
into the smallest possible set of deltas and build scripts, such that they
are as easy to audit and rebuild as humanly possible.

That was my vision, FWIW. But yes, I did fail to attract other developers,
though the only ones I really saw in the area seemed too much in my mind to
just want to become the next centos-like technocrat clique, instead of my
goals of just automating away the whole [expletives deleted] problem so that even amateurs could remove redhat's/centos's ego-stamp from their distro, and replace it with their own.

-dmc

* from the perspective of traditional 'scientific method'

[1] http://listserv.fnal.gov/scripts/wa.exe?A2=ind1111&L=...

RHEL clones: a surfeit of riches

Posted Jan 6, 2012 12:21 UTC (Fri) by walex (guest, #69836) [Link]

I think a fully automated way to build a base distro from sources as you describe would be very welcome at Scientific Linux.

Their main mission is to support the CERN WLCG Grid and they are somewhat overworked. They had therefore considered adopting CentOS as the base and then work only on the "Scientific" bits.

Try to submit a presentation at HEPiX, it might be well received. The CERN guys might be especially interested, as they build their own slightly customised version on top of Scientific Linux, and are the guys who really matter.

RHEL clones: a surfeit of riches

Posted Mar 8, 2012 11:27 UTC (Thu) by sudhirgandotra (guest, #83392) [Link]

Could you finally create such a script to automate the re-spinnig of a distro like RedHat/CentOS ?
This can help a lot of students to learn the internals of Linux and spread it further.
I would be intereste in such a script of tutorial.
thanks.

RHEL clones: a surfeit of riches

Posted Jan 5, 2012 14:20 UTC (Thu) by michel (subscriber, #10186) [Link] (11 responses)

What I have never understood is why RH does not provide a personal/non-profit way for someone to run RHEL. Simply allow you to run it, without any support, but with access to updates, etc. Clearly, I'm not going to pay for enterprise support for a bunch of small home based systems.

I use Fedora for my main machine at home, but end up using SL for some of my servers to get the more slowly evolving/stable aspects that I want there.

Perhaps it's simply a scaling problem.

RHEL clones: a surfeit of riches

Posted Jan 6, 2012 3:36 UTC (Fri) by ewan (guest, #5533) [Link] (1 responses)

What you're suggesting is essentially the situation that existed with the old Red Hat Linux distribution - people could buy box sets or download ISOs, but support was extra. As I understand it, the problem was that a lot of people were contacting Red Hat for support, despite not having support contract, simply because they were running 'Red Hat Linux'. The load and the bad feeling caused by turning people away wasn't doing Red Hat much good, so they moved to the current RHEL model where you don't even get a copy without having a support contract. The rules for the rebuilds are that they have to remove all the Red Hat branding, so that anyone faced with a copy of CentOS, SL, etc. has no reason to get the impression that they're running something that has anything to do with Red Hat at all.

RHEL clones: a surfeit of riches

Posted Jan 6, 2012 11:50 UTC (Fri) by michel (subscriber, #10186) [Link]

Well, the problem there is that people bought the box, which implies at least some sort of support and is not unreasonable for the people who purchased the product to expect. And I think there are ways to deal with support calls from folks that have no support, but I guess this is why I am not running a $1B company.

RHEL clones: a surfeit of riches

Posted Jan 6, 2012 12:30 UTC (Fri) by walex (guest, #69836) [Link] (1 responses)

But Red Hat are a for profit company, therefore as a company they decided to focus on their paying customers for EL. The non-profit variant is Fedora and it is deliberately not EL-like.

Part of the problem is that as another commenter points out a lot of very clever sysadms liked to play the game of looking good to management by using a business distro without the cost of support, reckoning it would be infrequently needed, only to turn around and blame the business distro when support became needed. So Red Hat decided to switch to a model where pay-in-advance is the only way to get the distro.

RHEL clones: a surfeit of riches

Posted Jan 6, 2012 12:58 UTC (Fri) by anselm (subscriber, #2796) [Link]

So Red Hat decided to switch to a model where pay-in-advance is the only way to get the distro.

Actually I've heard that Red Hat will be happy to support your existing CentOS installation if you buy the requisite RHEL licence(s), with no need to reinstall everything.

RHEL clones: a surfeit of riches

Posted Jan 6, 2012 15:18 UTC (Fri) by drag (guest, #31333) [Link]

> What I have never understood is why RH does not provide a personal/non-profit way for someone to run RHEL.

They do. It's called ftp.redhat.com. People have taken advantage of it and that is why we have things like CentOS and Scientific Linux.

RHEL clones: a surfeit of riches

Posted Jan 6, 2012 23:49 UTC (Fri) by paulj (subscriber, #341) [Link] (5 responses)

You're perfectly entitled to run RHEL on your home systems, if you can get someone with RHEL CDs to make some copies of them (which they are also perfectly entitled to do for the RHEL CDs - I think RedHat even explicitly licence the OS in the aggregate under the GPL). Of course, the home RHEL user won't have access to any updates whatsoever.

RHEL clones: a surfeit of riches

Posted Jan 11, 2012 1:33 UTC (Wed) by filteredperception (guest, #5692) [Link] (4 responses)

"I think RedHat even explicitly licence the OS in the aggregate under the GPL"

I doubt this is the case, probably for several reasons, not the least of which would be because the spirit of the GPL, and perhaps even the current interpretation of it would suggest then that RedHat be required to produce the build scripts used to generate that aggregation, so that others could easily modify and then redistribute an enhanced/changed version of that aggregation.

One of the subtler angles I see of all this, is how we are, IMHO, probably well past the point of not thinking of linux distros as singular derived works in their entirety, rather than as collections of objects that can be thought of as derived works, absent the collection being thought of as such.

That said, RH does go a long way towards empowering users to create derived from-source distributions. It's just that 90/10 thing and how that last 10% of the work just gets fractally gnarly. Probably I just made the mistake of thinking koji was the right tool for the job I was using it for. I would like to leverage it to enable clustered superfast builds, but given I think my acer aspire one netbook(amd dual core, 4Gram) can probably build all of current rhel6+updates from source in a week... eh...

RHEL clones: a surfeit of riches

Posted Jan 11, 2012 7:23 UTC (Wed) by paulj (subscriber, #341) [Link] (3 responses)

The RHEL EULA certainly seems to place "RedHat Enterprise Linux" under the GPL:

http://www.redhat.com/licenses/rhel_rha_eula.html

It asserts RedHats' rights over its trademarks and the need to acquire permission in any commercial redistribution. It doesn't mention private redistribution, but the GPL then gives you the general right to copy, and private redistribution isn't restricted by trademark law.

RHEL clones: a surfeit of riches

Posted Jan 11, 2012 19:57 UTC (Wed) by filteredperception (guest, #5692) [Link] (2 responses)

"the GPL then gives you the general right to copy"

Hmm? But asside from my skepticism of what truth there actually is in that, you fail to mention the immensely broad realm of 'non-private, non-commercial' redistribution. That matters a lot to me. So much so that I spent an obsessive amount of time scrubbing trademarks from DevKitPro's redistribution of GCC as a Nintendo-DS homebrew development environment. Specifically, Dave Murphy educated me as to the fact that users have no right to redistribute, even unmodified copies of GPL binaries including protected trademarks. Basically one of my overriding goals is to provide a turnkey LiveOS distro that includes both the code of RHEL6 and DevKitPro, but in a form in which any user, can _easily_ fix a 1-line bug, and redistribute, without the need for permission from any party, and even presuming that I place trademark redistribution protections on my derived work equivalent to the way RedHat and DevKitPro do. That is, I believe, quite in tune with the spirt of the GPL. And you'd be amazed what a pain in the ass that task is to actually accomplish. But it'll happen soon enough...

RHEL clones: a surfeit of riches

Posted Jan 11, 2012 20:31 UTC (Wed) by nybble41 (subscriber, #55106) [Link] (1 responses)

> users have no right to redistribute, even unmodified copies of GPL binaries including protected trademarks

In the case of unmodified copies, that would be a purely descriptive use of the trademarks, and thus normally permitted under trademark law. After all, you're using the trademark to designate the precise binaries distributed by the trademark holder, and protecting that association is the entire purpose of the trademark.

Distributing modified binaries would, of course, be an entirely separate issue, even if they were derived from the same source code. "Based on TrademarkedName(R)" would probably pass, as a purely factual statement, but you can't legally label your own version with someone else's trademark and pass it off as the original software.

RHEL clones: a surfeit of riches

Posted Jan 11, 2012 20:56 UTC (Wed) by filteredperception (guest, #5692) [Link]

Actually you did see the case I was really focused on, i.e. modified binaries generated from unmodified source. I.e. rebuilt on top of a differing linux distro (gcc/etc) platform. And in that case, Dave made it perfectly clear that redistributing such things, under any sort of moniker whatsoever, would be something he would prosecute, if for no other reason than the IP law angles that involve needing to prove that you have actually enforced your trademarks. Basically he was saying- if you want to redistribute, you'll have to scrub every protected mark, and for legal reasons he explicitly (like many other corporations) chose not to specify what exactly that means (trademark names in email addresses within source code files? exactly where is the line drawn and how is the novice university-level GPL enthusiast to know how they need to draw that line for legal/ethical reasons?). In the end I used some wicked regexs and even sillier methods to just go overkill scrubbing devkitpro marks. But it was more technical work than I would want to wish upon the average open source user, modifier, and redistributor. Now, on the other hand, I'll give RedHat credit for the sadly practical hands off method they seem to be taking on that account. I.e. not seeming to care about things like even the bugurl and whatnot found in e.g. the ScientificLinux Xorg srpm's specs build code. And in general Fedora over the years clearly seems to be heading in the right direction, and making excellent progress, in facilitating the ability for someone to rebuild from source, remove the needed amount of fedora marks, and redistribute without having to gain anyone's permission. (Though of course that isn't really true, since if you wanted to enhance/modify any code amongst the subset belonging to firefox, you'd have to go to extraordinary superhuman lengths to scrub the firefox marks for the same reasons. ... sigh ...


Copyright © 2012, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds