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.
Red Hat is a cooler name, duh.
You are lucky your CIO is not wedded to Windows. Stop complaining.
CentOS wouldn't be around without RedHat. When you buy RedHat, you aren't really buying the software since it's free anyway. If he doesn't trust the technical support RedHat offers, that's what you'll need to research well and present to him for a decision.
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.
Centos is awful. I have no idea how to track security updates which is probably the most important thing. Other distributions have security updates linked from the front page and make things easy.
Tracking security updates should be your number one priority, everything else is easy.
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
Seriously, if your recommendation was to go with a product with paid support and your CIO is opting to go the other way, then get it in writing detailing the exchange. Nothing wrong with Centos. Nothing at all. Great platform and great support. However, there are products out there, or drivers for said products, which will ONLY work on a RHEL box because of RPM package dependencies or library linking to libraries of different names/etc. When that time comes up and it results in downtime, you don't want your manager or worse yet, the same CIO riding you for an answer as to why it is taking you so long to get a "standard" RPM installed to get things working again.
I've used RHEL, CENTOS, Oracle's EL, and Ubuntu... and there is ALWAYS something that needs a driver or a package installation that breaks because it didn't support the distro/flavor/version you have installed. Alien and other tools can only do so much... 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.
Winged Power Photography
The boss doesn't believe in support. CentOS is a product with no support. Do it, and if shit hits the fan you have your big "I told you so", hopefully in writing. If it all goes to hell, show that to his boss, assuming he has one. It's one thing if management doesn't understand, here they apparently do understand but disagree. Then they're free to fall on their own sword IMO.
Live today, because you never know what tomorrow brings
How can I justify redhat or redhat-based distribution when there is debian?
- To understand recursion, we must first understand recursion -
There are other issues with using CentOS instead of Red Hat. As of late, the timeliness of updates has not been acceptable for a security minded organization. The leaders of the project have shown no desire to open up the process to other contributors from within the community. It's gotten bad enough that quite a few companies that I consult for have started switching to Red Hat (or Scientific Linux). I think it's a fair assessment to say that the future of CentOS as an enterprise distribution is in question.
If your CIO won't consider paying for Red Hat, you owe it to yourselves to look at SL. It's backed by quite a few research organizations and universities. They release quarterly status updates. They turn out updates significantly faster than CentOS (many months faster for 6.0 and 6.1) and security updates for packages are faster as well.
From the people that created what you are using.. That is justification enough.
Having someone else to point fingers at when things fail should not be discounted.
---- Booth was a patriot ----
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.
Your CIO is already paying you. Do your job correctly and your CIO won't need a support subscription.
If your concern is over the ethics of it, wash your hands because it's not your call. When you get to be CIO you can make decisions about where to spend the IT budget. Raise your concerns, do what you are able and move on.
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
From what I've seen, large enterprise customers prefer to have support. Many will in fact not use anything that doesn't have "enterprise class" support. Maybe your company will be fine without such support, but then again, maybe it won't be. When shit hits the fan the CentOS developers aren't going to help you out, and Red Hat certainly won't either. But if you don't think you'll ever have a problem with the OS or a distro provided package, then go ahead.
I sympathize with your boss's disposition. Paid support often is absolutely worthless. I don't think Red Hat's support is worthless though.
It seems like the only reason you've outlined is "because we have money". What is your justification for wanting to use something that costs money (usually not a small amount either). If you really just want to spend money, you could always identify those instances where RHEL support will buy you something beneficial and spend it on those. Alternatively, you could donate (equipment or money) to the CentOS project.
In order to make the headline question nice and small, you didn't specify why you want to use Red Hat over CentOS.
Was it because you find the support from Red Hat valuable? You've had trouble in the past and really want to be able to get some technical help when problems come up?
Was it because you just want to make sure that Red Hat gets paid for the work they have done, or which the CentOS goons just leach off of?
Personally, if my direct reporting manager made such as requirement of me, I'd just up and quit. Actually, I already did that, and recently. That being said, I'm a Debian guy so I don't really have this particular problem, but when PHBs make demands of saving money now in the name of causing problems later, I'm out of there.
The only thing it lacks is support, which the CIO doesn't want.
The only real question here is whether the CIO is in error about whether you need a support contract. If you don't need a support contract, it simply doesn't make sense to use Red Hat instead of CentOS.
Red Hat is a profitable company. They make money by selling support contracts and by providing training and certification. Training for Red Hat is training for CentOS, and software developed for CentOS is software developed for Red Hat, so Red Hat actually stands to benefit from the popularity of CentOS.
Centos is a community effort and would be easier to infiltrate and infect with malware than official Redhat. While it's not the most likely scenario, the CEO and CIO may find themselves in a position where it could be argued that they did not exercise due diligence and care should your company lose data or be compromised in some other way. The breach doesn't even have to be related to Centos itself. They just have to be audited or investigated for some sort of breach and it happens to come up that instead of going with a cheap and trusted supported and paid alternative, they got cheap and greedy and cut corners.
The only problem with this line of argument is that it can backfire big time: the execs may panic and go too far - for example banning all open source or free software.
These posts express my own personal views, not those of my employer
There's really only one question to ask the CIO: if we're not paying for support, what will we do if we encounter a problem in the OS that we do not have the expertise to solve?
If you've got a Scotty-like reputation for problem solving, then it may simply have never occurred to the CIO that there's a problem you and your team can't solve. Make it clear that there are specialized areas of expertise involved here and you don't staff to investigate and solve them all. If you're running a mission critical system, then time-to-resolution matters. With Red Hat you can presumably get a service level agreement with a time-to-resolution clause. If you're just Googling and begging for help on forums, you can't make any guarantees. The CIO may assert that this is a reasonable risk. Make clear that it's his risk, not yours, and if failure comes knocking, make sure it's at his door.
What do you mean they cut the power? How can they cut the power, man? They're animals!
I think we need to know if the centos systems will be accessible by the public or if they are strictly for internal use. If for internal use I think rhel support would be less of an issue.
If you have the conversation in writing where you have recommended RedHat and why but you have been told to get CentOS instead, go CentOS. Chances are all will be well and it will be money saved. If something does go wrong that a support contract would have dealt with, no one can blame you for choosing CentOS over RedHat and you might even get a few hours paid overtime fixing the issue yourself...
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?
Comment removed based on user account deletion
RHEL support gives you a very good backup plan. If something goes wrong with your Linux systems they will stand behind it and help you get it right. CentOS your on your own. While that might be fine most of the time a case could come up when no one on your team knows how to fix or do something and your stuck. RHEL will help you through it in a timely manner while CentOS might lead to long down time. As others have mentioned CentOS is way behind on building updated packages. Because of this you may be open to a security hole for much longer then you would with RHEL. The other thing to keep in mind is if your using any third party software they won't support you running CentOS. If your CIO really wants a free Linux distro I would go with Ubuntu. Your getting the same binaries are the paid version and if something bad happens where you need support you can get it pretty easily.
Comment removed based on user account deletion
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.
I've been on many projects that opted for Centos over Red Hat, and some in which the CIOs demanded Red Hat over Centos. All on various perceptions of what free means and what paid for means. Sort of a Rorschach test.
If you feel strongly about this, you might ask the CIO if you folks will be open sourcing the software you write, and if not, why not.
Ultimately, it's a question of paying in dollars or paying in other resources, such as admin time.
Instead of paying Red Hat to spend their time supporting their OS, he's going to be paying his own folks to provide that support. There will be no guarantees about how quickly vulnerabilities are addressed, no guarantees on when his systems will receive updates regardless of severity. His admins will be dedicating time to supporting the OS that they could otherwise be spending building *on top of* that base OS.
Free may save him some dollars in the short run, but as someone who's done sysadmin and ops work for the last decade, I can say with certainty that he *will* be paying those exact same dollars (or more) over the long run. Maybe he's okay spending dollars out of operating expenses rather than capital expense, but one way or another, those dollars will be spent. The main question he should be answer is how much value he's really receiving for those dollars.
In my opinion, he should spend the money on RH entitlements and let his sysadmins work on projects that aren't simply reinventing the same wheel.
This also doesn't get into any of the value-add stuff that the RHN or RH Satellite provides, such as easing and speeding up the audit process for SOX and PCI audits.
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.
Otherwise, it's just a compilation of others software, just like CentOS is.
No, that's not so. Red Hat does much more than simply repackage other people's software.
Have a look at Fedora.
If you want news from today, you have to come back tomorrow.
> Our CIO is convinced that technical support for any product is worthless.
I know of people who were lucky to have bought Redhat on a supported Hardware and getting a quite subtle question about a specific raid controller config which blocked them from using their compute cluster answered promptly.
You haven't given us any information to work with. The best I can infer is you want RHEL because the company has money. That's not a reason.
WHY do you prefer RHEL over CentOS? Are you at all likely to encounter an issue covered by RHEL that you can't solve in-house? If so, wehat sorts of issues? Are they things your department is supposed to be able to handle?
With commercial support, if and when you find a bug in the distribution, you have the means and leverage to have the bug fixed and possibly interim workarounds.
I tried putting a client on CentOS 5, and it was a disaster. EVERY Qt or KDE program randomly crashed on startup (sometimes it would run, sometimes it would crash), but there was no rhyme or reason to it. After limping along this way for a few months, they insisted that I do something. I removed CentOS, and replaced it with Kubuntu. Not a single problem since.
CentOS had demonstrated very poor quality controls, so I decided to stop using it. For customers with 3rd-party software that must run on only officially approved distributions (which boils down to Redhat) such as Oracle or ESRI, I use RHEL. For everyone else, I use Kubuntu. CentOS will likely never see another installation on any server I manage.
The CIO is right for the most part. But I would say this. You will need to replace the redhat support with one extra FTE in order to make sure that security updates match what redhat is doing.
If you consider CentOS, have you considered Oracle Linux. Why I've used RedHat: I use software packages not supported under CentOS. Those packages (including Oracle database software) are supported under Oracle linux. With Oracle Linux, you can choose to go a very-much-like CentOS path and not get support and not pay, or you can choose to pay and get support where you need it. Real support, not the "it is better to get help from the community than expect actual help from the company you are paying" kinds of support. I am NOT an Oracle linux user. I am evaluating this issue right now.
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
"Then"
"Flyin' in just a sweet place,
Never been known to fail..."
"The only thing it lacks is support, which the CIO doesn't want"
There's more than that it lacks, even for the basic customer. Something more important (to me, at least) that it lacks - RHN. RHN is great. Yeah yeah, one can set up a spacewalk server and update locally. I know. But...why?
Another thing CentOS lacks which is extremely important in the industrys I tend to work in: certifications. Has CentOS been EAL certified at any level? No. Will the DoD let you use RedHat over CentOS? No. Will a PCI auditor be a fan of your use of CentOS for your externally-facing website that processes credit cards? No. Does CentOS have enterprise-level QA processes for each and every thing that they are (because they are...) modifying? No. Would the FDA be happy with an OS vendor with no QA process? No. What's the indemnification that CentOS will give you in suits against Microsoft?
It's not as though the options are "CentOS" versus "Redhat with full support" after all. There's the self-support option, which just gets you access to allllllll the other things. And you can even be "that place" that has 500 servers but only bothers getting 50 seats...eh, whichever, won't really matter except for the indemnification part.
I mean, what industry are you in that the question is even worth pondering? If you handle money, sensitive material, or PHI you'll spend WAY more than that tiny self-support price in the bribes and obfuscation necessary to get ok'd with CentOS. I mean hell, Fedora has a more extensive QA process than CentOS. Maybe you should just tell your boss you agree with him so much you think you should use Fedora!
Yes CentOS is great in fact I use 5.7 as my webmail server, but what happens when the guy running Cent OS decides to vanish for 2+ weeks without anyone being able to get in contact with him as happened only about a year ago
http://www.osnews.com/story/21921/CentOS_Project_Administrator_Goes_Missing-in-Action
Sorry, don't see Redhat doing that one....
And the first time that bites the other "C" guys in the ass the whole department gets shipped to India, damn how much it costs.
Maybe this is a non-critical business that can afford time to fix things. But if the CIO thinks lack of payed support makes your team MORE valuable, it ALWAYS backfires. IT is always expendable.. We make too much money and aren't part of the "golf and hookers" culture. They'll never really trust us.
When your production instances running on Centos get rooted because of an unpatched vulnerability, and your company gets the same reputation for security as Sony, your entire board of directors will understand why you need support -- even if the CIO doesn't get it..
"Red Hat had this patched on 01-October, why were we still vulnerable?" is the kind of question a CIO hears right before he's fired...
Technology -- No Place For Wimps! Grateful Dead and Jerry Garcia Chatroom -- http://www.wemissjerry.org
1. Redhat provides more timely security updates. One ownag3 due to a patch being late in Centos, and your CIO will wish he had spent the extra bucks. This isn't terribly likely, but it should still be a concern.
2. Redhat provides indemnification. This can be a Big Deal if you get sued by someone. A large enough company with deep pockets is a target to be sued. (Patent lawsuits anyone?)
3. Redhat provides 24/7 support. Sure, your admins may be Super Great, and you never need the support, but what happens when the admin is on vacation, fishing in the middle of Alaska with no cell coverage? What happens when the Super Great admin finds better pay somewhere else?
With that said, I think Centos is a great option for a lot of people. I use it myself for my home machines, and have used it for small businesses. None of the above are terribly important for either of these cases, so Centos is a much better option. But at a certain point, largely dependant on company size, the above reasons are going to overshadow the additional cost.
AccountKiller
There's a number of ways you can deal with this, but one of the most important aspects is how you approach your CIO.
I'd strongly recommend you pick up a copy of Dale Carnegie's "How to win friends and influence people". It's mainly aimed at salesmen but there's a lot of information in there that's useful for people in all walks of life.
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).
We are not those people. We have money.
So your argument is that you should pay for it because you can afford to. Not because you have costed the benefits or one solution or another, but simply to "reward" RH because your company is in a position to pay.
On that basis your CIO is making the right decision for the company and its shareholders.
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
To be fair to your boss, I've witnessed plenty of "issues" arise with different software platforms that had commercial support and where the vendor wasn't particularly interested in resolving the issue. Perhaps we weren't big enough fish in the pond. I've also watched IT staff use that as an excuse for failure. In my personal opinion, designing around a closed source solution and having poor response from a vendor shouldn't let you off the hook. In a way, it's worse than an open system, because often you can't even get into the guts of the problem to fix it, even if you might have the ability.
The cost to a company for using a commercial platform is not merely in the cost of the licenses, either. You have to also consider the cost of license compliance and tracking. The energy my workplace spends in a year on tracking "seats" and negotiating licenses for closed-source programs is just depressing.
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.
But that's OK. In reality you get about as much desktop Linux support as Windows support... Buy the time you GET the support you could have just replaced the machine anyway. Systems configured to keep all the data on the network have their own "support" built in.
Obviously, the servers are for something critical enough poster things they need support... If only to cover his own ass.
I'd add it's fun to be the hero in an IT situation... Then you grow up and want to do the same work that took 60 hours in the normal 40 to do other things. Careful use of support contracts is how you make that happen... IT is funner when it's boring.
For example some stuff from IBM.
Their installers will refuse to install on any other linux variant, and rewriting the installers yourself is just not worth the effort.
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.
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?
How will your sysadmin organisation look like?
Who will be responsible to do the updates and upgrades? Who will administer the systems? Who will be doing housekeeping? Who will train the admins? Who will add new nodes? Who will decommission old nodes?
If to most of the above questions you are the applicable and sole answer then you have a severe problem. Otherwise you should be able to convince the CIO.
However, I wouldn't be surprised if your IT depts. combined amount to a rather small number of workers. And that the title CIO is an euphemism for "the guy that knows the owner and is responsible for IT". Starting from 20+ workers you really shouldn't have this argument and support fees should be a given.
One last tip: Be prepared to seek employment should you decide to let the "CIO" read this story.
I hadn't the slightest objection to his spending his time planning massacres for the bourgeoisie... (P.G. Wodehouse)
If Redhat are not happy with organizations like CentOS benefiting from the contributions they make to GPL protected software they have a simple solution: stop distributing Linux and write their own proprietary Unix clone from scratch. If they choose not to do so CentOS are free to build and distribute their Redhat based distro and users - commercial or otherwise - are free to use it as they wish,
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
It's hard to argue with free. And frankly in the many years I've worked with Red Hat, I've only needed support once or twice and in those cases the support was useless. Google'ing for answers is faster and more effective.
First of all, if "because we have the money" is the best persuasive argument you can make, I don't see your career going too far. What is your real justification for obtaining support? Do you do custom development which may expose the need for kernel patches? Or, are you looking out for your own career and thinking RHEL will look really good on your resume? Second, are you certain your company "has the money" to purchase support? Having been on both sides, I can guarantee the CIO has a far better view of departmental financials and the corporate big picture than you. Add to that one-time purchases are often treated differently than on-going operational expenses in the budgeting process. (People think IT is black magic; accounting is the root of all evil and makes technology look like child's play.) My guess is your CIO is facing one of two things. Either there isn't the money to spend, or he's under pressure to keep on-going operational expenses as minimal as possible. There is still the very real possibility of another economic downturn, and companies don't want to be left holding the bag of unneeded expenses. As such, he's asking just how often support would be used and not seeing a justifiable number.
Enough said! I suppose your CIO is capable of doing everything himself? Let him. [I work for a commercial software company.]
you can call red hat if you have questions you can't call centos it's the biggest don't use linux argument that support contracts for free software are hard to find
Put an arbitrary valuation of the businesses data within each server per licence needed and lost of service by hour for each and compare it to the cost of Red Hat licensing. If the data is valuable enough and downtime expensive enough then Red Hat Support is really worth every cent.
Support for the OS is one thing, but what about support from other vendors? For example, I'm involved in a project where a client has used CentOS throughout their solution. Now, they want patch management, backup/restore, etc...and have found out that none of the commercial solutions (and they need enterprise-grade commercial solutions) support CentOS, even when they have support for RedHat. So now they are pretty much screwed.
For your security, this post has been encrypted with ROT-13, twice.
seriously, if you don't like your boss' decision, then leave. too many times CIOs have their heads up their asses and don't listen to the techs in the trenches.
Remember kids, if you're not paying for the service, YOU ARE THE PRODUCT THAT IS BEING SOLD.
If you need support you buy red hat. If you don't need support you download Centos, or some other free for download Linux variant. It's not that hard.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
There's probably nothing you can do. You don't say what the project is about, or what you might possibly need support for, so I'm forced to assume that you're going to be running CentOS/RHEL in a common configuration on commercial-grade hardware. And if that's true, then your boss is right.
But more importantly, recognize this: the CIO is your boss. He made a decision, you questioned it, he reaffirmed his position, end of story. You deploy CentOS. If or when you need support for the OS (and not the application you're paying for), the blame will have to come back to him since it was his decision. And unless you weren't smart enough to get it in email, there's a paper trail too.
Now make way for the comments from other bitter Slashdotters who will tell me I'm wrong because they've allowed themselves to be scapegoats for their bosses' inept decisions.
If the firm uses CentOS today because they find that optimal, they may find paying for Red Hat support tomorrow optimal. If they use some other operating system, they will be less likely to ever send Red Hat money. So take this opportunity to educate the CIO so that if your firm is ever in the position of needing their services, he or she will know where to go.
The goal should not be to eliminate free riders. In fact, free riding is an inherent component of the open source model and many who are free riders today will become paying customers tomorrow. The economic model works when the number of free riders is not so high that it chokes off resources necessary to develop the platform.
Whether or not that is the case for Red Hat is going to have little to do with your firm's decision or people's sentiments about whether paying for open source software is the right or wrong thing to do, and much to do with the general incentives that their economic model produces. Red Hat knows there are firms like yours wrestling with the same decision, and that many of them will chose options such as CentOS, but hopes that there are a sufficient number for whom it is a good business decision to avail themselves of Red Hat's (and other open source contributors') services that the product will command sufficient resources to continue to improve.
-- My choice of computing platform is a symbol of my individuality and belief in personal freedom.
It's difficult to believe nobody here has discussed what availability http://en.wikipedia.org/wiki/High_availability#Percentage_calculation your boss wants for your systems. Likely different systems need different levels of service. Perhaps you only need 98% uptime for most of your systems and 99.9% for some others. Can your internal team ensure a particular system is back up in 8-9 hours? Perhaps a particularly critical system needs 99.99% uptime or better. In this situation it is unthinkable to not have external support available at a minute's notice. Now you have to look at what kind of SLA Redhat support can give you. Do they have a band of service where you can get on the line with an actual support person in less than an hour? You really need to know your reasons for each system rather than just setting a carte-blanch policy across all your servers, otherwise you're just paying a tax for having a running computer. And if you ask your boss if he wants 98%, 99.9%, or 99.99% availability and (s)he says "yes" with that blank look in their eye that shows they really don't comprehend the technical implication of each guarantee then don't even bother trying to handle this battle; you'll get nowhere.
You should collect data from your own organisation or others within your company that have used either Red Hat or CentOS in the past few years. You are looking for statistics like downtime (and impact/cost), number of cases opened and how they were resolved, and general information -- facts -- about their respective experiences. If your company has no experience with either, try to gather this kind of data from your professional network if you can. Then evaluate the data and produce slides showing both the raw data and its applicability (of lack thereof) to this particular project. Be sure to make the connection clear by showing how the risks and costs apply to this specific situation. You should also be able to clearly show the total costs in each year of each solution along with your projections -- again, based on applicable HARD DATA -- for how well each solution will work for your project. In the process of doing all this, you should have an open mind yourself about the outcome; that is, you should not enter it intending to justify one solution over another but rather you should be looking to see what the data justifies and supports. While your gut instinct has value, it is not a compelling argument, especially if the data don't support it. If that's the case, look harder: what are you missing about the situation? What information can you gather that addresses the missing pieces? Or maybe you changed your own mind by doing rigorous research.
If your company's CIO is a good manager, then this kind of data, compiled correctly and presented well, will sway him. At minimum, it will provide a clear focal point for discussion: he can argue about your assumptions, point you to other people to talk with to adjust them, or direct you to find ways to lower the costs you present. All of these are victories for you, because they give you an opportunity to change the outcome. You may not get your RHEL licenses, but you may get another head, or help from another department, a meeting with Red Hat to negotiate lower pricing, or something else that you can come up with to mitigate the risks and costs you identify. Worst case, you've made a clear presentation of the options that will be remembered if things don't turn out well; again, a good manager will at that point be honest enough to acknowledge that he made the call, and will admit to you privately that you were right. At that point, you should be ready with a set of recommendations for fixing the problem going forward not just for other projects, but also to salvage this one. If it's 2 years on and the underlying business need will be changing or going away soon, does it make sense to switch to RHEL at that point? Is there another option you've been researching to mitigate the problems you're having? Be ready with recommendations that show you understand not only the technical situation but also the business impact and the full gamut of possible solutions. Show that you are focused on solving the problem; don't miss that opportunity by gloating or showing him that you don't have answers!
Bad managers are difficult to convince of anything, especially if they are biased for some reason other than a desire to see the business succeed. If you're stuck working for such a person, there may be little you can do. In that case, you have to ask yourself whether you want to try to get a larger audience, preferably including the CEO, when you make your presentation. That path is fraught with career risk, but if your data is very solid and you are a good communicator who understands the business, the project, and the people involved, it may be worth it. You don't have a lot of other options. Frankly, the best thing you can do is find another job. It's usually not worth waiting for these people to hang themselves because bad managers tend to be hired or promoted by other bad managers; his boss probably isn't going to hold him accountable either, and will let him make you the scapegoat if things do go south. The middle and upper management ranks of most larger companies are full of people like these and your best bet is to look elsewhere if that's the situation you're in.
Ya know, I've never really understood that either. I had a former boss that like me got fed up with corp work and walked away and by the end he would just tell them flat out "Does your desktop come on in the morning? Can you get your email? does the web work without you being spammed by Viagra ads? Well do you think that magic elves come in and do that work?"
One of the last straws for me was this law firm I set up, which I thought I did a beautiful job even though they were cheap bastards. Everyone had a standard Dell Optiplex PC, a nice sonicwall in the closet, it all ran like a Swiss watch. I told them i didn't have time to be their admin but I knew a couple of guys, both damned good AND affordable, and gave them their numbers, so what do they do? One of the PHBs says 'Oh that's too high, I know a guy that's a WIZ and computers, he'll do a great job!" and I bet half the admins here are ALREADY cringing, but you ain't heard nothing yet.
So I get called back out about a year or so later because the "Wiz" got caught surfing porn and running a Quake III server on company time and "things are acting funny" so they paid me time and a half to come right out....acting funny....damn. I get there and the wiz has thrown out EVERY SINGLE BOX that I bought because they were "too slow" and instead put together a bunch of gamer rigs from Tigerdirect barebones. NOTHING matched, ALL of it was this nasty unstable OCed mess. I thought that was bad and then...I went into the closet...Jesus Tapdancing Christ! The braintrust had tossed the sonicwall for a pile of d-link routers you know, the shitty blue bastards? yeah those. and instead of the ISP I had set up he had set up a DIFFERENT ISP for damned near EVERY router! Apparently his idea of adding bandwidth was to chain on another D-Link and get another connection!
That episode and a couple of similar ones broke me of working corporate. if you work corp, you have my sympathy. They are constantly fucking you on the budget, constantly giving you too much to do with too little to do it with, and what is your reward? To get offshored or even have to train the H1-B they are gonna fire you for.
I don't know, maybe IT guys need a union or something. All I know is having family in construction and working IT frankly the plumber gets more respect than the guy who has to keep millions of dollars of hardware and software running, and that just ain't right. Maybe IT needs to have a case of the "blue flu" and everyone take off for 3 days, just to let them know how much you really do? something has to change because at the local college IT has become a ghost town. Nobody is learning IT anymore because they've seen how shitty the rest of us have been treated. Everyone is in either medical or legal.
ACs don't waste your time replying, your posts are never seen by me.
What's the indemnification that CentOS will give you in suits against Microsoft?
If my employer is bigger than RHAT, does this even matter?
Does it matter at all, other than being a marketing FUD-ish topic?
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
Drop him $100k and he might help you out?
And that's the point. When you pay for support, you are paying for somebody to be ready to help. That's expensive. But when you have $10k per hour on the line that kind of money is a bargin the one time in the year you really get stuck. Or better, you DON'T get stuck down because you had somebody to call before a crisis started costing your company money.
You're dead man walking already if you're tied to one specific distro and only that distro.
You carefully avoided describing why you selected red hat / centos.
If all you need is a generic "Bind" install or a generic "Apache" install, why deeply tie yourself to one distro? A sysadmin that only knows and can only learn one distro is about as useful as a dev that only knows one language or a salesguy who only knows one product and pitch. If thats all you got, you need hand holding and lots of space in the budget for the inevitable brain fart monetary losses.
Scenario: Horrific bug appears in red hat / centos / debian / ubuntu / whatever. Not in the other distribution red hat / centos / debian / ubuntu / whatever. You should be able to roll your app out on a new install of the safe distro in a couple minutes. Not hard if its all done in GIT and puppet and possibly running on a virtualized server.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
Why buy a support contract from an open source company if you can hire equal or better skilled consultants, or have an arrangement with a consulting service to always have a local guy on call? Aren't you better off with a local onsite guy who already knows you, your business, and your configuration? Thats kind of how it works in the Debian world... there's thousands of locals willing to provide support... for a price.
If, for the sake of example, you needed a Bind server running on Debian, why not hire on a contractual consulting basis a genuine Bind dev and/or one of the Debian Bind packagers?
You don't need support for "how to run the ls command", hopefully, anyway.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
I would say, if you are able to support CentOS using the skills available in your organization, by all means, go for it! You will not need the RH support. On top of that, you are not buying a whole lot with RedHat support. Look at their conditions and you see a lot of things like:
- No support if you run a customized kernel.
- No support if you run non RH packaged software.
- No support if you run it on "certified" hardware.
So basically, if you run it according to the conditions, you will not need the support. As soon as you do something that makes you need the support, it will fall outside the contract and you end up paying for it.
To be frank... your pointy haired boss seems to have gotten it right this time. Cherish it. Most of us never get to see that day!
There are arguments for using CentOS because you don't necessarily have to wait for the CentOS team to release a bug fix. You may be able to rebuild the software from source and just install it in either /opt or /usr/local. There are also companies that use CentOS on public facing servers. For example, host gator uses CentOS successfully. It isn't like there is not a precedence for using CentOS in the enterprise.
Don't buy support, just buy timely updates.
Self-support Subscription (1 year) $349
Although, I would suggest buying support for at least one set of systems in your test environment. That way you can get RH support and resolve any issues there.
So it's all great that the CapEx costs for CentOS are much lower than those for RHEL, however, what are the OpEx costs associated with the two? For most companies the initial expenses to purchase a product are nothing compared to those that are required to maintain it over the life of the product.
You can try to tackle this from a financial, support, or business perspective, but that's not the direction I'd go...
Red Hat funds a large chunk of the GNU/Linux development which you are benefiting from. They make a good product for a reasonable price (enterprise wise), and their competition is good for the software ecosystem. I want to see more companies follow their business model and promote Free Software. Given all that, personally, I think there is some, however small, level of moral obligation to support them if you have the resources. It's just the right thing to do - I think you feel it, and I know I feel it.
Tell your boss that you want to work for a moral company, and that includes things like not exploiting employees, recycling and green initiatives, and things like buying at least one copy of Red Hat Enterprise Linux if that's what you are using on your servers.
When he calls you a "linux hippy", just be like "yeah I'm a hippy, just like all the other hippies that got together, did what most people scoffed at, and created this software from scratch, for free, which you now want to run your whole enterprise on".
Personally, I don't understand the case for CentOS.
I get the case for Red Hat. If you install Red Hat, it *exactly* matches what the third party developer for the paid software you're using had when he developed and tested his software. When you need a bug fix, or you need him to examine a problem, your system will match his. And if you're doing any sort of government work, they have a process in place for accrediting your Red Hat system. Not so for CentOS even though it's so very similar.
If you're not buying third party software, a distribution like Debian or Ubuntu has so vastly much more open source software under package management (and integrated into their security updates process) that I can't imagine why you'd want to use either Red Hat or a clone like CentOS.
It seems to me the only real value case for CentOS is that I can use it at home for free and it's very close to the comparable version of Red Hat I use at work.
Advice to the poster: if you're buying any other commercial software to install on top of the OS, get the $350 "self-support" Red Hat option and pitch that to your boss on the basis that it will facilitate debugging of any issues which arise with the other commercial software. Otherwise, go Debian.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
How can you justify Centos with its lagging release schedule when Scientific Linux exists?
Maybe instead of a monetary donation to CentOS, consider providing a server mirror to help the cause. May be cheaper than "paying" for Red Hat, and it goes to further the cause.
When it comes to support - consultants are great for implementation. However, if you've got a really large installation and start running into obscure kernel bugs or other software problems unique to your installation, you'll need kernel engineers or other higher caliber software developers or systems engineers to really deep-dive the problem. Red Hat can provide that with support subscriptions (or one-time incidents). Can't say the same for CentOS - you're at the mercy of the community.
Same goes for rapid-paced updates to zero-day problems. Chances are, you're going to get a fix a lot sooner from Red Hat than you would from CentOS.
Do I leverage CentOS for small projects - absolutely. But I understand that while it's 99% Red Hat code, it's not Red Hat in every respect.
$ man woman *
-bash:
OK, here's the bottom line:
1) Red Hat includes support, and guaranteed updates, and you can be sure it will be continually updated in a timely manner.
2) You can call Red Hat for assistance
3) You also get content that is not included in any free distro, the Red Hat Value Added content
1) CentOS gives you a remastered version of Red Hat EL which is potentially 2 to 3 versions behind Red Hat.
2) You get the support you pay for, ie: Being told to RTFM before you're entitled to any assistance from the community. Help that's limited to what users of CentOS can give, because the developers won't waste their time helping you, even though it's Community ENTerprise OS, they really only put the distro together for themselves and don't really care about the community.
3) You can't be sure that the updates are up to date. In most cases, the updates you get are lagged significantly behind the Red Hat release, that it could leave a known security hole in your network, in a business environment this is dangerous.
Don't get me wrong, I love FOSS, and I infact use CentOS on my home server, but I also know that I have to rely on myself and those I personally know, when I need to fix something that I'm struggling with.
In a business environment, I would insist on only using a distro that has the backing and support of a company/organization that is capable and willing to support it, like Red Hat is, without saying RTFM before I'll help you. With Red Hat, you are paying for that support, and they step up to the plate to give you what you're paying for, regardless of how elementary or advanced your knowledge level is regarding the product, or the complexity level of the issue you're calling in about.
In other words, you get what you pay for, but in a business environment, you should consider if it's worth it to pay for support or get little to none.
A RHEL subscription provides:
The ability to file bugs via a paid SR and receive supported hotfixes
CentOS does a good job of releasing updates fairly quickly, though not necessarily between point releases. Especially if point releases occur when a point release for multiple versions of RHEL is released simultaneously. You can be stuck in a lurch for quite a while while CentOS's small team works hard to get things going.
As to getting bug fixes... this has primarily been helpful at my company as we write software that runs on RHEL and occasionally need to ensure bugs in RHEL provided software are fixed in a timely manner. It's nice to be able to escalate a BZ entry via an SR and a TAM or account rep.
Tech support you may or may not need. Perhaps if you're the only Linux "expert" or if you want that extra assurance or a vendor to "blame" if something goes south.
Ray
I would agree that paid support is for the vast majority of the time, quite worthless. It is just like insurance. When everything is fine, it is a waste of money. Even then, over a period of time, the insurance companies don't stay in business by paying out over the odds.
Paid support is like a bad insurance contract - when you go to claim, you are never sure just what value you are going to get. My experience is; about half the time I have had to call on a paid support contract for help I have nutted it out myself before the support service has. Never the less, when all else fails, any help you can get is better than none.
Give Red Hat a call. Seriously, if their sales department can't justify it for you, it's not justified.
My company has something like 20,000 diskless servers running Linux. Red Hat wanted us to pay for that level of support, which is ridiculous. Groups of several hundreds or thousands machines all netboot from the same image. Because of this, our needs for support is far lower than the number 20,000 suggests.
In the end, it was far cheaper for us to use CentOS and hire people to maintain the machines and their OS image than to pay what Red Hat demanded for 20,000 machines. Red Hat's business model just didn't fit, even though we wanted to have their support.
"Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager
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.
I have at least a couple of times had trouble with equipment and had theories as to what the problem was only to be told by the vendors support team I was wrong. Long story short and lost customers later, turns out I was right. There support was actually harmful.
I have been running Linux for 15 years in our ISP where downtime was a big no no. Research on online forums provides quicker cheaper solutions that just about any support I have experienced.
Our CIO is convinced that technical support for any product is worthless. He's will to spend money on "one-time" software purchases, but nothing that is an annual subscription.
Well, the important thing here is that CentOS is not just free RHEL, and the choice between them has engineering implications.
A RHEL subscription is not merely technical support. It's also software updates. CentOS has been notoriously slow about software updates, and the last thing you want to do is wait 6 months for a bugfix for an issue important to your business. Your CIO is going to look pretty bad if you have systems crashing due to an issue, with an available bugfix that you don't have access to, because CentOS hasn't carried it yet.
You can't report "bugs" in CentOS that exist in RHEL, and Redhat won't really listen to you unless you have the subscription.
Also, the RHEL subscription provides update, monitoring, and patch management features through the RHN website that are not available with CentOS.
CentOS strives for binary compatibility with RHEL, but this is not guaranteed -- there are and can be issues and bugs you will encounter.
A good number of third party software products are supported on RHEL but unsupported on CentOS.
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.
"They don't think it be like it is, but it do
-- Oscar Gamble
"Flyin' in just a sweet place,
Never been known to fail..."
CentOS 6 currently seriously lags in updates. I gave it a try, but then over a couple of weeks there wasn't a single new package available. Over the same time RHEL pushed out a dozen updates easy. It'd be pretty irresponsible to rely on CentOS, and anyone not understanding this is unfit for a CIO job. Two socket RHEL is a couple hundred bucks. It's money well spent. If you want to be cheap, you better compiled all RHEL released SRPMs as soon as they are available and kept your CentOS up to date that way.
A successful API design takes a mixture of software design and pedagogy.
Here's your loud answer. You can buy all the support for GNU/Linux you want same as any proprietary software. The actual designers and coders of OS/400 (now System i) and other proprietary OS don't support their work either, others in their company do.
By some chance do you write documents which are intended to pass for manuals, for electronic products sourced from China?
You've spoken your peace. Unless you know of a specific technical reason why using CentOS will not work, just do what you're told. It's your job to make sure the project succeeds.
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..."
That's why he's the CIO.
My personal experience is that Red Hat support doesn't buy one much except the warm feeling of having it. I've never known a corporation to go for CentOS on Production machines, but I've seen it all the time in Development environments.
As someone else suggested, you'd be wise not to try to be spending someone else's money. In your place, I'd make a case that outward facing system should have support, because we lose (whatever it is -- sometimes thousands of dollars a minute) when they're down, and under those circumstances, you don't want to be asking on Linux forums for a solution. Everything else, development, test, sandbox, can be CentOS if it's a comparable build to Prod.
But if he turns that down, well, he's the CIO. He gets paid to make those decisions, and to live or die by them.
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
Support isn't worth anything if it's a guy in his garage that supports 10 other people. What happens when two have an outage at the same time? But when you contract for a larger company (someone who makes the product) and they say "we can't help now" you will be held blameless. Most of business in the US is driven from ass-covering, not innovation.
Learn to love Alaska
Get it in writing that he doesn't want 3rd party support for the Operating System despite your insistance.
That way if something goes wrong, you have it in writing the CIO took a risk by cutting corners and he is responsible for a fix taking some time.
Make SELinux enforcing again!
Especially in terms of unpatched security vulnerabilities - to wit/e.g. (and, we'll compare them, "Apples-to-Apples", by the types of softwares involved for enterprise class development for business):
FIRST, OPERATING SYSTEMS:
Vulnerability Report: Microsoft Windows Server 2008: (10/30/2011)
http://secunia.com/advisories/product/18255/?task=advisories
Unpatched 3% (4 of 153 Secunia advisories)
vs. Linux's "latest/greatest" KERNEL ONLY (mind you, just a kernel - toss on the rest of what's in a full linux server distro? You'd have even MORE than this (which is 4x++ that of Windows Server ALONE)):
---
Vulnerability Report: Linux Kernel 2.6.x (10/30/2011)
http://secunia.com/advisories/product/2719/?task=advisories
Unpatched 6% (18 of 281 Secunia advisories)
Let me look at the links.
How many of the Linux kernel bugs were marked critical by Secunia (4 or 5 of 5)? Oh, none. How many of those 153 Windows bugs were critical? 60!!!!! They released a product with 60 critical bugs!!!!!
Wow. Thanks for the links. It makes it clear who has the more secure product.
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
CentOS doesn't cost RedHat anything other than the work they put into making it so that folks like CentOS can do their thing, which is minimal. What they get in return is that each year some of the folks who use the derivative distributions choose to level up to RHEL. It's like advertising - a numbers game. It's designed that way on purpose. I don't doubt RedHat would be tickled pink if the entire Fortune 1000 migrated to CentOS for everything they're not already paying RHEL for. So, carry on! Build up those line-of-business apps on CentOS, get good and committed. Sooner or later you'll buy some support for something and RedHat will get their money eventually.
Help stamp out iliturcy.
reads Slashdot. Wait until you go into work tomorrow and see if he brings up the conversation. Cheers.
Think the original poster has managed to stir up a religious debate.
The job is to manage/execute/spec the project.
Like it or not linux is an OS, its not going to earn your company money. Its support.
So put in in terms of money:
1. What are the switching costs and reduced:
a. what are the scripts you need to rewrite - in terms of man hours, anticipated outsourcing costs
b. What standard tools used in the organization will break, great if it is none but any experienced migrator will tell you otherwise
c. What is the cash saved in the life cycle of the project and what costs are saved in the extended life
d. What additional sales expected?
2. What is the value of your stream of updates( you have data, quantify it in terms of $$$)
a. In Engineering terms what is the cost of remedy and what is the cost of defect prevention (Past data where a patch is not present and how much activity the repair cost the organization, how much does it cost the organizaiton)
3. Disaster recovery
a. What happens if the OS becomes a blocker (e.g. some obscure library file provided by the latest RHEL on the dev pc and not on CentOS)
b. What happens if the applications behave differently(not likely but Ive seen it happen)
c. No offense, but what if you as key frontman(assuming here) are not able to solve a CentOS issue and you need help
d. You are proven right in the end you need a stream of updates, so how much will it cost to setup one
4. Suppliers
a. Do your organizations or partners have the capability and experience to implement rapid/ acceptable deployment for OS (provided you need multiple farms)
b. What will they charge and feed it back to 1
5. Customers
a. Do you marketing people go around promoting quality and talk about your RHEL, imagine the liability if it your customer faces an issue and get pissy
b. Will they accept CentOS, redhat has a lot of pull in the enterprise linux world. Like it or not, people will not like it when you switch away(like you!)
c. Will your customers choose another supplier if you switch, customers can be fickle, if they can switch on color of a GUI they can swith on an OS
6. HR needs (not really your call from the sound of your post , but still its in your domain and you are holding the bucket, so better to voice out)
a. Do your anticipated maintenance staff have the proper staff and certifcation needs(some organizations require a certain % of staff to be certified)
b. Do you need to hire more staff(project/contract/temps) to enable this project
This is a very short summary of what you can do(ill write more if you pay me =) ).All feeds back to 1. And ultimately its the CIO's call as some posters have made the point.
Ive seen organizations dragged down by such issues, where one engineering group goes off pushing their own distro and another group pushes their own. Lots of wasted resources and time. If your CIO makes the call, he makes the call. If you as SME know the difference, present in a way so that he can make the call. Supporting redhat will not help your organization or you. Put it in neutral terms and show what RH has to offer and if you got time pull in other companies. If he is open to CentOS why not suggest the full spectrum and let him make the decisions. pad it with costs from trade magazines(alright bad source but still better than nothing) , studies and most importantly your company's history. His call, his decision , his responsibility. In any case, if it hits the fan, you are covered and your organization has a plan from day 1. Good luck
If your CIO or CEO is one of the people that only hears the "free" part, there's nothing that will convince them to contribute to the community, whether through cash, donations, or sharing their own source code.
The torrent community calls them "leeches."
I do not fail; I succeed at finding out what does not work.
You won't, Your too ignorant to read even the most basic of agreements. You did manage to waste 1 minute of 300,000 peoples time on a Sunday afternoon.
"Computers are a lot like Air Conditioners" "They both work great until you start opening Windows"
The solution to the problem is simple: Use Debian instead. Debian doesn't come with support either, but unlike CentOS the package selection and average quality levels are sufficient for production systems.
By definition, Centos lags behind Red Hat on patches. They work very hard to make that window as small as they can, but sometimes it drags out longer than you'd like it to for a critical system. Some researchers will wait for Red Hat to release a patch before posting about a vulnerability. Not so many will wait for Centos. So the window where there's an announced flaw without a patch is, necessarily, larger with Centos than Red Hat.
.sig: file not found
Yes. That's actually a sortof dumb question. If Lockheed Martin subcontracts a part, it's ok if it comes from a known terrorist group because LM is bigger? Think about what you're saying. Yes, code repository auditing is important. Yes, QA is important. I don't care if your employer is bigger than RedHat, it doesn't matter a hill of beans.
With a very small group where everyone knows everyone else it would be difficult to infliltrate it and infect it with malware. There are not very many CentOS developers and packagers.
Sounds like you can't do your job without someone holding your hand. I've used CentOS, and the Internet works just fine for doing research into problems. I'd do as you're told and make sure you document any time spent researching problems. After all, he might decide that you're not capable of doing your job if you keep insisting on the paid support. I have yet to find an industry problem that can't be solved on your own.
"Please describe the scientific nature of the 'whammy'" - Agent Scully
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!
My post above was meant for you, not the Anonymous Coward.
Argh...
--- Grow a pair, liberals... stop letting the Republicans bully you!
If this situation came up 100 times with 100 different CIOs, I'd venture to say that 99 times the CIO would make you choose Red Hat. (Actually, they'd probably steer your toward Windows Server, but let's assume we're dealing with Linux-friendly CIOs here.)
Most CIOs won't let a big software project go through without paid support from all the software vendors in question. But your CIO is a smart man. I wouldn't say all software support contracts are worthless, but if you've got strong Linux knowledge in-house, CentOS is a perfectly acceptable alternative to Red Hat.
As the director of IS at my company (we don't have a CIO title, so my position is as close as it gets), I have spent years building up Linux gurus who know their way Red Hat- and Debian-based distros. I trust their knowledge, and their ability to research and solve problems on their own, to go with CentOS when a Red Hat-based distro is needed for a certain project.
Some projects we have done have absolutely required RHEL (to the point where they won't run on Red Hat-based distros, even Fedora), so we went with them because we had to. The only difference we found was that we couldn't get updates without our RHEL license keys. We were able to solve all problems with our own staff; we only contacted RHEL support when there were problems with the update servers.
Maybe you don't feel confident enough with your in-house knowledge. That's too bad. I'd spend money on training and developing gurus rather than forking over cash just to get updates. But mostly I say enjoy your situation here, as it is very unique. 99% of CIOs are going to force you to go down the paid route.
:q!
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.
You can say that about nearly any organisation on earth, but once again smaller groups without much to change are more likely to notice it than a large group.
Why don't you try a different argument that does not rely on the stupidity and inexperience of the reader? Why are you pushing such a line which I very much doubt you believe yourself? Is it some silly game to see if you can get a large number of replies about how silly your suggestion is?
Hey, if you consider clicking on [OK] every once in awhile to be a good way to make a living, so be it.
CentOS is completely frustrating for their inability to distribute current software. After years of compiling more and more of my own applications on CentOS 5.*, I finally got upgraded to CentOS 6.0. Already have to compile my own python and xfce. Something is wrong when the kernel revs more frequently than the applications. I belive RHEL has the same approach. What's the point in running an OS for outdated applications??
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?
When the economy is booming and money is flowing go RHEL.
When the economy looks like it is driving off a cliff pinch pennies.
Welcome to Econ 101.
google "32 trillion offshore needs IRS attention"
It is rare in large and medium-large companies to find any executive, or even high-level manager willing to say "I'm going to bet on my people's capabilities, rather than spend a lot of company money on the 'safe' (for my job) solution." Your CIO has the same two choices that countless IT managers, directors and CIOs are faced with: spend a significant amount of company money on an outside vendor, who can be blamed when all hell breaks loose, or rely on his or her team to do the job as well if not better and possibly take the flack when bad things happen. A nasty old phrase in IT was "nobody ever got fired for buying IBM." It worked until I knew the guy who did get fired for stubbornly going IBM when there were obvious better alternatives. Today, that "don't get fired" vendor is Microsoft. One day the axiom will fail them too.
Relying on internal staff requires a few things beyond thrift: keep your staff well trained, compensate them well enough that they don't quit too frequently, treat them well enough that their morale keeps them eager to do their jobs well, etc... All of those things benefit YOU. A thrifty-minded manager/director/executive who doesn't make sure to build good teams is a waiting scapegoat and will be out of your way soon enough.
In the bigger picture though, what trend do you want to see: safe-bet management that relies on treating internal staff in a mediocre fashion, massive outsourcing to "support companies" who can and will ship jobs out of your country, IT seen more and more as a cost center to minimize rather than the people who get vital company work done, and companies getting less and less effective with their IT solutions because every new project and every exploration of an idea requires going through the protocols and expense of consulting with another company? Why have highly-trained, highly-paid internal IT people while having pricey outside-vendor support subscriptions? The trend I've seen is reducing staff to an "account-manager" or two and getting rid of IT people by attrition if not outright layoffs.
Now, all that said, if your company is small, and the choice here is finding and hiring and relying upon one good support person (who might get hit by a bus or move across the country for love, etc...), or paying for a pool of proven support staff fully available on a defined protocol, well, you may have the better idea than your CIO. But the issues at hand are much greater than "CentOS is cheap" versus "RedHat is supported well," and worth discussing at those additional levels.
I always wondered what kind of support really is given? Mostly it really is just giving answers to question which are compiled into FAQs or Forums, so everything is already available..
Support isn't worth anything if it's a guy in his garage that supports 10 other people.
Er, what's your point? Buy your Linux support from a company that has the resources to do the job.
Hairy Feet's argument would be plausible except for the fact that Red Hat are spectacularly successful.
http://www.selftrade.co.uk/quote-red-hat-inc---RHT
Thier share price has increased about 1000% in the last 10 years and nearly 25% in the last year. That is similar to Apple, but without much advertising or notice from the media.
This year they are on course to have $1 billion in revenue, with $200 million profit. Doesn't everyone know that Linus Torvalds became a millionaire because he had shares in Red Hat?
Anthony Mouse (elsewhere in this topic) has described a scenario where Red Hat will be taking money to the bank because of recession. In fact they already are.
http://finance.yahoo.com/q?s=RHT
I would certainly recommend their support offerings as both best in class and exceptional value, but you don't need them in every situation.
It is also interesting to turn the question around. Do you think that Redhat would prefer you to use a different distribution?
centos is a clone of redhat getting all the work done by redhat for free. If you work in a for profit organization and will use the servers in production, i.e. making money, then it would be fair to pay redhat support if your company like so much redhat that they chose a clone of it. Otherwise, they could go for Ubuntu or other free Linux, and participate in debugging and developing it, that would be fair too. If your company is willing to save a few hundred dollars per year to get redhat's work for free, then you should question if you should stay. I mean I bet you do some kind of internal support on Linux machines for them, and they clearly don't value that much ...
Apple, HP and other large companies started out as a couple of guys providing hardware, service & support from their mom's garage.
I haven't been following the situation too closely for the past few months, but not long ago there was a lot of turmoil at the top of the CentOS project, and some people were starting to question its future viability. Have those issues all been resolved?
The CIO is not capable of doing his job if he doesn't understand that mitigation of risks involving purchases as well as projects in IT is his job. If he believes that assigning risks to the future is the best way to handle that job then he should be removed. There are many things that require additional support. The issue is not one of Red Hat vs CentOS (and CentOS does not have all the latest fixes as well as there being additional issues revolved around Red Hat's change in patch structure).
There are too many things critical to operation that cannot be contained without support. That support buys you bug fixes, as well as the ability to escalate towards people who do things like actually write the kernel or device drivers.
I thought this was profound. Every single aspect of our society is for-profit. In order to succeed in that, an operating system needs to generate money and re-invest it in development.
How many times have you used some FOSS product and inquired about a feature, only to hear that the programmers don't consider it important and aren't interested in it, even though there's 2,000 people in the support forum asking about it?
With Linux, we got a great operating system but also a community of freeloaders.There's a reason people buy windows and OS X, which is that because you pay money, you have an expectation that they'll eventually fix stuff and put in the features you need. It ain't perfect but it's the best we got.
He can try and support a OS with no professional support at 3 a.m.
"Our CIO is convinced that technical support for any product is worthless"
Has your CIO ever supported an application environment that included: Oracle RAC, DB2, Weblogic, OSB(aka ALSB), Websphere, Websphere Commerce, or heck a computer?
I would advise in creating a Risk Assessment (aka CYA Signoff) that outlines the risk HE is assuming by not purchasing support. Get his signoff on the Risk Assessment. You'll be surprised how quickly higher ups change their tune, when they realize their decisions are actually documented, and they can't just toss some lowly admin under the bus when it takes hours to recover from a production outage. When you do a Risk Assessment, schedule a meeting with the parties involved, DB Team, Networking, etc. If you can invite a Business side guy, even better.
I know it sucks! I like fast moving companies, that make solid decisions... but sometimes you have to play the game, to avoid catastrophe.
Normally, I would say this will help, in this case, whereas your CIO is against all support, it will only CYA when you have an outage during production hours, and the CIO tries to lay the blame on you.
I'm not familiar with your environment, so unless this project is a smallish LAMP wiki for internal use, I would be concerned.
Awesome!
Ask your CIO which response he'd rather have when requiring support. a: "Of course, lets open a ticket." b: "lol n00b RTFM." c: "Bug report? Fuck you. Fix it yourself and submit the patch."
Vintage computer games and RPG books available. Email me if you're interested.
In my last job I was a Linux/Unix Systems Administrator for a Fortune 100 logistics services company where we used RHEL and Solaris mostly. Our team had a large variety of preferences as far as our desktops and home server setups go. A lot of them favored Debian based distros, and we even had a diehard SuSe zealot (for both desktop and server), but one thing I can definitely say is not a one of us ever argued the value of Red Hat's Enterprise Support Services. With literally hundreds of thousands of dollars of business on the line every day, a near 100% up time was critical. We had some pretty talented SysAdmins, but there were several instances where RH support paid for itself many times over on each occasion. They continue to thrive even in this recession because of that rock solid support. I love the Open Source Community and love using totally free alternatives at home and even at work where I can. When it comes to mission critical IT infrastructure though, where every second of downtime counts, that level of support is a life line and in my humble opinion... priceless. That IS the reason for using Red Hat Enterprise Linux, and why years ago they split the distro branches like they did. If you don't need that level of support though, feel free to use whatever works best for you. It all boils down to what level of support do you need?
Try getting Emulex HBA drivers, Mellanox InfiniBand drivers, and many other "enterprise" hardware drivers, etc. to work with CentOS. The manufacturers won't support those using CentOS over RHEL (which they're made for usually with RH's cooperation). Oracle will also laugh at CentOS users. But then yes, there is support, and my experience with RHEL support engineers has been impeccable.
This is _the_ classic mistake by management: "Software is a one-time installation, not a process".
I'm betting that the same CIO also repeatedly does not budget enough money for maintenance and doesn't understand the concept (and consequences) of bit-rot.
http://www.youtube.com/watch?v=sTSA_sWGM44
-- Linux user #369862
Non-self-researched support isn't really an issue for me, as I typically am running FreeBSD or OpenBSD as network and website servers. Most BSD licenses are great for, well, not even having to worry about the license, really. They've both held up amazingly well and I haven't had any problems with the operating systems. Then again, FBSD is my desktop OS, so I am quite used to it. I note that our environments probably differ; the network I administrate, which has an OpenBSD network server and a FreeBSD website server, is a school. It's been painless and reliable. I also plan on changing my hosting server (I host a bunch of my client's sites) operating system from OpenBSD to FreeBSD sometime soon, as performance is a growing concern, as traffic grows for each client. Also, irc://irc.freenode.net/freebsd, irc://irc.freenode.net/openbsd, irc://irc.freenode.net/netbsd are all great support channels.
CentOS is fine if you just need an office file-server or print-server.
If you are running an e-commerce website, then you need to be PCI compliant and up-to-date with the latest security patches *QUICKLY*.
CentOS updates can be unpredictable as to when they will be released. Look at Wikipedia's "Delay" column for CentOS releases.
https://en.wikipedia.org/wiki/CentOS
Due to extremely slow 2011 updates and releases, I switched to an alternative OS out of fear a CentOS update might never arrive. It did release eventually.
Does your IT staff have the time and knowledge to create their own RPM files for updating CentOS, when the closed group of CentOS volunteers fail to deliver?
If not, I would suggest either pay for RHEL updates or use current free releases of Fedora, OpenSuse, Ubuntu LTS, or Debian instead.
Comment removed based on user account deletion
This is exactly what you're looking for!
IDC April 2011: "Understanding Linux Deployment Strategies: The Business Case for Standardizing on Red Hat Enterprise Linux"
It is at the link at the bottom of this Red Hat page:
"Research Highlights Significant TCO Value of Red Hat Enterprise Linux Subscriptions"
http://www.redhat.com/about/news/blog/Research-Highlights-Significant-TCO-Value-of-Red-Hat-Enterprise-Linux-Subscriptions
This is the Red Hat sponsored, IDC 2011 study of non-paid Linux v. Red Hat, including "mixed environments" of some Red Hat and non-paid Linux. To quote from the Executive Summary ...
"This IDC White Paper compares organizations using a commercial Linux subscription from Red Hat to support their Linux servers with organizations that are using a mixed environment of both commercially supported and nonpaid Linux distributions and organizations that are primarily using nonpaid Linux distributions aboard their servers."
Not only are the TCO results interesting, but the make-up of the companies as staffs. E.g., Average Experience:
- 5.3 years (Red Hat standard)
- 6.4 years (mixed)
- 10.1 years (primarily non-paid)
Basically 10.1 years is longer than Red Hat Enterprise Linux has been around (2002+, excluding RHL6.2EE, of course). So we're talking non-paid environments typically have 2x the experience than those with Red Hat as a standard. But what does that result in?
"Red Hat Enterprise Linux customers experience about one-fifth the amount of downtime as compared to organizations using primarily non-paid Linux distributions. With costs of downtime considered, Red Hat Enterprise Linux users spend less."
There you go! There's the value right there. As someone who is >>10 in corporate, Linux deployments, it might make sense to skip on support. But in reality, those who develop the software, those who can modify the software directly, are the ones that will keep you up'n running. Red Hat has proven this over and over, not only against unpaid options, but even other, paid vendors who don't have the sheer development in-house and know the software far better.
Support from enterprise-level hardware and software vendors. A lot of these vendors only certify that their product(s) work with RHEL (some vendors will only provide drivers in a RHEL-compatible RPM package). For those that need the support of these vendors but do not necessarily need the support from Red Hat, CentOS (which aims to be 100% binary compatible with RHEL), is a viable option. I'm all for supporting Red Hat with my wallet, but I'd much rather do it in the form of a donation if I don't really need their support.
It would be healthy to find more formats and models for open source project financing. Perhaps there would be more software and coding then. And more open souce forums. And more open source developer support. Google made a big contribution with summer of code, a new format. Kickstarter made another. I'm sure there must be many, many others which are not widely known.
I'm no alternative financing expert, bit thought of using complementary currencies, and transitioning closed-source to open-source upon reaching a sales target.
Build your own energy sources from scratch. http://otherpower.com/
So buy your Linux support from a company with tens of millions or more in revenue. My employer is one such place, we support major GNU/Linux distributions including Debian, Centos, Scientific Linux, Fedora, Ubuntu, Arch, SuSE, Mandriva and have clients in municipal government, manufacturing, healthcare, and insurance.
CentOS on all your test beds, RedHat in production. (Like the rest of the business world who has a flippin clue).
Support is only one reason to go RHEL over CentOS, and only a minor one IMO. Sometimes it makes sense to go CentOS, sometimes it makes sense to go RHEL, and sometimes it makes sense to run both. CentOS is really good and may be all that you need. I wouldn't hesitate to run it over RHEL in smaller shops.
So, here is why you would want to pay for RedHat instead of CentOS
- You really need the support. If you don't have deep linux knowledge, this might be for you. I have contacted Red Hat support about 5 or 6 times in the past 5 years. It was only really necessary once or twice and the other times were more like "I'm trying to get X to do Y. Am I wasting my time because it just doens't work that way?" kinds of questions.
- You need the big company on a sheet of paper. If you're running software like Oracle or Websphere and their support offerings are dependent on an "approved platform".
- Your customers. Are your customers and the customers you would like to have swayed by your infrastructure running on Red Hat? If they can turn around and bleed you, then do you want to be the one wholly responsible? CentOS has very little responsibility to you as a customer, however Red Hat does.
- Who do you trust? Last I knew, the CentOS project is actually really small. There are a few key players who hold the keys to the kingdom, and the project is dependent on them. If the CentOS project decided to turn around and evaporate tomorrow, or start throwing backdoors into everything, then they will lose credibility and respect from the community. Red Hat has $millions and future $billions on the line. Their continued success is more than just a personal matter to their CEO and board.
- ...which leads to, who is going to be around tomorrow. See above, CentOS isn't a huge team (which may have changed by now).
- Testing. Red Hat has the resources to test extensively. CentOS does not, but they also don't really need to test to the same extent since Red Hat has already done it.
- You own a lot of Red Hat stock. This mostly only applies if you're the CIO or a VP.
Your product requires or will benefit from an improvement in RHEL 6.1 or even better 6.2.
CentOS 6.1 isn't out yet and probably won't be out for quite a while.
Why not download and use Oracle Linux. Its enterprise Linux free to download and use. Subscribe for support if and when you need it - and its 24*7 / Global / Enterprise level - Even cheaper than Red Hat when it comes down to support cost.
I come to Slashdot only to read sigs. One you are reading is mine.
Stop complaining on Slashdot and get back to work!
If he/she does pay the bills, then let them take the responsibility for this decision. Simple. If you know Redhat, you already know CentOS so no big deal. Go with their choice and move on.
This sig can be distributed under the LGPL license
I used to work for a company that used official Redhat for the production end (web server, mail server, samba servers) and CentOS for for DNS servers, testing, network monitoring, etc.
It was a nice compromise. Support on the production side and only having to know one distribution on the other servers.
This reminds me of how MSDN works. You pay for production servers but can use the OS for testing/development/learning.
Competition Good, Monopoly Bad.
We use CentOS AND RHEL. On a few mission critical servers running non-FOSS apps certified to run on RHEL, we use RHEL. We want to know that in event of a major problem (especially if I was gone for some reason) we can call the app vendor or RH and be reasonably confident the problem will get fixed. We've never needed to do that, but over the past decade it has remained far cheaper to pay RH than run the same app on Windows servers. We aren't talking about talking about tens of thousands of dollars to be able to run RH and get updates. If you want the ability to call Red Hat for support on a case-by-case bases, you can get an annual RHEL license for as low as $349 (academic pricing is more like $60/yr!). $799/year gets a 1-hour response for critical issues. But it is up to your boss to decide what level of support, if any, he wants to go with. For many of our other servers we use CentOS. Some can be down with little affect on the organization. Others are just running basic LAMP and FOSS apps where certification isn't an option or isn't required for support. Frankly there is no benefit to us to use RHEL on these servers as we are able to fully support the OS and recover from even severe problems. If you don't have any need for Red Hat's services, software/hardware certifications, or anything else that adds value to RHEL, then by all means stick to CentOS. If you are worried RHEL (and therefore CentOS) will go away if you don't support RHEL, insist that your boss buy a contract (and don't complain when you are looking for your new job.) It is all insurance. As others have said, the real question is how much will downtime cost you? Will RHEL reduce the chance of downtime? Will it shorten the amount of time until recovery? Will it show enough "due diligence" to your boss's bosses to keep both of you employed after a disaster? If you are really worried, fire off a memo to your boss with your concerns and then accept whatever he decides. (But keep a copy as CYA for yourself in case you turn out to be correct.)
First: I agree with those who question your motivation to try convince your CIO to use RHEL instead of CentOS... Still I want to suggest using Scientific Linux instead of CentOS. Why? Because SL is also a "free RHEL" like CentOS but it's backed by major research institutes around the world. The majority of development is done at CERN by paid developers. But what's more: CentOS had serious issues with their project lead in the past... SL didn't have those issues... Also the people from SL seem to be significantly faster in following upstream (ie. releasing new versions) than CentOS
I know that Powershell is not terribly useful without even being a Windows admin.
Essentially what you've said is that the graphical IDE's are better -- something I've never bothered with in Windows or UNIX -- and that Windows is better with policies to manage itself -- which is far less necessary on UNIX to begin with as you simply can't muck with things that aren't yours.
recently spec'd out a large project for our company that included software from Red Hat
... IO 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 ..
This CIO is clear enough in his views. If he doesn't really need technical support for this installation which is part of a larger project, then just go with it.
OK
Most support, even enterprise support, really is crap. Red Hat support is (usually) far above the rest. When I worked for Red Hat, I regularly interfaced with support staff at partner companies, and they were usually a long way below anyone who was out of training. (Before anyone chimes in with their horror story, yes, some people manage to make it through training and bungle a lot of stuff before getting fired/reassigned; some tickets get triaged by a n00b who doesn't know what they're doing; and sometimes even the experts mess up. That's when you should be requesting escalation, no matter who you're talking to.)
That said, a lot of people don't need the kind of support that Red Hat provides. Red Hat's business model focuses far more on the large enterprise than SMBs. When SMBs use RHEL, it's often through a VAR who's also helping them with whatever they're deploying on RHEL. Red Hat gets a smaller cut, for less work. CentOS is just fine for many people, at least until they grow to the point where they need a support subscription with SLAs. Red Hat gets a ton of business from people who use CentOS until they grow enough to justify fixed-price subscriptions with SLAs. The sales team doesn't lose any sleep over it. Most people who choose CentOS over Red Hat are either completely rational in that they don't need that kind of service, or they customize too much of the distribution for Red Hat support to be economical, or they're just really cheap and would inundate support with trivial questions rather than shell out to send their admin to a (very good) training course.
If you think CentOS is better for you than RHEL, odds are you're right. You don't need to guilt trip yourself about being a freeloader. Report bugs, frequent mailing lists and chat rooms, and do whatever else helps the CentOS community, because it's ultimately good for Red Hat and the community at large. Red Hat is running a profitable business, and doesn't need charity.
There's no failure quite as dissatisfying as a complete and total solution to the wrong problem.
You're really bringing batch files into this? There's no comparison between batch and UNIX's who ecosystem (IPC, etc.).
There is flat out NO comparison between the level of stuff you can accomplish in Windows via the command line vs. UNIX, which leaves you to box clicking.
This was always a Windows vs. UNIX thread though. Saying that DOS sucks is simply redundant. Powershell is not good compared to UNIX, though I'll admit I could learn more to be able to better articulate why.
The think about UNIX also is that you have all of the little utilities for text manipulation, including generally having Perl available. Yes, you can install all of that shit on Windows, but... I dunno. Anyhow, I'll read up.
" The only thing it lacks is support, which the CIO doesn't want. Help?"
He does not want updates and bug fixes or does not want to pay for it?
A CIO that wants unsupported software is goofy and should not
have the title UNLESS he is in the business of supporting software
in contrast to developing and selling software.
Tell him that Gentoo is a much better choice. It gives him lots
more options.
I have noted that for some companies Redhat was a bit constrained
and pricey. If your CIO has five servers he can decide if he wants
one, two, three.... or five copies of RH should he feel that a price
of 1/5 or 2/5... or 5/5 is right.
Of interest in some lab and development environments
Centos is easier to work with.
Truth is stranger than fiction, but it is because Fiction is obliged to stick to possibilities; Truth isn't. Mark Twain.
Tell the CIO that if you use CentOS, you cannot be fully responsible for the security and eventual problems on the systems. Ask him to sign a piece of paper where he assumes responsibility in case support is needed. Tell him also that any major application (like Oracle) is not certified on CentOS. Again, ask him to assume responsibility for running applications on an OS that is not certified. Say that you'll be happy do it and let him collect the laurels _if all goes well_ but if not, you just can't be hold accountable because your professional opinion is that you need support.