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.
Cover your ass policy.
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.
If anyone knows....
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
If your CIO would rather pay you for support than contracting with Red Hat for it, you're getting that much more job security.
I work for a institution which uses Red Hat, and honestly we haven't gotten any support from them in the 18 months I've been here.
I'd much rather use a Debian based distribution (like Ubuntu), because upgrading is easier -- currently we're struggling to migrate from RH 5 to 6.
I also use centos, scientific linux and redhat, but prefer debian...
ftaurino
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
This is about ethics. Companies don't act ethically. It's that simple.
On the other hand chosing software without commercial support makes the IT people in the company less expendable. It's not ethical, but going with CentOS puts you in the position of power. Getting a raise will be easier....
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 ----
1/3 of them desktops, 2/3 of them render farm. We have no support of any kind.
The -only- way you'll persuade the business mindset is to write the business case as to why to use Redhat over CentOS. So, either go with the flow, or use your spare time to create the convincing argument f
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
The summary doesn't state why the person posing the question wants to pay for support. Do they not have the expertise? Is it a simple matter of wanting to support a Linux company? It sounds like the CIO is, reasonably, looking to get a good deal on their software purchase. If you can't give them a reason why Red Hat is the better option then I don't see what the problem is.
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.
Seriously if you think centos is anywhere near cutting edge.... oh dear.
- http://www.milkme.co.uk
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
Why you needed Redhat? Does any application requires, as a contractual clause, the use of a "enterprise" distribution as Redhat Enterprise or Suse Enterprise? IBM, Oracle and may other ISV vendors require this to have support for their product. This is the ONLY reason I see you would need a "enterprise distribution"... and, true to be told, even with your contract support, if you aren't a big customer (believe me I work for one of those two) is fairly remote the support you will get, and not much different than the support or information you could get from your google-fu skills. If you are worry about support, contact local linux enterprises and ask for a bid for support... with Linux, you will have troubles very early in the implementation, or relatively easily identifiable hardware issue (yesterday we had network, not today). If you get "random issues" that could be 2 things... software (specially if you are using java) tne 95% of the time, or faulty ram...
But for example, you have faulty ram, they you are in the need of better hardware, with hardware based memory error detection, and if you are worry about future issues because your skill level, Improve it, and make tons, and tons of backups...
Don't spend the enterprise money in software licences, better use it to get MORE and Better hardware....
Seriously if you think centos is anywhere near cutting edge.... oh dear.
I do believe that's the opposite of what he said. They're not committed to a release schedule, so they're far behind red hat, releasing whenever they feel it's ready.
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?
If CentOS does the job equally fine, why do you insist on paying for Red Hat? Don't you have people around who will make sure your project works? Do you really need others to do it for your company? (re: red hat support)
I suspect your CIO feels this way about paying for support because he/she is surrounded by highly skilled technical people. Most any problems are thereby expected to be solved in-house. Regardless, its something you probably can't influence one way or another, unless you're willing to commit to a Corporate Re-education Campaign. As with all things with management, YMMV.
Either you pay for it by having to keep technical staff on hand that are able to solve problems (e.g. read documentation) or you pay for it by buying a support contract. It's definitely cheaper to buy support contracts than to keep a few experts on hand. But then you also run into the gray areas when trying to gauge what's appropriate. In the case of Red Hat, the support isn't that great in my past experience. For example, if you have an issue that is kernel related, it will take a while to get you up and running again. In some cases you can end up with a reasonable workaround, but that's not a given. If asked, I would probably side with your CIO to opt out of paying for Red Hat support. The value in Red Hat support is the updates, but you get those for free with CentOS.
It is ironic that you tell him to use English, yet your grasp of the language seems much weaker then his.
When you cant win, ad hominem.
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.
CentOS cannot have that - as someone said, CentOS is 6.1 barely, RH is 6.2.
I do understand why you want to buy RedHat. It's the support, but it's also buying from the cow, since RH are one of the largest (if not the biggest) contributors to the Linux kernel + many other stuff. I think it's the fair place to put your money, but if your boss doesn't understand that, try to make him understand the dangers of being out there in the open without guarantees (things that RH offers). Like patching a vulnerability in a specified time limit. You know, the kind of stuff that will save you from leaking client data and other things similar. CentOS can never provide that, nor can they be made liable. Tell him that RH is his parachute if something goes awry - and he will not be held responsible if he made the right decisions.
For the guys that recommend Debian: while I admire the wonderful debian tools, that's about it. RH invested a lot in the core OS and I think that Debian also profits from the success of RedHat. While I do agree that Debian is great, I don't recommend it for enterprise.
That's why people buy Windows, btw. It's because they have the perfect parachute in the MS support.
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 work on an open source project which shall remain nameless. Myself and the other maintainer both work on Commercial projects that use said project and both of us have a similar philosophy when it comes to bug fixing. If it effects the people that are paying the bills fix it, if it doesn't review patches (when we get time) and accept them if they don't break our uses of it. When it comes to RH or CentOS your choice is to be the customer or to be the random dude with a bug report. If you have the technical expertise to fix bugs and possibly manage custom versions of software if upstream doesn't accept your changes go for the "free" version, otherwise you are better off paying someone to do that for you.
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.
Really.
Upgrades are worse than windows. Package manager is only recently catching up (but not yet met) where other distros have been for decades. C'mon, why RH OR CentOS (which suffers the same shortcomings as RH). I haven't used any other distro that recommends against an upgrade. Also, what is with needing a CD to upgrade even if you are willing to "risk an upgrade". RH does upgrades the worst of all distros, I think Debian does it best. just a simple command to upgrade a host to the next major version, and there are tons of Deb systems that have been through many version upgrades, and work perfectly (no "risk" here).
The only reason we have ever run a RH or CentOS box is when a commercial vendor requires use of this inferior distro.
RH also packages almost nothing. Had a box running one of those commercial apps, and RH (not centos), and it needed some sort of AV. RH didn't even package ClamAV! (not sure if this has changed with recent versions, but, again, c'mon!
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
Under the context you describe you can't justify Red Hat.
The CIO has determined that his strategy is to take on support risk in house. That may mean that he pays for experts he controls, it may mean he has an operational strategy that makes the impact of technical incidents related to the OS have less impact, or it may mean he ignores the risk because it isn't likely enough to occur or if it does occur isn't a big enough of an impact economically to justify the cost of vendor provided support.
The reason he has chosen this strategy is relatively unimportant (unless of course he has solicited your input on the strategy). Under his current strategy the decision to use CentOS even if you can afford RedHat or even to build your own OS is irrelevant. Take a requirements based approach, determine what your operational and non-functional requirements are, and implement his strategy to meet those requirements. When you're CIO you can change the strategy.
"Then"
"Flyin' in just a sweet place,
Never been known to fail..."
What if you've got to use RedHat with a closed source solution... and that solution is buggy an requires undocumented tweaks? Having Redhat support in the loop could help take care of that. Is the configuration your using even supported?
I think what you don't realize is that you have a very forward-thinking CIO who supports open source so much he's willing to hire staff to implement and support it. If you find a bug in centos, fix it on the job. Get paid for your time. Submit a patch to the community. There: you're a paid open source developer. Are you failing to see how awesome your boss is being?
"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....
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
We have faced a similar question and ultimately went with Red Hat for the IP Indemnification found in their "Open Source Assurance Program" -- the way I understand it, if someone decides to pull a SCO, Red Hat will go to bat for us.
http://www.redhat.com/rhel/details/assurance/
CentOS went three months without a single security update earlier this year, who in their right mind would touch it given that history?
It's fine for development systems that need to operate certified software. Only a clueless spreadsheet monkey would try to save a few bucks by deploying it on a production system that's accessible from the internet. Whoever posted this question should forget about arguing with his CIO, it's pretty useless. And he should get his parachute ready because if these systems get hacked that CIO is going to make sure the fan is pointing his this guy's direction when the shit hits it.
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.
What does Redhat support get you? In truth, it doesn't get you much at all. We pay for Redhat licenses, but we use Centos as well for dev & test environments. I don't really see what paying for Redhat gets us at all. It is a waste of money.
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.
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)
Yes. Funny way of putting it. And redundant. Obviously, if there are two people of whoms grasp is poor and person a is worse, then comes person be. They could just have used the word "than", which will compare the two grasps finely.
If you have multiple environments, use RHEL on Prod and Stage and CentOS on Dev and QA.
Generally the most important point/s have been made: official support from many third-party vendors, and timely support for updates (which CentOS will always lag behind). The RHN network (and Satellite) are also handy for keeping track of machines and (security) updates.
At the end of the day though, it's the CIO's job to manage risk, and if they're okay with it and start rolling things out I guess.
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,
That's why sensible people and organizations use OpenBSD. No patch would have ever been released, because the flaw would never have been introduced in the first place. This is due to OpenBSD being developed by some of the smartest and best developers around, due to them caring about quality and security, and due to them reviewing code changes properly.
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.]
As far as support goes, google is your friend.
Perhaps he's trying to save money on something he really doesn't care about?
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.
The network admin is more likely to be fired for not keeping CentOS update to date.
"You didn't patch our servers for 2 years??"
If downtime cost is non-zero and money is an issue, you can try Oracle Linux. It is free for download & use / deploy, includes optional support, and it is compatible with Red Hat Enterprise Linux and CentOS. A lot of people argue that Redhat develops RHEL, so they pay Redhat for support. However, that is not fair to the other contributors - the Linux kernel is developed by many others including IBM, Novell/SuSE, AMD, Intel, and yes, Oracle. Redhat packages a lot of code from many open source projects (I know that is a lot of work), but most of the code is not contributed by any single individual or company. For example, filesystems like Brtfs & OCFS are developed by Oracle, and performance fixes including OLTP, Infiniband, and SSD disk access, NUMA-optimizations, RDS, async I/O, OCFS, and networking are contributed by Oracle as well. And the Oracle "Unbreakable Enterprise Kernel" is developed by Oracle and licensed under GPLv2.
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.
Investing into the knowledge of your engineers above choosing for a vendor in order to look pretty and cover his ass at the next shareholder's meeting is an admirable thing to do, however it looks like the financial part seems to be the only motivator in choosing CentOS above Redhat. That might be even worse as the next decision in line might be to offshore the it department.
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.
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)
---
AND YES, there are 3 remotely vulnerable unpatched security problem outstanding in Linux there too, unpatched (despite all the "Open 'SORES' eyes" out there to fix it (yea, "right", not!))
* Additionally/again - so it "sinks in":
That's also more than the ENTIRE GAMUT of what MS gives folks to do business & build tools for it as well has & LAMP certainly cannot show less errors in unpatched security vulnerablities than 5 total from MS...
---
SECOND, DATABASE SYSTEMS:
Vulnerability Report: Microsoft SQL Server 2008: (10/30/2011)
http://secunia.com/advisories/product/21744/
Unpatched 0% (0 of 1 Secunia advisories)
vs.
Vulnerability Report: MySQL 5.x (10/30/2011):
http://secunia.com/advisories/product/8355/
Unpatched 4% (1 of 26 Secunia advisories)
---
THIRD, WEBSERVERS:
Vulnerability Report: Microsoft Internet Information Services (IIS) 7.x: (10/30/2011)
http://secunia.com/advisories/product/17543/
Unpatched 0% (0 of 6 Secunia advisories)
vs.
Vulnerability Report: Apache 2.2.x (10/30/2011):
http://secunia.com/advisories/product/9633/
Unpatched 8% (2 of 25 Secunia advisories)
---
FOURTH, DEVELOPMENT TOOLSETS:
Vulnerability Report: Microsoft Visual Studio 2010: (10/30/2011)
http://secunia.com/advisories/product/30853/?task=advisories
Unpatched 0% (0 of 2 Secunia advisories)
Vulnerability Report: Microsoft .NET Framework 4.x
(10/30/2011)
http://secunia.com/advisories/product/29592/
Unpatched 0% (0 of 8 Secunia advisories)
vs.
Vulnerability Report: PHP 5.3.x (10/30/2011):
http://secunia.com/advisories/product/27504/
Unpatched 8% (1 of 13 Secunia advisories)
---
* "Proofs in the pudding" & "argue with the numbers" + "read 'em & weep", penguins...
(Simply because I could put out nearly ALL of what MS gives folks for business & development here, and they're STILL be ZERO UNPATCHED security vulnerabilities in MOST the rest of, if not all of, their apps they put out (per my normal list I post here of that), & certainly less than the "Open SORES" world shows us, see above for a sampling)...
APK
P.S.=> Now, I predict I'll hear LOADS of unsubstantiated bullshit with no backing proofs to disprove the documented, concrete, & verifiable FACTS I posted above - why? It's typical "penguin/Pro-*NIX" fanatic behavior (along with adhomi
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.
Exposure to Risk due to patching delay of CentOS.
Ease of patching: CentOS doesn't (at least didn't' used to) have the ability to just apply security updates.
Safety net option w/ professional services (you don't have to use them, but it's there if you need it)
If you are familiar with quantitative risk management, putting a dollar estimate to these shouldn't be too hard.
Besides ... you're using Linux because it's a better, more stable OS (when wielded by an experienced person) ..... not b/c it's free ....... right?
This is basic mgt 101 ... risks have an associated cost.
Pretty quiet in here, no?
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.
Without wishing to FUD, there is less likelyhood that Red Hat wont be there tomorrow. Centos has already had a few concerning moments, founder disappearing, very late rhel updates. This is fine for lots of applications but for a mission critical you need guarantees they wont just stop one day for some reason.
But you need to weigh in this risk. if this app is worth 20million to you you'd be insane not to pay out a few thousand for rhel say.
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
It's linux man, grow some balls. We don't use linux because of support, we do it because we're bad asses.
.. morning when your CIO tells you he also reads /.
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
First things first, I appreciate CentOS for what it is and the advantages it brings to multitudes of people who wouldn't go another way.
I always end up prefering RHEL and Scientific Linux (a similar sibling) over CentOS for the fine reason that the latter claims but, does not provide 100% compatibility at the rpm deps level. I have seen such troubles in the past while trying to install postgresql rpms, I think from pgsqlrpms. What a time waster.
Generally speaking, RHN pays back its money very fast when you manage a network of multiple servers (gives automated overview/alarms for pending updates). You can initiate updates from the RHN web interface (if your clients are setup right) and works smooth, since many many years. No other company providing an OS has given ever such a decent service. Do you buy in that? http://en.wikipedia.org/wiki/Red_Hat_Network
Also, when a security issue pops up -eg kernel hole-, there is perfect accountability about who does what when and if you are decent enough in your configuration you'll never fall victim of the blame game. With CentOS, you can still whine that a bunch of volunteers were slower than a determined group of hackers.
btw.
If you have a funky issue against funky hardware against the Linux kernel, with RH you get a good chance to have some support for serious debugging rounds;
without it you will be left on your own devices. If you can write decent technical support requests, reasonable responses come back within the hour. I like this. Sometimes I just don't need to prove to myself I can a big manual and 100s of online FAQs. I just need the damned answer.
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!
i agree with you, CentOS, being a copy of Redhat, will not receive updates if CentOS doesn't. And supporting Redhat is a good thing in a case like this. But, you've made your case, and the boss is going the cheapskate route. There's just nothing more you can do about this. I figure, if you do find a support problem or bug, then try to solve the problem or come up with a patch... tout it on the appropriate forum or bug tracker. If you can't support Redhat financially, this at least supports them "in kind" by fixing some bug that otherwise they may have to spend time (time=money) fixing themselves.
The other side of the coin is that applications which are certified to run on RHEL systems will not be supported on CentOS. I'm willing to bet that a lot of the systems you run today have supported OS's, is CentOS on there ? It may or may not be. Either way, as others have said it's important to examine the uptime of a software solution as well as the downtime. Downtime is mighty costly.
As a maker of software running on RHEL systems, I've seen a couple cases where the software only works properly on RHEL systems and not CentOS. these cases are rare, but those clients that wish to run CentOS get to figure out by themselves why CentOS differs from RHEL releases.
Additionally don't forget the excellent Red Hat Network. The significant amount of time this tool saves you is worth the cost of subscription. Want to deploy a package to 100 hosts ? Click a few buttons and it'll deployed on the next check in. How easy is it to setup ? How about a simple: "rhn register". Hits the net and you're up. Want to see what the specs of a bunch of machines ? Select them from the RHN and pull out the stats.
The purchase of an OS has to do with :
1. workloads
2. support contracts of applications which run on the platform (this is really *serious* if you use any software which is written by a third party)
3. support contracts of the OS
4. support contracts of the employees managing those systems
5. ongoing maintenance costs
Think of this as Total Cost of Ownership, beyond what the Microsoft F.U.D. talks about. Assign numbers for these tasks and contracts on a recurring basis and see where things may be cheapest. Next, consider some of the intangibles :
1. How well trained are your staff on OS XYZ?
2. What is the cost of moving your software from one OS to the next ? ( How easy is this? )
3. What other things must you achieve in the near future and how will support of this change impact those deadlines ? (you might be able to take a guess and how much this would cost in terms of man-hours )
Good luck. Might want to have a serious sit-down if you're up to that level of things. Religious affinity to a product typically does not go over well in a business setting -- sell *WHY* Red Hat is a better product. Talk about the kernel commits that they make, talk about the support available at various levels of their organization from the kernel developers, driver writers as well as commitment to making the reams of documentation available that helps you do your job on a daily basis.
At the end of the day it's the CIO's choice, he has enough rope to hang himself with a poor decision. "Feed that rope out" and note your objections without getting emotional about it.
-Enjoy.
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.
Many times the commercial application or framework that runs on top of the servers require RedHat or some other commercial distro in order for them to support their software. There are many commercial software products that require the Operating System be on their list of "supportable" environments. I can't remember ever seeing CentOS on one of those, RedHat has been on every one.
If you only want to build one infrastructure for build, configuration management and repo then that one commercial application may dictate the rest of the Linux environment. If you don't have that application and don't expect to get one then I'd go with CentOS.
One ungodly, yet potential solution might be the Oracle Linux distribution. They're actually doing _some_ cool things technically with it. Like updating the kernel more than once every three years. Pay for the support you want. Of course you can build your world on Oracle and wait for their rules to change next week that invalidates all of your plans.
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".
Hello everyone,
I've been in the same place, replace CentOS w/ Oracle "Unbreakable" Linux and you have the same story. I've been using RH Linux since 1995 and, honestly, so far I was not disappointed. Not that I liked when they started to charge for the OS (read support) but, now it all makes sense. RH has to survive one way or another and, so far, from what I read and experienced, their support is decent (good but not great). By the same token, what CentOS and Oracle Linux take from RH is purely open source software (got it so far ?) BUT RH puts a lot of QA, effort and implicitly money into the RHEL and CentOS and Oracle are taking that too, for free. The difference is that CentOS has the decency to NOT RESELL what they have taken from RH but Oracle, in it's infinite greed, RESELLS what they've taken (read support) at a much lower price than RH, directly undermining RH. Well, it's a wild world out there, and the strongest will survive.
But let's look at some facts: RH is one of the top contributors to the open source community in multiple respects, the last time I researched their contribution was somewhere around 13 % while, get ready for this.... Oracle had a mere 2 %, not sure about CentOS though. So, what Oracle is doing is taking away customers from RH, diminishing RH's revenues (OK so far, business is business) .... but, less revenue for RH means less contribution to open source while Oracle's contributions don't increase. Hmmm, this looks like a lose, lose situation to me. Extrapolating, Oracle's strategy will work until RH will go under (worst case scenario, I bet IBM will jump to buy RH .... or Oracle will jump to buy RH); at that point what is Oracle going to take anymore ? What's going to happen w/ Oracle Linux ? Same logic applies for Cent OS too. I bet that M$ is laughing in their beards, waiting for their main competitor, not to destroy itself (really?) but to not be a competitor anymore ...
Enough with this stuff, my advice is to get RHEL, pay for support and indirectly encourage and support the open source community
Have fun !
When I started at my current job, CentOS was the Linux distro used on production systems. We decided that we were big enough and wanted to graduate to something with support, patches, hot fixes, etc. In other words, we had proven Linux was viable by testing with CentOS and now we wanted the "real" thing (not that CentOS is functionally any different). We wanted the comfort to be able to have someone we can call when we get stumped or too busy to dick around. So we got RHEL and all was happy, until Red Hat screwed up their licensing and quadrupled our annual cost. See, we use VMware. Red Hat USED to sell licenses that we compatible. Then someone at Red Hat got the bright idea to try to use price to drive VMware shops to convert to Red Hat's virtualization technology. So the special Red Hat VMware licenses vanished and were replaced with single server license OR special Red Hat virtualization licenses. Therefore our cost quadrupled overnight for RHEL. We complained to our vendor and then to Red Hat. Eventually, to prevent from not getting any money, Red Hat extended the special VMware license for us. Not anymore. So we seriously considered moving back to CentOS or SUSE. I have used SUSE at other jobs and think it is a very good distro. The cost for SUSE license would have brought us back to where we were. The transition was not something we wanted. So we talked to Red Hat again, and again they have changed their licensing. It is obscure and not advertised well, but they sell licensing based on physical sockets for any virtualization (which they don't specifically say). So we stay with Red Hat. Our cost has gone up a little, but we went with the "unlimited" per socket. Who knows how long this will last.
My story may not help. One thing we did toss around was how much we used the support, which was maybe once or twice per year. However, when factoring the security patches our management did not question the need. They only questioned to change in cost. My advice, if they can afford it then they should buy it. The reason is this, if you get hacked or if you have downtime or any problems then one of the first questions asked is "could this have been avoided". If the answer is "we didn't buy Red Hat support to save a few thousand dollars per year" but the incident cost millions, then the decision maker is getting fired. I once mentioned to my boss that backup tapes were expensive. His response was that the data for which those tapes protect is worth millions. If a company need to rely on a tape for it's well being then cheaping out is a very bad decision. The tapes could have been 10 times their cost, so long as they work then the cost is justified. If a company runs so lean that they cannot afford the things they need and must get substandard components then that is the sign of a failing company. My guess is that your CIO is not fiscally smart. Pose the question to the CFO (granted CFOs don't want to spend any money). Ask the CFO if he'd rather have a free, unsupported OS for his financial system or a paid, supported (24x7) OS. I have yet to see a money tight CFO not spend wildly on insuring their own systems be working 100%.
Cuz the oracle team wanted to give up easily and not deal with the 11.x to 12.x 64-bit issues.
I told them, no, I'm not going to maintain 2 distributions of Linux.
Maybe your CIO is selecting CentOS is so that your I.S. Department's funding makes sense when he takes the budget to the CEO/CFO. By saying "we need to pay for support", in some people's minds, the thought process goes: "If we're paying them to support our systems, what are you for?". I'm not saying that it's right being in a similar position, but that may be how he is justifying some of the cots of the department.
if he thinks redhat is support is for nothing he is cheap.
if he thinks there is no free alternative he is an idiot - look at debian.
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.
1st, an application of a program I call "ReVeRsE-PsyChoLoGy for trolls online" ->
"gaf a er'uoY" - by Anonymous Coward ANOTHER "ne'er-do-well" /. OFF-TOPIC TROLL on Sunday October 30, @07:37PM (#37889002)
"???"
Uhm... Could we get a translation of that off-topic "troll-speak/trolllanguage" of yours, please?
* And, you're an off-topic troll - no questions asked...SEE MY SUBJECT LINE ABOVE!
You prove me correct (see my quote below)!
Not only in regards to security vulnerabilities unpatched (where Linux's KERNEL ALONE has 4x++ more unpatched & 3 remotely vulnerable ones too, no less, the most dangerous type!), but?
Well, also in regards to the illogical off topic adhominem attacks I'd get because you're off/wrong & you know it, you cannot defend against facts I posted, & that's that!
(Yes: You again, 2x now, help prove ME right - that's one thing you penguins always end up doing, is making ME, look good & me? Heh, I love it, lol - why? Well, that's simply because it's just "too, Too, TOO EASY - just '2EZ'", lol, every time!):
P.S.=> Now, I predict I'll hear LOADS of unsubstantiated bullshit with no backing proofs to disprove the documented, concrete, & verifiable FACTS I posted above - why? It's typical "penguin/Pro-*NIX" fanatic behavior (along with adhominem attack based illogical off topic replies of course, or spelling/grammar-writing style critic b.s. too) by Anonymous Coward on Sunday October 30, @07:04PM (#37888756)
"Pats self on back", lol... & funny part is, that you made it so with this off topic illogical adhominem attack of yours in your reply I just replied to:
APK
P.S.=> Yes, it must have just have been another off-topic done nothing of significance with his life troll spewing his off-topic b.s. again & not contributing to the ongoing conversations. Oh well - No biggie!
("ReVeRsE-PsYcHoLoGy", for trolls - Courtesy of this code by "yours truly" in less than 1 second flat):
---
#TrollTalkComReversePsychologyKiller.py (Ver #2 by APK)
def reverse(s):
try:
trollstring = ""
for apksays in s:
trollstring = apksays + trollstring
except:
print("error/abend in reverse function")
return trollstring
s = ""
print reverse(s)
try:
s = "Insert whatever 'trollspeak/trolllanguage' gibberish occurs here..."
s = reverse(s)
print(s)
except Exception as e:
print(e)
---
... apk
Software updates from the dedicated commercial Red Hat Network servers rather than relying on the public mirror system (which is superb but for a corporate network RHN may be more reliable in times of crisis?). Frequent e-mail notifications of bugs and security holes. I guess this falls under the support category and the information is available elsewhere on the web if you know where to look, but it's handy having notifications which are specifically relevant to your registered systems come directly to your inbox in a timely manner. System management: Monitor your system update status from a central control panel on RHN.
How can you justify Centos with its lagging release schedule when Scientific Linux exists?
has the ability to debug and patch in all areas of the software like RH? Because a single incident of downtime can cost more that the support costs? Because the CIO will have to explain to the CEO why the system isn't working right? Because CentOS isn't tested and CM'ed at quite the same level as RHEL? Because this is a really big project and delay in getting a fix will delay development, cost developer costs in unproductive time? Or maybe none of those is true in your case... It all depends...
I made a living for about 36 years in OS support of customers so my bias is that I've seen it matter. I've also seen it cost a lot. But I never saw a CIO worry about how much support cost while his system was down. He or she just wanted the problem fixed right and his system humming again.
I would make sure I communicate my issues to the CIO and my manager. CYA....... Depending on your business you might make the case from a regulatory issue, Any governing bodies for your business that have best practices? What about legal obligations? Does your company have SLA with others? How will you meet those?
Depending on the business model, your servers functions and acceptable downtime no support may be acceptable. On the other hand lack of vendor based patches, amount of time the admins will have to search for bugs and issues and the classic "What would the CEO say if our business appears on the front page of the paper as being hacked" All because we didnt have the support and the advanced patches?
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
If you are paying or support for third party software, best check the vendor will support it on centos because many isv's do not. Like if you are running sap on centos, you are not in a supportable configuration and sap can ask you to reproduce the problem on RHEL.
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.
Some random ideas I was jotting down the other day when we were having the same argument:
Now that we are hitting bad economic times, I'm seeing several entities taking the risks of non-supported systems such as CentOS and Scientific Linux in place of RHEL. This got me thinking about the whole thing, and in my unimportant opinion I think they are going about support the wrong way.
I have never liked the RHEL licensing scheme, because it has always seemed to me to be no different from microsoft software licensing. You can call them whatever the hell you want(entitlements), but from the customers point of view it is nothing but overcomplicated software licensing that ends up being a pain in the ass for the admins to keep up with.
Git rid of software licensing and create an actual support model and offer incentives.
When I think of support I think of documentation, tech support, bug fixes and consulting. I do not think of a per OS/software suite licensing scheme. What I would like to see is some sort of general support model. With that model certain incentives can be put in place to create a better linux workforce and increase open source contributions.
1. Make the software free to download and use and focus on providing actual quality support.
Make the software free to download and get rid of the licensing model.
Benifits:
- Bring everyone back home to RHEL and away from CentOS, Scientific Linux... and so on. The reason most companies uses these is very simple. Cost. Why would I use CentOS if I could get the exact same upstream for free.
Create a general low level support offering that covers basic tech support and documentation(wiki) access. This should just large enough to contribute to Red Hat overhead for software errata and packaging, security certifications... and so on. (stress that this is what it will go towards as everyone understands)
Benifits:
- Same cost for everyone and the cost for basic overhead is spread out amount various support contracts. This should be small enough to make it inviting for small companies, but large enough to not hurt Red Hats ability to do what it does well.
In addition to the general support cost charge a monthly "admin" support cost. This seems more fair and makes more common sense then a software licensing support model. At the end of the day, its the admins that need the support.
Benifits:
- It just makes since and would keep the customer happy.
- Simplify the registration software. Throw all of the licensing BS from Satellite or Katello the programmers would have less to deal with.
Offer support add ons for specific software on a per-admin basis. This can include satellite, clustering, virtualization.. and so on with the ability to tie each support offering to specific admins.
Benifits:
- Companies can save money and buy support for the software that specific admin are responsible for.
- Red Hat can use these to provide money directly to the software projects being paid for via support.
Offer a support structure for consulting, architect work and redhat provided in-house installs/conf
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
BTW, it was discussed on the Oracle Linux forum that Oracle does support existing CentOS installations.
Dev machines CentOS.
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.
you stupid IT clown
It sounds like the CIO is wise. Do what he says.
my company started with centos 4 .. as we grew and need more support and did not want to expand our internal systems. we slowly made the switch to redhat now we only have 2 servers left with centos on them . and we literally just put plans in place to have them switched out by the end of the year. RedHat has been awesome and never once treated us a 'inferior' because we started with Centos. In fact is was just the opposite, they were like 'Oh good you are already using Centos' this will be so much easier.
as for the upper management... I agree with a lot of the above complaints. .. make sure it's documented in meeting minutes that you said you feel we should go with redhat.
but I also agree that it depends on your companies size, and more importantly the knowledge of your staff. We would not have been able to implement centos without the the staff we have. We already knew linux and wanted to get all our systems on the same platform. if you are coming from a completely windows it staff, it will be very difficult.
"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.
Redhat Licensing
Now that we are hitting bad economic times, I'm seeing several entities taking the risks of non-supported systems such as CentOS and Scientific Linux in place of RHEL. This got me thinking about the whole thing, and in my unimportant opinion I think they are going about support the wrong way.
I have never liked the RHEL licensing scheme, because it has always seemed to me to be no different from microsoft software licensing. You can call them whatever the hell you want(entitlements), but from the customers point of view it is nothing but overcomplicated software licensing that ends up being a pain in the ass for the admins to keep up with.
Git rid of software licensing and create an actual support model and offer incentives.
When I think of support I think of documentation, tech support, bug fixes and consulting. I do not think of a per OS/software suite licensing scheme. What I would like to see is some sort of general support model. With that model certain incentives can be put in place to create a better linux workforce and increase open source contributions.
1. Make the software free to download and use and focus on providing actual quality support.
Make the software free to download and get rid of the licensing model.
Benifits:
- Bring everyone back home to RHEL and away from CentOS, Scientific Linux... and so on. The reason most companies uses these is very simple. Cost. Why would I use CentOS if I could get the exact same upstream for free.
Create a general low level support offering that covers basic tech support and documentation(wiki) access. This should just large enough to contribute to Red Hat overhead for software errata and packaging, security certifications... and so on. (stress that this is what it will go towards as everyone understands)
Benifits:
- Same cost for everyone and the cost for basic overhead is spread out amount various support contracts. This should be small enough to make it inviting for small companies, but large enough to not hurt Red Hats ability to do what it does well.
In addition to the general support cost charge a monthly "admin" support cost. This seems more fair and makes more common sense then a software licensing support model. At the end of the day, its the admins that need the support.
Benifits:
- It just makes since and would keep the customer happy.
- Simplify the registration software. Throw all of the licensing BS from Satellite or Katello the programmers would have less to deal with.
Offer support add ons for specific software on a per-admin basis. This can include satellite, clustering, virtualization.. and so on with the ability to tie each support offering to specific admins.
Benifits:
- Companies can save money and buy support for the software that specific admin are responsible for.
- Red Hat can use these to provide money directly to the software projects being paid for via support.
Offer a support structure for consulting, architect work and redhat provided in-house installs/configurations. This is where Red Hat can beef up costs for large business and
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.
The answer to your CIO as to why you should use RHEL and NOT CentOS (speaking as a CentOS and Scientific Linux user) in the corporate environment is support, support, support. When the RH experts in the enterprise are on vacation, or away for whatever reason, and there is a problem, "who are you going to call"? Ghostbusters don't do Linux support... :-)
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.
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!
Really, unless you're emotionally invested in Red Hat, there's little justification to go with RHEL.
CentOS is free and offers no support, and Oracle Linux costs less than RHEL upfront and costs less on support (OUL licensing is slightly less per system as RHEL is per socket), so really, RH doesn't have the "if you want support" angle covered anymore, they're priced themselves out of that market segment, and frankly the only thing that keeps them afloat, with their ever-shrinking net revenue is the diehards who stick with it because of the emotional attachement to it being Red Hat.
It's not a question of how you can justify RHEL when CentOS exists, that's easy to do. It's how you justify RHEL in a world where both CentOS and OUL exist. There's just no good reason to go with RHEL anymore. Even the old argument of going with CentOS hurts Red Hat, and without Red Hat, there'd be no CentOS no longer applies. Oracle is fully capable of taking on the development of a second OS if it makes business sense to do so.
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
You don't know what the requirements are for the project for which the server is being built. Install CentOS, patch it up, then turn it over to the team that will be using it.
This kind of evangelism is the kind of crap that gives professional unix sysadmins a rep for being whiny linux basement nerds wearing a 10-year-old t-shirt with a penguin on it.
There's always a reason for whatever the decision is, and you are not always going to know, or be entitled to know what that reason is. I don't have to, nor do I have the time to, justify every decision I make to you personally. If you're going to be a problem tech, you're going to end up pulled off server admin and assigned to helpdesk.
If you've accurately presented the risks to running CentOS over RedHat, then your job is done. The CIO will be held responsible in the end. In the old days, system administrators (aka system programmers) knew C and fixed bugs themselves. They are part of the reason we have open source.
In the end, you have access to the source code. What are you worried about?
Only thing I've ever used Red Hat support services for were licensing issues. No lie.
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.
The best solution is to take all the above suggestions and neatly present them with assigned probability weight (%) (go through the industrial journals on CIO failings etc)., and send the copy to CIO via email with copy to others on the team. The tone should not be accusatory in nature, rather pose these as questions and asking the views of every one. Once this is documented, all future problems will fall at the lap of the CIO and if he refuses to change his mind, you need to find another job. Most CIO have insecurity and are not very bright, or rather have street smartness but lack creative and academic smartness. Thus placing all the facts on the email as a polite enquiry you safe guard your position. Never discuss any new ideas without an email (with a copy to your home computer) and higher ups always steal ideas from the best and use them as their own. Be careful.
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!
Red Hat and Centos suck donkey bollocks. I have to use both here at work because RH has "Enterprise support agreement". It's crap- the only times we have tried to get support out of them they have been slow and completely off track. Don't waste your money on RHN. You would be far, FAR better served using something with a decent package manager- which is the source of roughly 70% of the problems I have managing RH. Debian FTW.
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.
He is not responsible about RedHat being paid, he also does not have to adopt YOUR views about open source community. He thinks that RedHat is a rip-off (or so I gather between your lines) and in the end of the day, given his C*O title he probably reports to someone who usually cares most (if not only) about stockholder value and has every right to do so.
Besides, having no option to fall back to "sunken cost" -vendor support, you should get a warm fuzzy feeling of job security about the CentOS choice :)
Like the person who asks "how can I use NFS to serve web pages?", you're starting with the wrong question.
Before asking "How Can I Justify Using Red Hat When CentOS Exists?", first ask "should I use Red Hat rather than CentOS?"
It sounds quite likely that you shouldn't, and your boss is telling you so. Ask "might the boss be right?" before asking
"how do I change his mind?".
If you come up with a really solid answer as to IF Red Hat is better for your business, you'll know why and tell the CIO why.
You will have no need for a sales pitch generated by Slashdot users who don't know your business at all. After many years I''ve
just started to do this with politics - rather than asking how I can convince people of my point of view, I'm now starting to
consider whether perhaps they have a good point, whether my old point of view is necessarily best or not. It has been opening
my horizons and making things more interesting.
There is no point to *CentOS* with *Scientific Linux* in play. CentOS is buttt slow to release, has repeatedly left key security and feature updates dangling for up to six months behind their unpredictable "releases", is too busy infighting to put their work under source control or publish their build structures, and is losing both users and core developers (such as Dag Weiers) to Scientific Linux. There *is no CentOS 6.1 yet", and there is no published or expected release date. Let's face it, CentOS is coming apart for exactly the reasons their core team used to make fun of White Box linux for.
So the question as stated is, in fact, a stupid question. Now, if you want to compare Scientific Linux to RHEL, I've used all of them. If you need the upstream vendor to actually modify the packages for your needs, as I have when needing better virtualization support or new drivers for new hardware, or need patches to gcc and glibc to support new architectures, or needed Apache and OpenSSH updates backported to my production environment within 72 hours, then you need a commercial support license.
If your tech suport is in house and your staff is actually writing the patches and sending them to Red Hat, then maybe you can rely on your in house support. I've been in that position as well, and my salary has been justified supporting clusters on White Box, CentOS and Scientific Linux, and Red Hat's costs more than paid for for the kernel and core component support for production sites that would have taken me weeks to resolve the issues, if ever. And if you want to invest in *guiding* the next release, or package updates, to fill your company's needs, there's nothing like being a paying customer to get Red Hat to actually include something you want as a supported package, even if you don't have the staff or skills to get it into Fedora for possible inclusion.
Your company does $240K a day, and vice presidents? Plural? Sounds like too many chiefs in your company.
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?
A few years ago I was working on a real time system control system managing a reversable (tidal) lane in the middle of on of the busiest streets in my state capital. We were on RH enterprise ed, running a 2 node cluster that communicated via a shared SCSI array. Every now and then the cluster would go crazy with each ndoe "killing" the other over and over.
Long story short: we had an _enormous_ amount of help from RH, and a lot of days and nites with their engineers in our offices or production site. They went way above and beyond. In the end it turned out to be the nasty, dodgey rubbish Dell MB and let me tell you, Dell was the the other send of the support scale: Who us! Fuck off!
Did I tell you I hate Dell servers!
The question is: Why do you want to use RedHat in the first place ?
If you need the support AND this is a mission critical setup you need RedHat if not you can run on CantOS.
You can always upgade to RedHat later, it is not like moving from RedHat to Debian so it is quite easy.
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??
How can you justify using CentOS when Scientific Linux exists?
In years of using RedHat, we or our clients never called RedHat support, the clients call us, and at the end it is me who fix the thing. Even if called RedHat they wouldn't know how or application expects the system to be configured, so still needing someone from our company (me) + someone from RedHat.
For this reason, I always recommend Centos (with the donation thing, but they don't want to pay that either). Our systems are in a separate private city-level network, the weakest security problem is not our servers.
For similar reasons we are also dumping Oracle in favor of Postgre, which is much more easy to admin, and we compile it when we use it.
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.
Things like FIPS, if that matters.
http://www.redhat.com/solutions/government/certifications/egotist
Sounds that you want an other OS, maybe Windows.
Pay for it, even tho there is better alternatives.
Let someone else do the support for you, without understanding that the system will be down during the time they or you fix the problem.
Lose knowledge that lets you bring up the system yourself, in case support priorities down your system against others when the problem occur.
Good luck with your project.
Risk Mitigation
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..
We are a SAAS house running roughly 1000 Linux servers. We are SAAS, so I have software
developers and server administrators on my staff. Last year the person who maintains our
internal CentOS repository got transferred to another project and I no longer had a full time support
person on my staff.
So I ask Redhat a quote on repository servers and support in case we run into problems. We end
up getting a price of around $500 per server per year. That is half a million dollars per year for some
repository software and a support number. I had to stop the negotiations with Redhat explaining that
I don't see us getting a 90% permanent reduction on their pricing.
I ended up hiring a new person and now we are attempting to reach a situation where the underlying
flavor of Linux is irrelevant. I'm finding it easier to get people with Debian knowledge. For CentOS based
stuff Scientific Linux seems to be more up to date.
We've been in business 10 years and so far every problem we have encountered could be solved
with patching the kernel (two incidents, last one 5+ years ago) or by Googling (too numerous to count).
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.
My company has a simple rule : RHEL on anything facing the web, CentOS on anything internal
Especially where a zero-day exploit might impact us, we want the fix as fast as possible -- even if only a few hours.
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 ...
While I applaud your desire to support RedHat, I think it's misplaced. If you need RedHat's support then pay for it. If you don't, don't. This is the business proposition on which RedHat is based (and is doing quite nicely, thank-you).
On the other hand, supporting open-source and linux specifically, whether using CentOS or RedHat, by contributing to forums and irc, by reporting bugs and by publishing any trouble-shooting or specific set up (without giving away too much about your infrastructure :-) documents, etc you have is something that should be pushed and encouraged. In my experience these things are over looked and rarely get management buy in (more in the "meh" sense than the "don't publish our competition advantage" sense).
Given the fact you guys are running more than one Linux based system, your CIO must think very highly of you if he's willing to go with the system that offers no support. To be honest, we've been running Linux systems in our corporation for years, we've never once had to pay for support. Most problems we've been able to fix with 10 mins of research, and some hw/sw reconfiguring. I know for a fact that's saved our company thousands upon thousands of dollars. Just fyi, they're not simple LAMP systems either. We've got vmware esxi, nfs/drbd/snapshot storage/backup setup, centos asterisk servers, endian firewall, among others all setup and configured by internal IT. Given all of this takes a ton of research, but whatever you can learn yourself just makes you a better tech in the end
After the huge troubles of CentOS bringing out version 6 and other turbulence, I would completely forget about CentOS and go for Scientific Linux. Scientific Linux has proved to keep up much better with RHEL than CentOS in recent times.
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?
http://www.scientificlinux.org/
CentOS but with faster releases.
How are you going to feel when you've purchased support and they cannot help you... If you can get CentOS installed on a lab installation and up and working there are no gremlins that are going to eat you. I cannot tell you how many system admins try and play the "we have a ticket open with XYZ vendor" as a pass on something they should have been able to diagnose and fix. I think the CIO should speed the money to get a better in house resource to support linux installs who won't cry about not having support after all GOOGLE is an excellent free support resource if you know what your doing.
There are a lot of reasons why the CIO got his CIO position. Relationship to the CEO might be one of them. Technical background might be another. Yet a third reason might be that he understands how to make the CFO look good (i.e. saving a bundle on technical costs).
He knows that Linux-based solutions are a good bet when it comes to looking for stable platforms upon which to run software. He knows that the chances of something Bad happening (RAID configuration going awry, server being affected by mal-intent, hardware failure) are slim. But he also knows that, given the technical staff (i.e. YOU), even IF the system goes down, it can be handled by throwing late hours and overtime (i.e. YOUR time) at it.
"..than his"
You suck too.
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.
If you CIO does not see the value, then the only solution is to show him the value. Unfortunately, you cannot show him the value of kbase and such, if you can't access it. However, you can keep track of time spent on fixing problems and such, and how much time might have been saved with a subscription. If downtime does not cost your company a significant amount of money, and you already have a large technical staff that can afford to have there time pulled away from other work, then you probably do want to be using CentOS. However, for most companies even the reduce in risk by getting the security fixes on day 0 is a sufficient justification. Lets face it, chances are the subscription cost is probably negligible to the rest of the budget.
Just set out the facts in an email. Keep the email.
The CIO is I assume an executive. If so, his job is to balance risk and reward.
Just set out the risks and rewards in a professional and dispassionate way and let him make his choice.
Once he makes it you will have to live with it Im afraid.
If he's a good guy he'll do the right thing and if he's not then he'll probably attack you anyway so dont put a crosshair on your own ass.
Having said all that Ive worked a lot with CentOS in a production environment and its OK. Its not Debian right enough, but its OK.
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.
"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."
We hit a huge issue with device drivers for a particular vendor's RAID card. They insisted the problem was in the kernel, not their drivers. Having RedHat support meant that instead of us arguing with the vendor, RedHat engineers argued. The result was that we got a fix, plus we got back some of our hardware investment as credit because the vendor was so embarrassed.
If my CIO told me that technical support for a software product was worthless, my reply to him would be, "I quit."
As long as you've got someone in-house that knows a thing or two about Linux, you should be good-to-go.
He can try and support a OS with no professional support at 3 a.m.
Sounds like he's doing all the financials of his job "seat of the pants" rather than rigorously. Do a cash flow analysis of the support costs between Red Hat and ad hoc support using CentOS. Presumably the Net Present Value for RH is lower (thus the only correct financial decision). At least you can CYA with presenting such an analysis if you get overruled. I'd talk to Red Hat about this also: they probably have such an analysis already "in their pocket" as a white paper.
"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.
While CentOS is a great product, managing many servers (updates, patch management, etc..) can be a nightmare. RedHat's Satellite patch management makes the job much easier.
There is a "free" alternative to Satellite (Spacewalk) but you've got to balance the management/configuration of Spacewalk over the ease of management of Satellite.
This sounds remarkably intelligent for C-level management. You should have been the one that thought of it not him. STFU!
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.
1. If it really so large then you will have a new dedicated server with hardware support and redundant everything onsite right? If you are not willing to pay for that then you and your boss aren't serious about uptime and it's not that big of a project. CentOS will be fine.
2. Is this just a matter of installing some software/set up a database and you will have very few changes to it? Then maybe CentOS is fine. Depending on size of you software/server do you even need CentOS? A different distro might be a better solution. In fact if you need other applications Fedora will probably be a better fit. I know CentOS requires you to use other repositories to get things working a lot of times and packages are many times outdated. And no you don't need to keep upgrading to the latest version of Fedora every time it comes out.
3. Really if you are considering CentOS this software isn't really exposed to the outside world and doesn't matter if you are getting timely updates, see #2.
4. Why not just get the RedHat software, pay for support for 1 year so you can get your software up and running with that initial support, then drop it if you don't need it. See #3.
5. It really comes done to how often you are changing/updating your software/client software/hardware. If it's just every 5 years, well you probably don't need 24/7 support. In that case just hardware support is fine.
Personally I would opt for #4 to make sure the project is a success if it's a big project. If it's just a smaller server I would use Fedora. I've used it many times with no problems. Later on, a few years down the road when the project needs a big revamp/upgrade, get support again/upgrade so you make that a success as well.
We moved away from RedHat in favor of CentOS a few years ago, on price lines and RedHat's unwillingness to negotiate (and frankly unprofessional sales folk who blew off scheduled meetings), and an extremely irritating experience wherein their licensing team tried to hit us up for 1300 servers worth of licenses because we licensed ONE machine, simply so we could get per-incident support (which they do not sell).
I believe in supporting RedHat, as I know the contributions they have made and continue to make to the community and to many packages. RedHat Satellite was extremely useful. When working in the US public sector, RedHat has the added advantage of being an approved distro.
However - in the past few years, they've adopted detestable per-CPU and per-guest licensing requirements that remove much of the reason Linux is as popular as it is (free beer). This is simply ridiculous for large server installations - and then they have the balls to try and incrementally charge for HA and load-balancing, again, on a per-CPU basis.
Per their support - we are generally a very self-sufficient shop, but we did run into stuttering and intermittent performance problems that we needed some help isolating (hence purchasing premium support on one server). After a week of back-and-forth nonsense, I finally gave up when the Tier 2 support person asked me what I meant by "system time".
How come Linux 2.6's KERNEL ALONE has more unpatched security issues than Windows Server 2008 does & heck - MORE THAN NEARLY ALL OF WHAT MS GIVES FOLKS FOR BUSINESS & DEVELOPMENT TOO?
(Toss the rest of what goes into a FULL LINUX DISTRO in there, mind you, that # of unpatched security holes goes UP for Linux yet again too)
Now... &, as my other posts show as well?
Program-for-program/Apples-to-Apples types:
Database-wise, Webserver-wise, development tools-wise, & yes, OS-wise, the "Open Sores" camp has more unpatched security vulnerabilities than does Microsoft's toolsets for the same.
* All those years of hearing "Linux is more secure than Windows" & "down with MS" etc./et al around here? A truckload of bullshit is more like it... ANDROID especially proves that (& it is a Linux variant) even MORESO, because it's a Linux that's being widely used in the mobile world, & it's being SHREDDED ON THE SECURITY FRONT, massively!
(Security-by-Obscurity, due to being the least used OS out there almost, is what you had going for you all penguins... that's having ANDROID show that much, easily, alone!)
APK
P.S.=> Explain that please... lol, especially since all those "Open SORES eyes" are allegedly fixing bugs for that Open SORES stuff, how come it has more unpatched security vulnerabilities then, vs. MS' stuff?
... apk
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.
3/18 REMOTELY EXPLOITABLE too unpatched, why's that?
MS' Windows Server 2008 has 4, & the ones it has can be worked around largely via cutting off services you don't need, or other configurations in security tools.
APK
P.S.=> Lastly/By the by: We're counting UNPATCHED SECURITY ISSUES HERE, they're what matters, fool... not ones already patched & secured (of which Windows Server 2008 does have less, & LINUX has 4x++ as many, plus, 3 remotely exploitable ones (worst kind))...
... apk
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.
Instead of seeing them wait days (or weeks) for CentOS updates, why not advise them to get a $99 RHN Developer Subscription instead?
The full platform (Enterprise Linux) and middleware (JBoss) is included, Red Hat Customer Portal Access (e.g., Knowledgebase, etc...) and support for development purposes. It's what I use at home, and use when I'm on a customer site and they don't provide me with a RHN account (although I require them to if I'm going to be on-site more than a week). Red Hat has maintained a developer subscription for years, and converted RHL subscriptions to RHEL ones back in 2003 as well.
- https://www.redhat.com/apps/store/developers/
The great thing about having a RHN Developer subscription is that instead of just targeting and testing on CentOS, you can develop and test on RHEL, offering SLAs and support options yourself.
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/
I don't know about others, but my Software Engineering 101 taught me that 85% of costs are sustainment. That's not new releases, that's not new features, that's sustainment of the software, over its lifecycle.
Yes, Linux is free. But backports for ABI/API compatibility cost money. Red Hat has engineers and developers to sustain its platform (Enterprise Linux) solutions for their 10 year lifecycle (7 years without ELS). That costs money. That's what you're also paying for. That's what "EL rebuilds" like CentOS benefit from.
If you don't believe in it, then run another distro. Let them change things on you. Yes, it happens. Red Hat left the "Single Release" model after Red Hat Linux 6.2 Enterprise, as it doesn't serve the interest of home consumer desktops and enterprises well. The result was the Enterprise Linux (originally Advanced Server) line. Consumers want things to change and ABI/API-focused enterprises and ISVs do not.
That's what you're also paying for. And if no one funds it, it will go away. Red Hat's still the only, major Linux vendor to have a sustainment model that is profitable and self-perpetuating. And as an added bonus, the community gets free, leading-edge development on not just Fedora, but upstream, as the duality of doing trailing edge sustainment. The proof is in the sheer number of commits not just to the kernel and core libraries, but GNOME and other, clearly desktop-centric code.
Yes, those who care about trailing-edge, sustaining engineering pay for the leading-edge, consumer developments. It's quite a model, 180 degrees from traditional software development! Instead of paying for new releases and features, you "the new stuff for free," because others are playing for the sustainment of the "old stuff." Why not pay if you deploy the "old stuff" too and need that sustainment done?
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
It's a common misconception to say the a Red Hat subscription is just support. Red Hat is more than support. A Red Hat subscription includes several things that are valuable to an enterprise company, the most important of which is security. Just remember that Sony was running CentOS.:
- Application Certification
- Everyone can compile Apache and PHP, but if you are running any enterprise application, your vendor will require a certified OS to support you.
- Legal Indemnification
- This one is often overlooked. In our litigious society, people can get sued for having open source code that causes issues. RH indemnifies the client against that and will rewrite the code.
- Security Fixes in a TIMELY manner
- The fact is most people are not aware just how big of a lag CentOS has when it comes to updates. And it is not just security updates. Performance issues and the like also make a big difference. An unofficial audit of the CentOS 5.6 and RHEL 5.6 repos found the following:
- Average time to release a patch: 13 + days
- Longest time to release a patch: 100 + days
- Missing packages: 300 + plus while people wait for 5.7
The delta between dot releases is also massive. It averages more than a month.
If you are under PCI compliance, you just can not pass it with those kind of lags. PCI requires updates in one month. No auditor would be ably to pass you with a straight face.
But I compile my own software you say? Great and how often does that get updated? Even worse, I bet you are not compiling the libraries that those services are dependent on, like libtiff, libpng, libjpeg, etc, etc, etc. So guess what? You are still vulnerable.
And don't even get me started on CentOS Continous Release. They have no transparency of consistency here. They only seem to release patches for things that get news time.
This article, called CentOS 5.6 Finally Arrives, Is It Suitable for Business, says it all: http://www.linux-mag.com/id/8608/ From the article:
"Imagine your boss coming into the office and after reading about a major vulnerability in the Linux kernel that affects RHEL. Now, imagine explaining to your boss that even though Red Hat patched the vulnerability three weeks ago, you haven’t updated the company’s servers — and you don’t have any idea when you’ll be able to. When will the CentOS team release an update? No idea, and asking on the list just draws flames from the CentOS developers. Can we help? No, go away. Don’t like it, go elsewhere."
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.
And after 4 hours it is proven why this isn't the best place to get what you're looking for modded up. ;)
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.)
Vulnerability Report: Linux Kernel 2.6.x (10/31/2011)
http://secunia.com/advisories/product/2719/?task=advisories
Unpatched 6% (18 of 281 Secunia advisories)
---
AND YES, there are 3 remotely vulnerable unpatched security problem outstanding in Linux there too, unpatched (despite all the "Open 'SORES' eyes" out there to fix it (yea, "right", not!))
---
COMPARE & CONTRAST A COMPLETE OS DISTRO IN WINDOWS SERVER 2008 NOW:
---
Vulnerability Report: Microsoft Windows Server 2008: (10/31/2011)
http://secunia.com/advisories/product/18255/?task=advisories
Unpatched 3% (4 of 153 Secunia advisories)
* Nicest part here is, that the few unpatched vulns ALL have valid easy work arounds, or don't apply to workstations, or can be secured for (by turning off services you don't need, especially on desktops/workstations or by securing them down rights-wise)...
---
So, that "all said & aside"?
* Additionally/again - so it "sinks in":
That's also more than the ENTIRE GAMUT of what MS gives folks to do business & build tools for it as well has & Linux, @ ITS CURRENT LATEST CORE/KERNEL ALONE, has more unpatched security vulnerabilities than does nearly ALL OF WHAT MS GIVES FOLKS FOR BUSINESS & DEVELOPMENT... period (read 'em & weep above).
APK
P.S.=> So, doesn't your redhat example use the "latest/greatest" kernel too? YOU LOSE badly!
... apk
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
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
not so sure about you
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.
Unless I'm mistaken, I believe the OP elaborated on his motivations behind choosing Red Hat over CentOS.
If one shelves their technical cap for a moment, and dons their enterprise business cap instead, the following two validations for choosing Red Hat over CentOS become clear:
- ISVs and OEM hardware vendors certify their products to work with Red Hat. Not CentOS. Not Scientific Linux.
- Red Hat indemnifies your enterprise business against legal action (a la: SCO vs Linux) and will carry the costs of such future legal actions. CentOS does not. Scientific Linux does not.
If you do not perceive value in the support offerings from Red Hat, you can always opt for a self-support entitlement, which still entitles you to updates, vendor certification and indemnification but at a reduced annual cost.
On a personal note, I harbour no ill will toward CentOS/Scientific Linux distributions. They definitely have their roles to play, however pinning the infrastructure of your enterprise business on the tail of a community project, which lives or dies based on the whim of it's creators (http://linux.slashdot.org/story/09/07/30/130249/centos-project-administrator-goes-awol) would be ill advised.
"Ain't talkin' bout LINUX: Linux's rotten to the core" http://secunia.com/advisories/product/2719/?task=advisories
http://secunia.com/advisories/product/2719/?task=advisories
http://secunia.com/advisories/44754/
http://secunia.com/advisories/19402/
http://secunia.com/advisories/14295/
NOW, as to the one unpatched you note in Windows isn't a "Critical File", so disabling/unregistering any affected libs (colorui.dll) would stop it easily, especially for a server (& much of the time they run "headless" too, no need for gui, pure remote admin work).
APK
P.S.=> However, those 3 remotely exploitable unpatched security vulnerabilities in the Linux 2.6x current kernel don't look too good... can you produce an easy workaround for them, as I did for Windows, above? apk
See the VB example here to marshall namespace commands in powershell http://msdn.microsoft.com/en-us/library/microsoft.powershell.commands.filesystemcmdletproviderencoding.aspx
APK
P.S.=> Now "That's what I'm talking about" @ least, & what was said is correct on PowerShell being able to use VB like syntax... apk
Try it, you'll take that back. It's got a hell of a lot more power in its namespaces than legacy DOS batch commands do.
APK
P.S.=> You're correct on batchfiles though vs. *NIX shellscripting power, but that was never the comparison here... it was about powershell. Batch was just noted as another scripting tool in Windows (since DOS). Powershell more than makes up for that, bigtime... I put some examples in my other replies you can check out to verify what I am saying here in fact!
... apk
I can't wait until ALL sec. vulns are patched! That is, IF that EVER happens (lol).
See - around 2006, I figured long ago on a forums (techpowerup) that by 2012, they'd be patched finally (for Windows, not sure about *NIX variants).
Yes - I do think it can be done, eventually... optimist here is why. Nice part about computing is, MOST times, anything can be fixed (then again, the hacker-cracker explosion since 2004 is showing the reverse as well... I look @ it ALL as the road to progress/growing pains, is all!)
On DOS: Personally? Hey - I like it. For me it was my 1st programming of a sort on personal computers (did BASIC/COBOL before that albeit on timesharing terminals).
Anyhow/anyways - Batching got a LOT more powerful via %errorlevels%, & the FOR command imo as it matured... & it's surprising what CAN be done using them!
See - batches are a lot more powerful now than they were, in say, DOS 3.3 & below (that's certain). I know you're not "into it", but there's power in batchfiles too.
Still - PowerShell (native to Windows) is TONS more powerful, & just for the hell of it, take a peek here:
http://linux.slashdot.org/comments.pl?sid=2500906&cid=37909886
Once you go to the MS link that, you'll see how much more powerful (tons moreso) powershell is than DOS Batch - I'd wager it's stronger & more capable than std. *NIX shells are in their scripting (but, they work on diff. things many times too, so, it may not be an "always 'apples-to-apples' comparison either).
APK
P.S.=> As to learning more? Hey - we ALL can do that. I figure it's a wasted day if I don't learn at least 1 new thing (I usually do - forums are great in this regard, perhaps in all my time online since 1994 & before that in academia? This MAY be the best spot (/.) I've learned a heck of a LOT in... mainly due to debates like this one - yes, there IS a good side to "arguments" @ times, & that's one of them!)...
... apk
Linux fell FLAT ON ITS FACE 1st day on the job @ LSE:
http://linux.slashdot.org/story/11/02/19/0147232/London-Stock-Exchange-Price-Errors-Emerged-At-Linux-Launch
and was also serving up malware there too later:
http://slashdot.org/submission/1484548/London-Stock-Exchange-Web-Site-Serving-Malware
* You're going to have to do BETTER THAN THAT, to try to "get the best of me"... lol, U FAIL!
APK
P.S.=> Need I say more? I think not (lol, rather I KNOW not)... apk
Period -> http://linux.slashdot.org/story/11/02/19/0147232/London-Stock-Exchange-Price-Errors-Emerged-At-Linux-Launch
So you can try to put your "spinmaster b.s." onto it, but facts, are facts: Linux fell on its face right outta the gate!
* That's kind of funny actually, since you said it was bulletproof on uptime... well, apparently not, when 20 seconds into the job it blew up!
Want more "recent Linux successes" on the security front too? Ok:
3/4 of the of the CA's breached recently ran Linux, see here:
http://uptime.netcraft.com/up/graph?site=StartCom.com
http://uptime.netcraft.com/up/graph?site=GlobalSign.com
http://uptime.netcraft.com/up/graph?site=Comodo.com
Each was compromised, per this article's proof thereof -> http://itproafrica.com/technology/security/cas-hacked/
However, since you in the business of "ribbing on Windows", well, then it's my "civic duty" to show even MORE CURRENT INFORMATION about Linux being "so secure" (not) as you seem to insinuate:
---
KERNEL.ORG COMPROMISED:
http://linux.slashdot.org/story/11/08/31/2321232/Kernelorg-Compromised
---
Linux.com pwned in fresh round of cyber break-ins:
http://www.theregister.co.uk/2011/09/12/more_linux_sites_down/
---
Breaching Fort Apache.org - What went wrong?
http://www.theregister.co.uk/2009/09/03/apache_website_breach_postmortem/
---
Mysql.com Hacked, Made To Serve Malware:
http://it.slashdot.org/story/11/09/26/2218238/mysqlcom-hacked-made-to-serve-malware
---
* That's ALL pretty current information... very recent too - how much more abuse can you heap upon yourself, lol?
APK
P.S.=> You are embarassing yourself trying to "justify" Linux falling FLAT ON ITS FACE 20 seconds into the job @ the London Stock Exchange though...hilarious that!
... apk
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.
Any of those text utils in *NIX (which IS what Bell Labs initially designed UNIX for mind you: Text processing) is doable via Python, PowerShell, & other programming languages (like perl), easily enough for the most part (they've pretty much all got Regular Expressions built in, or have toolkit libs for them too) - there's even "ported" versions of *NIX commands for Win32 as well, if you really LIKE *NIX tools (lol, vi).
I just happen to "favor" PyThon (and JAVA) right now, because it is "write once/run anywhere" (or pretty much so) is all.
I also think You'd also be QUITE surprised @ what the FOR command & loops can do on text in DOS batch as well I think.
In any event - Whatever toolsets you use, if they can get the job done (& they're secure/no outstanding unpatched bugs), doesn't matter. It's about getting things done & done right.
APK
How many MORE breaches happened on Linux the past few months -> http://linux.slashdot.org/comments.pl?sid=2500906&cid=37914568 LOL, face it: LINUX FELL FLAT ON ITS FACE @ LSE 20 SECONDS INTO THE JOB!
Whereas Windows Server 2003 + SQLServer 2008 (not even the "latest/greatest" from MS mind you) have kept up & running 24x7 (the "fabled "5-9's" of reliability) in failover clusters for NASDAQ acting as the "trade data dissemination system", since 2005... that's coming up on a DECADE now of solid reliability!
* All you here around here is "how secure Linux is", & ANDROID (a Linux variant) does an even BETTER JOB of showing what a farce that line of b.s. is... lol! No wonder this site's losing readers... too many "FUD" spreaders from the losing team have been caught after years of lies, & with their pants down.
APK
P.S.=> Now, how many HUNDREDS of security bugs are popping up in ANDROID (a Linux variant)? LMAO... once Linux gets a wee bit of marketshare on any given platform? You see the results of the utter LIES being spread around /. (of "Linux = secure, Windows is not" etc./et al).
U FAIL, as usual! Why? You lack the intellect to "get the better of" myself is why... & this?? Ah, I just GOTTA SAY IT, as-per-my-usual vs. Penguins:
This was just "too, Too, TOO EASY - just '2EZ'"
... apk
And, as to screwups by Linux @ the London Stock Exchange (& other places)? Ok, again:
http://linux.slashdot.org/story/11/02/19/0147232/London-Stock-Exchange-Price-Errors-Emerged-At-Linux-Launch
Want more, very recently too? Ok:
3/4 of the of the CA's breached recently ran Linux, see here:
http://uptime.netcraft.com/up/graph?site=StartCom.com
http://uptime.netcraft.com/up/graph?site=GlobalSign.com
http://uptime.netcraft.com/up/graph?site=Comodo.com
Each was compromised, & each uses Linux, per this article's proof thereof -> http://itproafrica.com/technology/security/cas-hacked/
Some more? Ok:
---
KERNEL.ORG COMPROMISED:
http://linux.slashdot.org/story/11/08/31/2321232/Kernelorg-Compromised
---
Linux.com pwned in fresh round of cyber break-ins:
http://www.theregister.co.uk/2011/09/12/more_linux_sites_down/
---
Mysql.com Hacked, Made To Serve Malware:
http://it.slashdot.org/story/11/09/26/2218238/mysqlcom-hacked-made-to-serve-malware
---
* That's ALL pretty current information... very recent too - how much more abuse can you heap upon yourself, lol?
Linux has 3 remotely exploitable unpatched security vulnerabilities as well in its current mainstream kernel also:
http://secunia.com/advisories/44754/
http://secunia.com/advisories/19402/
http://secunia.com/advisories/14295/
(This is why readership on /. has declined, after years of "FUD" lies spread by Penguins of "Linux is secure" b.s. - people got sick of the bullshit, & took off... period!)
APK
P.S.=> You are embarassing yourself trying to "justify" Linux falling FLAT ON ITS FACE 20 seconds into the job @ the London Stock Exchange though...hilarious that!
Worse still, is what's in my subject-line, & you trying to say ANDROID doesn't use Linux @ the core/kernel level, lol... & its security being shown as lousy (yes, even @ the kernel level) isn't helping you, because there's 100's of such occurrences by now...
... apk
" 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.
Since no one has modded this up, I beg for someone to please get this TCO study to the original poster!
This is EXACTLY what he wanted! It was a TCO of unpaid Linux v. Red Hat.
Ok.. there's the whole big picture thing but you also need to look at what is best for your company..
Technically, CentOS is the same as RHEL but you get no support. From the companies viewpoint, you have to ask yourself the question.. Have I ever call Redhat support? or more importantly.. am I likely to call Redhat Support for an issue? If you are then you have a case for paying for RHEL. Linux tends to be very reliable (ie. compared to Windows) so it's much harder to justify support costs if you're not using the service.
The company I work for is government owned and we only buy supported products, whether it's the best thing to do or not. Is this a waste of money if we never need the support? I would say yes. Will this change my management's view on getting support for absolutely everything? No.
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.
KERNEL.ORG COMPROMISED:
http://linux.slashdot.org/story/11/08/31/2321232/Kernelorg-Compromised
---
Linux.com pwned in fresh round of cyber break-ins:
http://www.theregister.co.uk/2011/09/12/more_linux_sites_down/
---
Mysql.com Hacked, Made To Serve Malware:
http://it.slashdot.org/story/11/09/26/2218238/mysqlcom-hacked-made-to-serve-malware
---
Linux's showing in CA's breached recently too? Ok:
http://uptime.netcraft.com/up/graph?site=StartCom.com
http://uptime.netcraft.com/up/graph?site=GlobalSign.com
http://uptime.netcraft.com/up/graph?site=Comodo.com
http://uptime.netcraft.com/up/graph?site=DigiCert.com
Per these articles verifying that much (since they're shown to run Linux above):
http://itproafrica.com/technology/security/cas-hacked/
and
http://it.slashdot.org/story/11/10/28/1954201/four-cas-have-been-compromised-since-june
APK
P.S.=> Yup - All those YEARS to DECADES of "Linux 'FUD'" spread around here of "Linux = Secure, Windows != Secure" is turning up complete BULLSHIT, & ANDROID (A linux because it uses a Linux kernel) especially shows everyone what a crock of complete crap that campaign all was & that once Linux DID get a decent share of market on a platform, it's security 'swiss cheese', period...
Yea... 'security-by-obscurity', which is NOT REAL SECURITY, was what you were trading on to mislead others (to no avail, because your marketshare on the desktop shows your failure on that account also, even WHEN LINUX IS A FREEBIE, it can't win, due to inferior design in comparison to Windows in the eyes of others out there -> http://www.netmarketshare.com/operating-system-market-share.aspx?qprid=8&qpcustomd=0 )...
... apk