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?"
The only thing it lacks is support, which the CIO doesn't want. Help?
Then you get CentOS and stop trying to spend other people's money on things they don't want to. If you care about Red Hat getting their support, then donate to them yourself, from your own money. Red Hat sells support service, and that is their product. Otherwise, it's just a compilation of others software, just like CentOS is. It's obvious your company doesn't need the support service so CentOS suits you just fine. Pushing an agenda down others throath doesn't help open source's image either. It should come from their own willingness to help or by providing so fantastic service that people actually want it.
By and large the CentOS team do an excellent job with the distribution - but it's a volunteer effort and there have been some notable times lately when important or security updates which have been shipped by Red Hat run late with CentOS, sometimes by a considerable amount of time.
If the CIO wants CentOS over Red Hat, he also needs to be prepared to accept the risk of delayed updates, no guarantees to updates or bug fixes and that one annoying time a particular server suffers an obscure bug, there won't be a vendor to go back to for obtaining a resolution.
You are lucky your CIO is not wedded to Windows. Stop complaining.
If your CIO believes his bench is strong enough to support CentOS without formal support (or using CentOS consultants instead of prepaying for RHEL), then he's making the right call.
Incidentally, I have very rarely gotten paid support for any software product that was anywhere near worth the price paid; support calls would typically devolve into blame games and shit would not get done until I got out strace or ethereal and could call folks out on their shit.
If your org does not have a strong linux bench or the linux stuff is not a core infrastructure component, or if your CIO manages via powerpoint and bullet points, then outsourcing linux skills to RH could make sense.
Give Red Hat a call. Seriously, if their sales department can't justify it for you, it's not justified.
If you want news from today, you have to come back tomorrow.
The only 2 reasons I can really think of are Redhat support (which, at the place were I work, barely gets used. In fact I believe we are migrating to CentOS because we can't justify the cost of support with how often we use it), and the release schedule, because it seems like CentOS is run by the seat of their pants, and they'll release when they feel like it.
If you can't answer the question 'what does the support buy you?', then you can't answer this. Most of the time, when people talk about support at the enterprise level they mean adding features and fixing bugs that are important to the company paying the bills. Do you have the expertise in-house to do this? If so, then there is no advantage in Red Hat over CentOS (unless it means you can make some of your in-house people redundant). If not, then it has some value. If you can do it all in house, then do: that's the main economic advantage of Free Software, that you always have competition when it comes to providing support, you never have one vendor that is the only one that can fix the bugs that you care about.
If you can do it in house, then don't try to persuade your boss to let you pay Red Hat, persuade him to let you send any fixes or enhancements that your team makes to the relevant upstream projects. This is likely to be much more valuable to those projects than your handing over a pile of money to a third party.
I am TheRaven on Soylent News
If you have a technically skilled support team who are willing and able to get into a bit of C coding, the "free" linux distros are viable. If your support staff are pure admins and don't do C coding much/at all, they'll struggle to maintain Linux without someone like Redhat backing them up.
Also, it depends on the app - if it can fall over for 2 days at a time without much of an issue, who cares about support? If an hour of downtime is a big issue, you need someone who is able to fix it Right Now (TM). If your local team is good enough, that's fine, but mailing list/forum support of free software is down to the goodwill of the community. They don't care if your app is down, they have day jobs and social lives as well. With Redhat, you can get someone on the end of the phone 24x7.
CentOS is good but slow; AFAIR Red Hat are working on 6.2 whereas CentOS 6.1 isn't even out yet. I use CentOS on my telecommuting system but considered paying for Red Hat last year when security patches got weeks behind.
So CentOS will save you some cash, but if you want to keep the OS up to date with fixes then you'll need to spend some money and buy Red Hat.
Go with CentOS as the CIO asks, and suggest one additional action: a modest donation to the CentOS team (less than RedHat support of course).
The real motivation is to get on the good graces of the primary CentOS developers/packagers, and develop a relationship so that if the company runs into something very difficult that they can't solve at once, they will pay for some direct one-on-one consulting from these developers as needed, and not as an ongoing expense.
And while sometimes the community is great, other times they make me want to stab myself in the eyes.
It really depends how deep into system your getting. If its the kind of thing that could run on ANY linux distro, you'll be fine as there is such a large community that can help. However if you find issues which crop up perticuallry with _centos_ and nothing else, and you require something which isn't "normal" in centos.... i.e.. not in the repos and your not happy building software yourself (which is kind of silly in linux but wouldn't surprise me these days) then you could be well and truely out of lucjk.
So...
If you can admin yourself, build your own software and fix it yourself - centos works fine
If you can't, you need that levle of extra support red hat offers.
Disclaimer ( I've never used red hat technical support, but have worked with random other companies who do technical support as my roles in IT work places and I think I know what to expect.
- http://www.milkme.co.uk
The only thing I can add is Liability. RedHat assumes some liability in the day to day operations of your company. Liability which if you sell to customers (aduh) they require for certain forms and certifications. Insurance is not enough. We're talking SOX, we're talking HIPAA etc. At the end of the day though, just remember that these are just tools. No different than someone saying "I want a stanley hammer" and you getting a black and decker.
I've written a few whitepapers on Support and Maintenance, and in my surveying of customers, liability or the ability to checkmark that their supplier/vendor has liability for the code they use to produce their goods has been a very GOOD thing in a few cases like government and lawfirms.
Yo Grark
Canadian Bred with American Buttering
CentOS went three months without a single security update earlier this year, who in their right mind would touch it given that history?
I agree with this. I have had customers running RHEL and CentOS and there have been a few times where CentOS does not keep pace with RHEL (most notably with the RHEL 6.x release). Support for issues is one thing but if the OS is not patched because the vendor, in this case CentOS, does not push them out then what recourse do you have as a CentOS user? You didn't pay for it so, to be blunt, "Sucks to be you." You take your chances when you choose CentOS for production environments.
You are lucky your CIO is not wedded to Windows. Stop complaining.
Not only that the CIO seems to know that Linux has various distributions serving different needs and knows of CentOS' relationship to RHEL. Not being a Windows only guy is great, but knowing that Linux is not a singular unix-like operating system is even better. There is actually no real evidence that the CIO is making an ill informed decision. He may be of the opinion that it is, or should be, within the IT department's capabilities to support these systems. More so if the systems are for internal use, less so if they are accessible by the public.
Since ANY system you use will require that you learn SOMETHING about it your title is misleading.
The scenarios are:
1. Your people can already handle the task
2. Your people need to learn more and do so without additional expenses
3. Your people need to learn more and do so with additional expenses
4. Your people need to learn more and do NOT do so
5. You outsource the project and dump the scenarios onto the outsourcing company.
It doesn't matter which platform you choose. So Linux is still free (and Free like speech) as long as you have a brain and can learn.
The only thing it lacks is support
That's you, right?
Its a whole different ballgame if the boss is willing to hire someone who happens to be a dev for the OS.
That is roughly the position I operate in since 1997, but in a Debian world.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
Some years ago we set up all of our systems using RHEL with a paid support subscription. As a government agency we considered this the proper risk averse thing to do. When we had an actual issue that required technical support, we discovered that the people tasked with delivering the support were clueless and once the query was laboriously escalated up the chain, we found that we were met with apathy, not much more clue and no effort to dig into the issue.
So we changed to another distro, stopped paying for support, and on the occasions where we do run into something strange, a few minutes of web searching usually uncovers an answer.
It would be *very* hard to make a compelling case to us for paid support these days.
One company I worked at would _only_ let us use RHEL because it was an Enterprise level OS which meant if there was a problem with it, then we could get support if it was beyond the SysAdmins but mainly because it meant they had accountability.
Most of the other companies I have worked at have used CentOS because it is free.
If you need the support, accountability and the stability with release cycles and patches etc then go RHEL. If cost is a factor and you don't mind not having the backup there if things go really bad with support, go CentOS. Just weigh up the pros and cons and go in batting for the more appropriate solution.
I have to admit that the place where we used RHEL, management changed and the new manager in charge of signing off my PO's was a bit of a Microsoft fanboy and wouldn't approve the renewal of our RHEL support agreement because 'I don't see why I should pay for support for a free Open Source solution' which I got told after he spent a decent amount of money for an Exchange+Blackberry solution. Due to his attitude, we lost a sale to a bank after they did an external security audit on us and needless to say, he only kept his job for a few months after that. It didn't stop him trying to blame me for the servers not being under support, thankfully I kept all the correspondence about the situation :P
Now I am currently stuck with our preferred vendor for Linux being OEL (Oracle Enterprise Linux).
If you need to explain why you were hacked with a common exploit that's been in the wild .. say 12 hours after Defcon.. you need real support, even if it appears passive and monitors your vulnerability and sends you a little reminder to "patch". One of the realy nice things about Red Hat Network is it "proactively" monitors the status of your machines and "suggests" patching for specific vulnerabilities by CVE.
I can't imagine "anyone" with experience suggesting such a thing.
CentOS is great.. and has stated goals.. but no one is paid on the CentOS project to create patches and update systems using CentOS.. its best effort only. At times its only porting of a patch released by Red Hat with no testing. And it almost always, by definition "lags" behind RHEL. CentOS does not port forward, patches originate upstream and port downstream.
While some third party software that you buy will state "should work with CentOS" that rarely extends to "supported" since they would be on the hook to support the OS as well.. or defend their position its an incompatibility with CentOS.
The more binary capability you need the worse the situation gets, for example with Tape Libraries and Backup Software, Antivirus software, SarBox software.
You might get away with it for a very short time, but as the subrelease numbers increase the differences begin to appear.
The most sensitive point is CentOS cannot be recomplied to be identical to RHEL, they have to use different kernels and or compilers since they only have access to source.. so its not a true clone. It strives to be that, but its still not the real thing. And with recent changes in packaging greater differences are going to appear.
Its such an obviously, strange suggestion, its almost not really worth discussing.
People who arrive at a conclusion "irrationally" without all the facts can rarely be "reasoned" out of the conclusion.
Bottom line, it is not Red Hat Linux.. it strives to be as much as possible and that is its charter.. but there are differences.
Paying for support is a whole other issue.
Support can be defined to be "community forum support", "email support", "phone call support", "remote login and fix my problem support", "custom software development support", "patch support" which can be broken down into "security patch support" and "bug fix support".
At a bare minimum you want "security and bug fix" support that's the real reason for signing up for Red Hat Network. You get proactive monitoring and timely patches for known documented CVE exploits that are retroactively tested and easy to apply. You get access to a bug tracking and resolution system which lets you log a bug, and see it progress throughout the system. You get access to incremental subrelease media so that you can deploy new systems without rolling all of the patches released since the initial release across the new system.. it keeps the install system up to date and concise.
I mentioned before, but really like that the agent you run on the system notifies Red Hat of the patches installed, they diff those between what they know is available and proactively send you an email to remind you if one of your systems is "exploitable" by a known CVE. Red Hat documents or converts bugs into CVEs that are industry wide that can be referenced and tracked across distributions, even across different Operating Systems. That is "Hugely" important, it becoming the gold standard for stating "yes we are test and verified and safe from that exploit" to a co-worker, a boss, or a judge.
CentOS's release schedule has been really struggling recently. Release 6 was almost edging a 250 day delay over Red Hat.
CentOS have still to announce an official date for 6.1 to be released, which Red Hat released back on May 19th. There is a lot of uncertainty regarding CentOS releases and as such in my opinion makes CentOS not the ideal choice for the enterprise.
Other advantages are Red Hat's support services and the Red Hat Network (RHN) are second to none. RHN alone is what convinced us to pony up money for licenses.
The gist of the advantages are: better support, quicker updates/security fixes, easier and centralised management of multiple servers with the only disadvantage being a price tag.
you don't want to be pulling your hair out at 2am in the morning... or worse yet, at 2pm in the afternoon, during a deployment/conference/expo/etc.
If you're deploying anything straight to production without testing that exact thing somewhere else first, you deserve whatever you get. RHEL can't cure that level of stupidity.
They don't grade fathers, but if your daughter's a stripper, you fucked up. --Chris Rock
The answer depends on the size of a company. If you are at a small, cash-strapped company, where more possible server downtime is an OK risk because the company really doesn't have any money, then CentOS may be the best route to take from a business standpoint.
We can get a rough idea of the size of your company from what you said. You said they can afford Red Hat, which would tend it toward a larger company. The company also has a CIO, which also tends it toward the larger. That you have input into the discussion of Red Hat or CentOS, and the CIO is involved in this kind of discussion, and he goes for free over supported as he isn't high on support would be something that would show you are probably not at the largest company.
Shit rolls downhill. There is a tendency of the higher-ups to not want to pay for support, not want to pay for new machines and software updates and the like. Why have 100% patched, supported software and hardware when they can have you running around all weekend trying to fix things and plug leaks when this old, unsupported infrastructure goes down. And then that it went down is your fault - you're supposed to keep the systems running and they did not run.
A CEO or CFO pushing against a CIO and saying lets not buy supported OS software is normal. A CIO should be pushing back and saying, except in extenuating circumstances, every server, every server OS, and certain types of software (Oracle or whatever) running on those servers need to have support. A CIO should be looking out for his infrastructure, his team etc. Weak, incompetent CIOs are the ones who never argue with the CEO and upper management - they say yes to everything top management says, and then run to their team in a panic telling everyone they have to implement the top managements crazy demands. Competent, smart CIOs have a little more backbone, and know when to say yes and when to say no. I have been at many companies over the years, and honestly, the entire company is much better served by a competent CIO who says no to the CEO once in a while, then a weak, incompetent CIO who says yes to the CEO for everything, even when he can't deliver.
A CIO who says something like yours did about OS support is either weak or stupid, or both. Honestly I'd polish my resume, spend more time professionally networking, start going on interviews, and seeing if I could find somewhere better. A CIO who says we just don't have the budget or there's extenuating circumstances or whatever for no OS support might be understandable. What he said is a sign of him/her being weak and incompetent, and you can probably do better. It's also a potential sign of bad times for the company - if your CIO is weak, who else in top/middle management is weak? Why does the CEO allow a weak CIO?
Are you kidding? This is *perfect*. Complain three times in meetings with as many witnesses as possible that "this exposes us to risk of downtime and high support costs", and be sure to end with "...this is your call, but its against my professional advice". Have that minuted.
Then, if the "train jumps the track", it won' be you who catches hell. You'll get your RH soon enough.
And it's *perfect*, because, like a military man asking for $800B next year instead of $700B, you come across as money-hungry, but honestly so, in service of doing your job well. No special approbation will attach. So, you don't lose significantly in the event that all goes swimmingly for many years on end, and you look prescient and wise if anything goes bad.
Just compare the release histories
Cent OS has a lag of anywhere from around a month, to 9 months in the case of 6.0, and 5 months and counting for 6.1. I have no idea of the delay for bug fixes, particularly security bugs, but I wouldn't be surprised if there was a decent delay there as well.
For the support angle, it's not so much the case that you're going to call them up and ask how to configure apache. But if you do encounter a bug that a real issue they're going to take it a lot more seriously if you're paying them some money.
Also note that 3rd party packages are generally packaged for RHEL, I recently tried to set up a Cent OS virtual server for my own use and ended up switching to Fedora since the LDAP package I wanted couldn't be installed on Cent OS. And that's not just the first example, I remember a previous co-worker who convinced his manager to get RHEL after screwing around with another 3rd party app that didn't like Cent OS.
Cent OS is great for some uses, but it can also be an extra hassle, and if you've got the cash to avoid the potential complications I'd go for it.
I stole this Sig
Be prepared to seek employment should you decide to let the "CIO" read this story.
It's very likely that a CIO who knows the difference between CentOS and RH and can take a risk of skipping support reads Slashdot on his own.
Just a very short refutation:
counting numbers of security advisories issued for a product is an entirely useless metric when it's up to the creator of the product under what circumstances to issue an advisory. Red Hat could stop issuing security advisories for anything tomorrow, and by your metric, it would then be the Most Secure Thing Ever.
By counting advisories and then ranking on the basis that more advisories = less security you're essentially punishing good behaviour. It's not a _good_ thing to encourage companies to stop telling you about security issues.
Red Hat is the free rider, most of what you get in their distro didn't come from them. Debian gives more than Red Hat. Red Hat could die, and GNU/LInux will go on.
When he's unable to to transfer his liability and diligence vis a reasonable commitment of support for business critical functions?
For god sake! Nothing against CentOS - but it's three guys with Rsync and a listserv. One of them went missing at a key moment, a couple years back!
"Flyin' in just a sweet place,
Never been known to fail..."
CentOS's release schedule and priorities are centered around F5 Networks need to rev their Big IP product. It's not "seat of their pants" it's "do enough to keep our product happy, and then, well, whatever."
Or at least that's how it was when I worked at F5.
And Red Hat then, more recently, started making things hard for CentOS because they know the above is true. They stopped shpping "stock source plus patch files" and started shipping patched sources.
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
If we are talking about end users or hobbyists, your point would be fairly unassailable.
However, "Linux is free if your time is worthless".is aimed at business situations. It based on the fact that time is money. So it is not a useless quote when talking about Linux and businesses.
The quote refers to the concept known as "Total Cost of Ownership" (TCO). This is a 3-Dimensional concept that includes the cost of downtime, system maintenance, and future costs for adapting to software upgrades and industry changes; in the universe of TCO, the price to purchase and install an OS is practically meaningless. And I mean meaningless: numerically speaking, when you have a company where downtime costs $10,000 an hour, exactly how significant is the cost of actually purchasing and installing the OS? Absolutely zip.
TCO dictates that such a business would be better off paying $100,000 to install and support an OS that will provide you 10 seconds per year of downtime, rather than paying $0 for an operating system that results in one day of downtime (which would set you back at least $240,000). *
The point is not that Windows is not free, everyone knows that; nor is the quote you're contesting denying the fact that Linux has zero cost to purchase. Linux may have zero cost to purchase but when you are paying someone to install it and you are sacrificing hours of productivity to switch to it, it is not free.
The fact that your servers and systems will not get built and magically deployed by Linux elves, says it is not free. From a TCO perspective.
Please don't get hung up over the 1-Dimensional concept of "purchase price" when talking about whether Linux is Free[tm], at least not when talking to a competent business. Businesses look at this issue from a 3-Dimensional perspective - as in, TCO. Of course, you can ignore TCO and stick with judging an OS by a 1-Dimensional concept like "purchase price"; but if depending on your mission imperatives, this may bite you on the rear.
Your argument only shows that the masses do not yet understand that competent businesses barely even look at the purchase price of an operating system. They look at TCO.
All of this basically means that you may think the quote is useless, but in fact it is the basis of any competent business's IT strategy.
* It just so happens that Linux's installation price IS free, and studies suggest that its down time less than Windows. Plus, now Linux applications have largely caught up with Windows. Linux is definitely more secure-able. But from a TCO perspective, Linux is not free.
Now I'd like to wrap two responses in one - this part going to the OP. The question of "can independent Cent OS support guarantee us downtime equal or less than going with Enterprise Linux?" is absolutely critical to the credibility of their decision to go with Cent OS. Allow me to distill that into an equation:
E= (I1+S1+D1 * C) - (I2+S2+D2 * C). The magnitude of folly in choosing CentOS over RHEL is represented by E. It is folly if E is greater than zero. It is epic fail if E is really really greater than zero. Do note, from my arguments above, that C is by far the biggest number in this equation.
I1 = cost of deploying CentOS (including labor)
I2 = cost of deploying RHEL (including labor)
D1 = downtime in hours (CentOS)
D2 = downtime in hours (RHEL)
C = cost of downtime per hour (applies to both scenarios)
S1 = cost per hour of CentOS independent support (this includes maintenance, upgrades, deploying software)
S2 = cost per hour of RHEL official support
--- Grow a pair, liberals... stop letting the Republicans bully you!
OK start with the Red Hat License agreement. Have any of you read it? In a nutshell, it says that anywhere you run Red Hat on a server it requires purchase of a subscription. And you can't buy a workstation subscription for a server, it has to be a server subscription. Subscriptions are based on 'sockets', which means CPU in real terms.
A 2 socket RHEL license costs $349/year on the 'self-support' model, and a 4 socket license costs $1,598 per year for standard subscription. Compare that to Windows Server 2008. The cost is $722.99 on CDW right now for W2K8R2 Standard. BUT, that's a one-time cost. And you get patches for free, regardless if you have a support contract or not. Figure that a Windows Server version may be supported for 10 years or more (2003 will run through 2015.)
Red Hat: $350 per year for 12 years = $4,200
Windows Server: $722 total, for 12 years = $722
That ends up costing you six times as much in license and support to run RHEL. Extrapolate that across hundreds of servers, and it becomes a monstrous expense. 500 servers = $174,500 per year. And yes, I assume you are going to re-buy a license for the new Windows Server one or two revs into the future.
THIS is exactly why we are not using RHEL in a highly compliance-oriented industry, and why we elected to go with CentOS. In the end we're going to be doing the support ourselves anyway, and Red Hat's cost structure is outrageous for what you get.
There is no such thing as a "one-time issue" with RHEL. You have to pay for a yearly minimum support contract, for the right to use software that has their trade marked brand name and logo's embedded. Once that runs out, you should either renew, or remove the offending binaries, documentation and logos off your systems. You do get update binaries in this minimal contract, which is what you really want anyway. Waiting for CentOS to come up with those may be the difference in having your systems compromised or not. There's nothing wrong with CentOS, but it's always behind RHEL, because of the mere concept of it.
OP: make sure you make the CIO sign for the fact that he's running software that's not supported on enterprise level, or certified to run on the hardware infrastructure, or approved as a supported platform by any of the applications running on the OS. Any and all extra expenses and damages resulting from that, are a risk he has to willingly take, and just to cover your own behind, I would recommend you have him sign for that.
I was promised a flying car. Where is my flying car?