Benefits to using RHEL over CentOS?

Latest response

I am trying to explain to a customer why they should use RHEL over CentOS. What are some good talking points?



Aaron K. Clark


Hi, I have that same question often but really it depends on the kind of environment and how concerned a customer is about the security and integrity of their systems.


But here are my top 3 off the cuff:


1. Updates are released through Red Hat quicker. Therefore you are able to better protect your system from knwn and unknown vulnerabilities.


2. Headquartered in America. Services are available to your customer and if the customer is unhappy or unable to resolve any issues with Red Hat, their are alternatives to securing a resolution. Customer support comes from the company, not just Google.


3. Red Hat software has been tested, evaluated and awarded some of the highest security ratings than other Linux derivatives.

Hi Aaron,

Great question!  There are a number of reasons why you might want to go with Red Hat over other vendors and projects (and Paul nailed several of them).  I'll name a few, and I'm sure others will jump in with more ideas.


* Support: Whether you're looking for help setting up a proof-of-concept or you've discovered a production-impacting issue in a mission-critical environment, Red Hat Global Support Services can help you with a solution.  With Red Hat Support, you're always dealing with the industry's top linux experts, all of which are at least a Red Hat Certified Engineer (RHCE) or higher.  Red Hat's unique support organization and award winning online Customer Portal ensure that any cases you open are directed to a qualified resource right away, so you don't have to wait days or weeks to get escalated to the right person, as with some other vendors.  Our support engineers also have direct access to the engineering resources that maintain the the products we ship, and so whenever you have a problem or question, you can be sure that you're getting solutions from someone who knows the products inside and out.  


* Access to engineering resources: With a subscription to Red Hat products, you have access to the engineers that design and develop the code you use.  So if there is a feature that you feel is missing, you can request it and Red Hat will consider it for upcoming versions of the product.  Or if you want to know how to optimize your usage of a particular component, the engineers that develop and maintain it can help you get the most out of it.  


* Online Content: Red Hat's Customer Portal was recently recognized as one of the Association of Support Professionals Ten Best Web Support Sites.  The Customer Portal contains all sorts of useful content that you can't find anywhere else, such as Product Documentation, Whitepapers, Reference Architectures, Videos, Technical Briefs and more.  It also contains a Knowledgebase which is constantly being updated with more and more content.  If you run into a question or problem, you can often find an answer in the Knowledgebase without ever having to open a support ticket.


* Hardware Vendor / ISV relationships and certifications: Red Hat works closely with industry leading hardware and software vendors to ensure that the applications you run in your environment work seamlessly with our products, and that you are getting the most out of your hardware.  We'll work with vendors to certify their products on Red Hat Enterprise Linux so that you have the confidence of knowing your systems are thoroughly tested and fully supported.  If you ever have a problem that involves other vendors, Red Hat will collaborate with them to find a solution that works for you as quickly as possible.  With other projects that rebuild from Red Hat sources, all hardware/software certifications no longer apply and you lose access to those relationships with the vendors.  


* Immediate access to the latest features: As long as you have an active subscription, you'll have access to all versions of Red Hat Enterprise Linux as soon as they are released.  With other projects that rebuild Red Hat products, you'll have to wait before gaining access to the latest bits.  


Like I said, these are just a few of the talking points about why you might choose Red Hat over other projects.  There are many, many more and I'm sure others will chime in with why they choose Red Hat for their organizations needs.


If you have any questions, feel free to ask.


John Ruemker, RHCA
Red Hat Technical Account Manager
Online User Groups Moderator


This probably won't win me points with RedHat, but, it's always good to consider all sides of an argument...


Overall, if your customer's rationale for wanting to run CentOS is the licensing costs of RHEL, a better option for them might be Scientific Linux. SLIN is much faster than CentOS at version-matching RedHat (it was actually some of the RedHat employees/contractors I've come into contact with suggested SLIN over CentOS for when you can't justify the cost of RHEL). SLIN had 5.6 and 6.x matched  versions out within days/weeks of RedHat doing so whereas CentOS didn't get their 5.6 clone out the door until the first week of April. 


If you want a good argument for "why we don't want to run CentOS", point the people asking to and look at the lag-time chart. Some of the lags are rather "non-trivial" (which, in the security-patch world can be deadly). Granted, you can always manually update packages that RedHat's released fixes for, but that gives you the choice of maintaining your own RPMs or skipping RPM altogether.

I tell Java and Python shops how they will benefit from the -optional and -supplementary channels, even though the software in them is not supported. Most foreign packages are installed and forgotten, never updated. These two channels increase the number of packages that are regularly updated and available in an Enterprise class Linux distribution, a reason for which many go down the Debian derivatives route.

A second point is how well RH's products integrate with each other, something that a growing organisation must not forget or choose to ignore. From Satellite to RHEV, JBoss, etc. - RH could be a single vendor alternative application stack.