Enterprise Linux by any other name

I’ve been doing a fair bit or reading and writing and talking about different versions of “Enterprise Linux”, and the more I talk and think about it, the more I come to realize that I’m not as comfortable with the definition of that phrase as I would like.

The current working definition of “Enterprise Linux” is a Linux distribution based off of the Source RPMs and build methods of RedHat Enterprise Linux. Essentially a group of people get together, put together a build infrastructure, and make a distribution using RedHat’s released sources. However, there are interpretations and changes made that make each of these distributions unique in their own right. CentOS has its issues, of course, but tries to stay as faithful as it can to the RedHat product. Scientific Linux seems to be a livelier group right now, but they’re truly making their distribution their own.

For example, SL doesn’t install the RedHat/Fedora Auto Bug Reporting Tool by default. While this is perfectly fine, it does make me wonder how if SL wants to push any bugs their community finds upstream or if they want to patch them within their own community. I was instructed by of the moderators at the SL forum site to contact one of the primary SL contributors about this, and I will. I’ll of course report back what I hear. I look forward to it.

I don’t know much about PISA’s philosophy, really. If someone knows more about the project team and their goals, I’d love to know.

AscendOS is just now getting off the ground, and their vision of building out an Enterprise Linux distribution without all of the baggage of the older communities. Noble, sure, but they’re still doing one thing like all the rest that may be worth examining. They’re all based off of what RedHat decides to do in their distribution.

I get the conventional wisdom, that if you follow RedHat’s lead, it’s easier to be compatible with RedHat. But it also piegon holes a distribution in to making mistakes that RedHat makes.

Now if you know me or have ever worked with me or talked to me for more than 3 minutes or been to a Richmond LUG meeting,  you’ll know that I’m a huge RedHat fanboy. I love how Shadowman goes about his business, and think they’re an admirable example of how to be a really good open source company. The RedHat product that really moved them into the limelight was RHEL 5. After coming out in 2007, it became the Linux standard in the Enterprise. But it had some serious shortcomings that proved at least annoying, and sometimes painful, for admins running it on a daily basis. The decisions that pop into my head are

  • holding on to Python 2.4 for so long
  • not including syslog-ng
  • not moving up to openldap 2.4
These are some of the first changes that happen to most any RHEL/CentOS 5.x installation that I control. I know RedHat had a good reason to maintain the older versions of python and ldap, and not including syslog-ng. But is it the best for an enterprise?
Should their be a distribution out there that relies more on sound principles than a specific company to guide their product? A community that tried to make the best distro available to run in a corporate environment.
Should we change how we define “Enterprise Linux” from “a RHEL-derived Linux distribution” to “A downstream Linux distribution that is optimized and hardened to work best in a corporate environment”. I guess that’s a pretty open-ended question, but I think it’s worth thinking.

The Clone Wars – CentOS vs. Scientific Linux

Update: The conversation continues HERE.

With Linux in the Enterprise, RHEL is king. Sure there are people who love and use Debian, or Suse. I would imagine that if you looked hard enough you could likely find somebody who’s using Slackware or Gentoo in a business somewhere. But I think it can safely be said that RHEL is currently the dominant enterprise Linux distribution. Then, of course, there are the clones.  If you so choose, you can forgo Shadowman’s Support team and either compile the freely available Redhat Source RPMs, or choose to use a community-supported RHEL clone. Currently, the two most popular of those clone distributions are CEntOS (Community Enterprise Operating System) and Scientific Linux (SL).

So if you have decided to not utilize Redhat support, which of these downstream clones is the better choice? With the recent (much delayed) release of CentOS 6.0 in the past week, many companies are looking to move up to the RHEL 6.0 family of operating systems. But is CentOS still the right choice? Being a primarily CentOS shop, and being more than a little OCD myself, I decided to compare the two in as practical as a manner as I could. Below are the results.

Maturity:

When it’s running on production, you don’t have time to wait on a tiny community to figure out how to backport in some obscure cross-site scripting vulnerability in an even more obscure module in your favorite language, even if you’re part of that community. An enterprise operating system needs to have an active and robust community to support itself, paid or not.

CentOS has been around for a long time and has a huge following. There have been murmurs of late about the core contributors getting tired, and the delay in CentOS 6.0 was the evidence. I don’t believe that fully, but I do believe the project could do with some fresh blood and possibly some new ideas.  But I don’t think it’s going anywhere anytime soon.

Scientific Linux hasn’t been around nearly as long, at least on the scale that it is currently enjoying. The community, however, is vibrant, and is backed by several large research labs such as CERN and Fermilab. Big plusses.

Advantage: Push

Workflow:

In Open Source software, the process is often times as important as the product. While I don’t believe there is anything massively different in how these 2 projects are doing what the do, SL is certainly better at talking about it and making the community aware of how it’s working. This presentation(PDF) is a pretty great one, even if it’s a little dated. SL Community, I’d love to see an update, for the record.

Advantage: Scientific Linux

RHEL Compatability:

This used to be a much larger difference, as late as version 5.x. Scientific made some pretty large changes to the RHEL repository structure, and added in some packages of their own. CentOS has always been as faithful a clone as was possible at the time. This is largely cleaned up in version 6.0, with the extra SL packages moving out to external repos, but much like the workflow advantage above, perception is still a strong influence.

Why is this important? Well, like lots of people, we’re a mixed RHEL/CentOS shop. It just makes life SO MUCH EASIER.

Advantage: CentOS

Mirror Speed and Availability:

I couldn’t find any perceivable difference in this category. Both networks are robust and highly available.

Advantage: Push

Community Support:

This is one of the most important factors when adopting a distribution, and sadly the one answer I’m not able to fully answer. I utilize CentOS support all the time, via the web, forums, and IRC. I’ve only occasionally sought support for SL, and this was way back in version 5.2. So I’m not really qualified to answer this one fully right now. However, I see active forums off of their home page and a 10 minute visit to the IRC channel on freenode saw plenty of conversation for a Tuesday night. I don’t think SL would have grown so much without good community support.

Advantage: Push

Lifecycle Support:

This was the one that surprised me.

As expected, CentOS mirrors the RHEL lifecycles. RHEL/CentOS 5.x will be supported through 2014. They haven’t updated their wiki yet, but I’m sure 6.x will be the same, with a full 7-year lifecycle.

Scientific only plans on a three year lifecycle. But on their forums they also mention supporting things in theory as long as Redhat does. So I’m a little confused on this one.

While I don’t typically plan on using the same OS for longer than 3 years, if it ain’t broke, I’m certainly not fixing it.

Advantage: CentOS

So those are my thoughts on the situation. Scientific Linux is definitely on the rise, and CentOS certainly needs to air out themselves a little. But at least with version 6.0, we’re still going to be going with our tried and true CentOS. I’m just not comfortable enough, yet, with the Scientific Linux community, mainly because they still don’t quite know how long they plan to keep their products alive. Out of this look at RHEL clones, though, the single biggest thing I’ve discovered is that I’m going to have to keep evaluating this choice down the road.