Slashdot Mirror


How Can I Justify Using Red Hat When CentOS Exists?

Bocaj writes "I recently spec'd out a large project for our company that included software from Red Hat. It came back from the CIO with everything approved except I have to use CentOS. Why? Because 'it's free Red Hat.' Personally I really like the CentOS project because it puts enterprise class software in the hands of people who might not otherwise afford it. We are not those people. We have money. In fact, I questioned the decision by asking why the CIO was willing to spend money on another very similar project and not this one. The answer was 'because there is no free alternative.' I know this has come up before and I don't want to beat a dead horse, but this is still a very persistent issue. Our CIO is convinced that technical support for any product is worthless. He's willing to spend money on 'one-time' software purchases, but nothing that is an annual subscription. There is data to support that the Red Hat subscription is cheaper that many other up-front paid software products but not CentOS. The only thing it lacks is support, which the CIO doesn't want. Help?"

2 of 666 comments (clear)

  1. Re:Update & security responsiveness by Red+Storm · · Score: 4, Informative

    Before I came to Red Hat I had a similar opinion. When I worked in Silicon Valley I thought "Why would anyone want to pay for Red Hat, I can't afford it so that means it's expensive." However after being at Red Hat for over a year my opinion has changed, and that has been because of some things I have witnessed.

    Support is one of the first things people think about, however there is a little more than meets the eye here. Let's start with the packages. Let's say there's a major exploit in SSHd, you will likely see a fix from Red Hat within a few days, which will then be available via RHN. The source to the rpm will also be available at ftp.redhat.com due to the GPL obligations. (More on the GPL and RH later.) At this point in time RH customers have the patch available, in this fictitious scenario let's say it took RH 3 days to release the patch from time of exploit publication. CentOS users still don't have the fix, plus CentOS operates somewhat as a "Black Box." You will get the fix when they get around to it, let's say that takes two weeks before it's released (Could be more could be less). That means your systems are vulnerable for about two weeks, in some shops that's an acceptable risk, in other places it's not.
    * Support from people is the other thing that people think about. Have you ever had to call RH support? If yes have you ever talked with an idiot? In the many times I have called RH support I have not dealt with anyone who I felt was sub-standard. Most often the problem I have seen is when the clients I'm working with do not present RH support with the information required in a timely manner. When the answers come back they often link to other knowledge base articles and have clear steps to either solve the problem or to better understand some of the complexities. When a solution is found and there is not a KBase article I understand (I may have heard wrong here) that there is an obligation to write a KBase article. I know that tickets are reviewed after they are closed. One ticket I opened regarding Satellite for a customer is getting discussion amongst the Satellite developers about how to best handle the same scenario in the future.
    * Support from Articles, this I feel is a real hidden Gem of RH. Nobody knows about it until you have a subscription, and then everyone is so used to using Google for their answers they forget to start here first. The KBase articles from RH are phenomenal! I had a customer ask me how to rebuild the RH ISO image to include their own KS script. I could Google and find 10 articles talking about much of what I'm looking for or search the KBase and find one article that has every step needed for modifying a RHEL disk to have the KS script on the disk.
    * Training. Having been through a few RH training classes I can say they are all very good. Yes there are some areas where I have questioned the need to know some things, but that is normal, but I'm never left feeling like the class was a waste. I have always walked out having learned many things which I can use later.
    * Consulting. Yes there are many open source consultants who can come onsite and help implement a solution or fix something, however how many of them have access to the people who wrote the Distro or maintain the upstream project? RH has an internal list just for technical questions, many of the engineers are on this list and very technical answers are delieverd. Often SAs (Solutions Architects) and Consultants will post questions their clients have asked. I have yet to see a response of "Why would you want to do that?" or "RTFM."
    * Additional products. Red Hat takes upstream projects and repackages them to integrate tightly with RH. Satellite is one example, it comes from Spacewalk and is designed to help keep internal systems up to date and patched according to their channel assignment. Could you use Spacewalk to manage your CentOS machines, yes you can! However let's say you have a problem getting Spacewlak to work right, or there's a bug, what kind of support

    --
    ---- Fight to protect your right to keep and arm bears! ummmm... ya I think that's right....
  2. Re:Support them from your own money by mlts · · Score: 4, Informative

    There are two reasons why I am speccing RedHat over CentOS, and neither have to do with support:

    1: Application support for production systems. Yes, it shouldn't make a difference, but if I call in for support on an application that specifies the list of supported operating systems, and its not RedHat, there is a good chance I'll get laughed off the phone with "sorry, no app support until you have a supported OS".

    2: FIPS, Common Criteria, and other certifications. These can mean the difference between "due diligence" in IT versus bad faith when it comes to an audit. Yes, this is pure legal eagle stuff, just like the requirement that the 64 CPU POWER7 box in the rack has to run McAfee, but it means the difference between passing an audit, or perhaps getting a contract terminated.

    This doesn't mean CentOS is bad. It just means that having the certificates that come with the commercial version of RedHat may mean success or failure when the CPAs and the JDs are done extracting their pounds of flesh.