How Can I Justify Using Red Hat When CentOS Exists? 666
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?"
Support them from your own money (Score:4, Insightful)
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.
Re:Support them from your own money (Score:5, Insightful)
Re: (Score:3)
Why get it when CentOS fits the bill perfectly? Apart from the GP's rationale, it's also helping to build the profile and perception of CentOS if a major CIO advocates it. Congratulations are in order to the CentOS team for their great work, the fact it was even considered let alone requested is a testament to their excellence. Bravo.
Comment removed (Score:5, Insightful)
Re:Support them from your own money (Score:4, Informative)
Re: (Score:3, Insightful)
Re:Support them from your own money (Score:5, Insightful)
Re: (Score:3)
There's a big difference between price as determined by market dynamics and willingness to pay. Red Hat is doing work people are willing to pay for, but parasitic market dynamics create a condition where people don't have to. It's a parameter in the Red Hat business model whether enough people can tell the difference.
The same dynamic
Re: (Score:3)
Not only this, but the more effort Red Hat puts in to make their software better, the less support people need and so the less money they get (From people not buying their support).
This is wrong twice: First, lowering support costs lowers the operating costs of their support business. Then for cost conscious customers, they can pass part of that savings onto the customer to make it so that the value of the support services still exceed their price, while still making similar profits. And if they can price discriminate then for less price-sensitive customers it means the same revenues at a lower cost, so more profit.
Second, lowering support costs makes their platform more attractive to
Re:Support them from your own money (Score:4, Insightful)
Except that Red Hat does provide services people value, they're they top contributor [cnet.com] to the Linux kernel.
They're the leading contributor because the people paying for support need those features/bugfixes they are contributing.
Support contracts aren't just for helping clueless admins do their job because they're too lazy to Google.
Re: (Score:3)
Except that Red Hat does provide services people value, they're they top contributor [cnet.com] to the Linux kernel.
They're the leading contributor because the people paying for support need those features/bugfixes they are contributing.
Support contracts aren't just for helping clueless admins do their job because they're too lazy to Google.
Agreed, support contracts are also for small companies for whom a support contract is a lot cheaper than hiring a full-time highly skilled admin.
Re: (Score:3)
Pretty good points. From my personal experience, redhat's support is worthless. We had documented issues and the support people agreed that they see the problems, but keep asking me to test it. I told them flat out - you agree it's a problem, you are able to recreate the problem, then *YOU NEED TO TEST THE SOLUTION OUT BEFORE ASKING ME TO TRY IT, DAMNIT*
Somehow, they don't seem to understand that last part.
Re: (Score:3)
A good, free implementation gets people using a platform. Just like with SugarCRM. The clients with money (the people RH cares about) can then, and quite possibly will, end up using various RH products, support contracts and equipment that comes from suppliers with both.
I think they've had a good, long time to figure out how to best run their business... a
Re:Support them from your own money (Score:5, Insightful)
Re:Support them from your own money (Score:4, Informative)
Where I am working at the moment runs Centos on many of their servers. Why? Because they are a consultancy and many clients are using RedHat. Centos allows them to develop against it with relatively high confidence it will work the same on RedHat (as well as you could expect developing against RedHat on a development network and then shipping a product to be deployed in a different environment at least). I don't see the client base changing to Centos for deployment - they need / want the support blanket.
Re:Support them from your own money (Score:4, Insightful)
"Hey, if we strip all the copyrighted stuff out we can just take what we want and not have to pay RH shit! We'll save a bundle!"
Well, and the "no so nice" part is?
Red Hat decided on their own way to do business. Such a way included not developing an OS from start but instead using an OS with a license that allowed them to package it and throw a brand, a marketing campaign and a support business but it has a cost Red Hat was willing to accept: that others could do the same.
The end result is that Red Hat pushes money at it because it works for them, CentOS rebrands the software because it works for them, and I as a user have a choice that fits me. The day each respective choice works for the given agent no more is the day they'll change boats to look for greener coasts.
But that's the basis of free market, now, isn't it?
you didn't think that through at all (Score:3)
Re: (Score:3)
Shaft? No, wait. That's wrong. The right answer was Sun. The community totally shit on them in return.
Re: (Score:3)
It's not my responsibility as a customer to compensate for a supplier's bad business model. But having said that, Red Hat is far from hurting with their "bad" business decisions. A quick google shows me that last year their revenue grew about 15% and topped $1 billion. http://www.newsobserver.com/2011/03/24/1076990/software-company-says-revenue.html [newsobserver.com] They make a lot of money from support, but they also make a lot of money from contract work.
If their support is not worth the money, then it deserves to die
Re: (Score:3)
Its the same reason I doubt you'll be seeing any companies opening their hardware anytime soon, as AMD bent over backward, even hiring coders to help the FOSS driver guys and opened their specs as wide as they could, and what did they get? every forum filled with guys saying "Herp derp, buy Nvidia"
With regard to GPUs, I currently have a (aged) Nvidia GPU but my next GPU will be the top end Intel Ivy Bridge. I'll be going Intel because I want a newer and faster CPU, the Ivy Bridge GPU will be fast enough for me, and most of all because the open source Sandy Bridge and Ivy Bridge support from Intel is strong now and improving. Intel seem like they'll hit the ground running for Linux support when Ivy Bridge is released. I want strong, out-of-the-box, open source GPU drivers for Linux and that's what Int
Re: (Score:3)
Re:Support them from your own money (Score:4, Informative)
Red Hat's share price is at a 5 year high, and I believe their revenues are at an all-time high. If they are being crushed, it is in some wierdly subtle way that shows up on the balance sheet as strong revenue and profitability.
HOW CAN YOUR CIO JUSTIFY KEEPING HIS JOB (Score:3)
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!
Re:Support them from your own money (Score:5, Informative)
There are two reasons why I am speccing RedHat over CentOS, and neither have to do with support:
1: Application support for production systems. Yes, it shouldn't make a difference, but if I call in for support on an application that specifies the list of supported operating systems, and its not RedHat, there is a good chance I'll get laughed off the phone with "sorry, no app support until you have a supported OS".
2: FIPS, Common Criteria, and other certifications. These can mean the difference between "due diligence" in IT versus bad faith when it comes to an audit. Yes, this is pure legal eagle stuff, just like the requirement that the 64 CPU POWER7 box in the rack has to run McAfee, but it means the difference between passing an audit, or perhaps getting a contract terminated.
This doesn't mean CentOS is bad. It just means that having the certificates that come with the commercial version of RedHat may mean success or failure when the CPAs and the JDs are done extracting their pounds of flesh.
Re: (Score:3)
If those are important to you, spec Oracle Linux instead. It's like CentOS, in that it derives from RHEL, but you can get the Internet only support contract for the server OS at 1/10th the price of RHEL's annual charge.
Re:Support them from your own money (Score:4, Informative)
Re: (Score:3)
CentOS has really fallen behind the mark. It took them forever to get. out the door and by then rhel had already made a new release. The servers I put rhel on get base updates much sooner than the centos boxes and with epel and rpm fusion, im not for want of anything on those boxes. Then again I have an ungodly number of rhel licenses available and my company partners with red hat. I used to like CentOS but for a while it was looking like I would see mass deployment of IPv6 sooner than CenOS 6.
Support does
Re:Support them from your own money (Score:5, Insightful)
Im pretty sure if the need arose, there are scores of companies that would love to take your money in return for supporting CentOS, either on an ongoing or onetime basis. A good starting google search might be "CentOS Consultant" or "CentOS support", both of which return promising results.
To OP:
An ongoing contract is not always necessary; sometimes it makes more sense to do one-time issues. The CIO's job (and higher executives) is to make decisions like these based on their own experience and based on the recommendations they get from others. You have given your input, and he is deciding that, however good your advice it is, he is willing to take the risk for what he thinks is a better value. I would just accept that.
As a consultant, I have met smaller clients who, for example, insist on using Norton "business" products. I give my opinion on them, tell them I think it is a bad solution, and if they say "thanks, but we want to use norton", I have done my job, and they are doing theirs. Noone wants an engineer who thinks it is his job to make executive decisions, because it is not.
No one-time issue (Score:3)
Re: (Score:3)
I'm a Linux support guy. I consider myself good at my job, and many bosses have agreed. That said, I'm one guy. Red Hat has dozens, maybe hundreds of engineers with in depth specialty knowledge of all levels of their OS. Need help with tuning kernel parameters or drivers to improve performance on a particular revision of some obscure SATA chipset? There's a good chance that the guy who wrote that module works for Red Hat. Having trouble tweaking your Apache config for some specialty web server? They
Re:Support them from your own money (Score:5, Insightful)
The question is not how much support costs. The question is how much is DOWNTIME going to cost the company?
When you hit a problem your team can't solve what dollar value is that? Granted, for anything using a LAMP stack it is probably just as efficient to spin up a new server and start over versus a lot of money for support that isn't going to figure out all your custom stuff anyway.
I swear by IBM System i with IBM support. It's outrageously expensive, but they will call support engineers after hours when you have a problem level 2 can't handle. Microsoft's comparible offerings require a thousand seats.. IBM will sell you support for just one server.
In my case we have three steel mills worth $10k+ per hour of downtime... Even more if downtime causes rework. If we have more than an hour down I have vice presidents in my bosses office!
I suppose it's up to poster's boss, those C.I.O. Letters make it his decision... and his ass will be on the line when you have to explain why he didn't line up something to cover for things the minions can't handle.
Re:Support them from your own money (Score:5, Interesting)
I used to run an AS/400 system. And you're right. IBM's support rocks. One time the keylock was broken on the unit, and we needed it working. My support guy came out, verified the situation, then told me the bad news - "The nearest part we have in stock is in New York." (I was in California.) Then my support guy smiled and said, "The good news is that I've gotten ahold of of one that's on an airplane right now, headed this way. It will be here in 45 minutes."
Now THAT is support. :-)
Re:Support them from your own money (Score:4, Insightful)
The question is not how much support costs. The question is how much is DOWNTIME going to cost the company?
No, the question is what is OP's job description. Arguing endlessly with his superiors about their executive decisions is not going to change their minds or endear OP to them. Sometimes being an adult and a professional means accepting that your superiors will make decisions that you disagree with, and learning to accept that.
Re:Support them from your own money (Score:5, Insightful)
My philosophy is that I'm not paid what still seems like a somewhat shocking amount of money to just do what I'm told. You can get some kid to do that.
I'm paid to do my best to understand all the issues, make a clear recommendation, and to make sure that the boss clearly understands my recommendation. If the boss disagrees with my recommendation, it's my job to make sure they understand why I think what I think.
At that point it's on them if they want to decide against my recommendation. Sometimes it works out, sometimes it doesn't. And it becomes my job to do what they decided should be done, and to do my best to make it work, even if I think it's stupid.
It seems to me that the OP is still in the "make sure they understand" phase.
Re: (Score:3)
The boss is always right, because he pays you. That means you get to do whatever dumb thing he wants you to do, because it's his ass on the line.
It's your ass too, in many cases. That's why you make sure that his decision is properly documented as not being yours.
You're wrong. (Score:2)
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 [fedoraproject.org].
Re: (Score:3)
I agree with parent here. There are good reasons when to use Redhat and other good reasons to use CentOS. I think you do a major mistake if the reason you want to choose Redhat in a job is in order to support Open Source. You must make a real business case to justify investing in Redhat here - to support Open Source is not a business decision!
You must for example focus on the potential cost of downtime from one solution over the other. Maybe the solution you build have critical components to the company, wh
Update & security responsiveness (Score:5, Insightful)
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.
Public or internal systems? (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2, Informative)
The only updates Red Hat is ever prompt with are security updates. Until recently, I was forced to use RHEL for a number of servers (yes, it could have been much worse, Windows, etc.) but I spent a good deal of time rebuilding RPMs from Fedora just to get current libraries. And I'm not talking weird drivers for esoteric hardware, I'm referring to core language support for Perl, Ruby, Python, etc.
One option you could look at is using Ubuntu. The product is free but Canonical offers paid support for the LTS r
Re:Update & security responsiveness (Score:5, Insightful)
Re: (Score:3)
I'm not sure, but I think I read somewhere RedHat will even support a CentOS install if you ask them to.
Re:Update & security responsiveness (Score:4, Insightful)
I seem to recall something about that also.
I worked for a place, that was sworn to use RedHat.. Well, RedHat 6.0 through 6.2. The logic was "Our application worked on it then, we'll keep using it forever". Damned the remote exploits. Damned patching it, ever. We'll use it the way it came off the disk.
{sigh}
I showed them that their application ran fine on the current Slackware, and even Slackware64. They had 64 bit servers, but refused to consider using a 64 bit operating system. Again, "it's the way we've always done it."
A few remote exploits later, and new hardware that simply wasn't recognized (damned if they'll let me build a kernel). I had to sneak a few newer kernels on, to support hardware that they wanted. (shh, that's still a secret).
They did decide to start using newer hardware, with a modern operating system. They wanted RedHat, they wanted support, but didn't want to pay for RHEL. I asked them "how many times have you asked for support in the last few years?" The answer was, "zero". Actually, they did ask for support. The folks over at RedHat laughed at them. Well, very politely. It was something like "You're using an ancient unpatched patform. Go download something resembling modern, and we'll help you."
There was a running theme there too. They used the version of Postgresql that came on the CD. They used the version of Apache that came on the CD. Regardless of what improvements or security fixes showed up in future versions, they didn't come on the original CD, so they weren't trustworthy. I was really surprised that we didn't have a higher suicide rate. I found that talking to a brick wall while on long smoke breaks was far more rational than trying to argue with them.
The ended up going with CentOS, because it was modern, it did have pay support available, and they could get the OS for free.
I have a serious problem with RedHat and all derivatives. They patch known stable code to make it theirs. On so many developer sites, I've seen statements saying that they can't support known bugs in the RedHat tainted versions, because the changes destabilized it. Basically, if you want help from the author, go get a fresh copy, compile it, and install it. If you're allergic to compiling (sadly, so many people are), most authors have a RPM version available.
It's not just a few authors who complain. It's not just some edge cases that become troublesome. I ran into them all the damned time. In quite a few cases, I had to go compile static binaries from original author sources, on my Slackware machine, and copy them over, so basic things would "just work". They refused to accept that anything with "Slack" in the name could possibly work, regardless of the fact that I ran an enterprise network for years, fully automated, without any problems.
The fully automated part was the reason I wasn't there any more. My babies (the servers) were self sufficient. I was just a babysitter, in case something went wrong. Failed hard drive, CPU fan failure, the occasional bad network cable. You get the idea. I didn't spend every day logging into well over 100 servers, fixing things. And we were always patched up to current. If Slack didn't have a package, or if we wanted something different, we managed that ourselves. As I recall, that list was 3 things. Apache, Sendmail, and OpenSSH. Those three were customized for our purposes.
Re: (Score:3)
I worked for a place, that was sworn to use RedHat.. Well, RedHat 6.0 through 6.2. The logic was "Our application worked on it then, we'll keep using it forever". Damned the remote exploits. Damned patching it, ever.
[...]
If I'm compiling for system-wide use, I remove any distribution installed packages first. For example, Sendmail.
You ridicule people for using obsolete code that's full of security holes just because it's what they know... and you still use sendmail? Do you not see the irony there?
Re:Update & security responsiveness (Score:5, Informative)
Before I came to Red Hat I had a similar opinion. When I worked in Silicon Valley I thought "Why would anyone want to pay for Red Hat, I can't afford it so that means it's expensive." However after being at Red Hat for over a year my opinion has changed, and that has been because of some things I have witnessed.
Support is one of the first things people think about, however there is a little more than meets the eye here. Let's start with the packages. Let's say there's a major exploit in SSHd, you will likely see a fix from Red Hat within a few days, which will then be available via RHN. The source to the rpm will also be available at ftp.redhat.com due to the GPL obligations. (More on the GPL and RH later.) At this point in time RH customers have the patch available, in this fictitious scenario let's say it took RH 3 days to release the patch from time of exploit publication. CentOS users still don't have the fix, plus CentOS operates somewhat as a "Black Box." You will get the fix when they get around to it, let's say that takes two weeks before it's released (Could be more could be less). That means your systems are vulnerable for about two weeks, in some shops that's an acceptable risk, in other places it's not.
* Support from people is the other thing that people think about. Have you ever had to call RH support? If yes have you ever talked with an idiot? In the many times I have called RH support I have not dealt with anyone who I felt was sub-standard. Most often the problem I have seen is when the clients I'm working with do not present RH support with the information required in a timely manner. When the answers come back they often link to other knowledge base articles and have clear steps to either solve the problem or to better understand some of the complexities. When a solution is found and there is not a KBase article I understand (I may have heard wrong here) that there is an obligation to write a KBase article. I know that tickets are reviewed after they are closed. One ticket I opened regarding Satellite for a customer is getting discussion amongst the Satellite developers about how to best handle the same scenario in the future.
* Support from Articles, this I feel is a real hidden Gem of RH. Nobody knows about it until you have a subscription, and then everyone is so used to using Google for their answers they forget to start here first. The KBase articles from RH are phenomenal! I had a customer ask me how to rebuild the RH ISO image to include their own KS script. I could Google and find 10 articles talking about much of what I'm looking for or search the KBase and find one article that has every step needed for modifying a RHEL disk to have the KS script on the disk.
* Training. Having been through a few RH training classes I can say they are all very good. Yes there are some areas where I have questioned the need to know some things, but that is normal, but I'm never left feeling like the class was a waste. I have always walked out having learned many things which I can use later.
* Consulting. Yes there are many open source consultants who can come onsite and help implement a solution or fix something, however how many of them have access to the people who wrote the Distro or maintain the upstream project? RH has an internal list just for technical questions, many of the engineers are on this list and very technical answers are delieverd. Often SAs (Solutions Architects) and Consultants will post questions their clients have asked. I have yet to see a response of "Why would you want to do that?" or "RTFM."
* Additional products. Red Hat takes upstream projects and repackages them to integrate tightly with RH. Satellite is one example, it comes from Spacewalk and is designed to help keep internal systems up to date and patched according to their channel assignment. Could you use Spacewalk to manage your CentOS machines, yes you can! However let's say you have a problem getting Spacewlak to work right, or there's a bug, what kind of support
Re:Update & security responsiveness (Score:4, Informative)
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.
You could also use Scientific Linux instead of CentOS. SL has the backing of CERN behind it, and as a result it has been much more responsive to that sort of thing. SL 6.0 and 6.1 came out much sooner than the CentOS team could port (hell, I think we're still waiting for CentOS 6.1). SL is pretty much otherwise identical in spirit to CentOS... pretty much a white-box clone of RHEL. Sure there are a few minor improvements [scientificlinux.org]. And there's a LiveCD!
CentOS itself was apparently launched by a diskless clustering company [infiscale.com], which has since started primarily developing on Debian. So I kinda anticipate SL becoming the premier RHEL clone.
Most places I've worked for would develop on CentOS, then swing for the RHEL license when they deploy to clients (probably so they can bill it and markup a "handling fee").
There is a movement to migrate everything to RHEL for security reasons (mainly so you have someone else to blame if your server gets hacked for any reason, I suppose if you're running CentOS you basically might have to suck up the blame).
I would like to support Redhat financially, but I'm more of a Debian guy, and the RHN is more or less broken on the RHEL6 licensed VM that work bought for me due to some certificate error :-P
Still not Windows (Score:4, Insightful)
You are lucky your CIO is not wedded to Windows. Stop complaining.
CIO may be reasonably well informed (Score:4, Interesting)
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.
Re: (Score:3)
I'd be willing to bet that his behavior isn't exclusively on the weekends. He probably sits in his cube researching why the CIO should change his mind, and complaining to other employees that he's right and his boss is wrong. I've seen it happen so many times, it isn't even funny.
Re:He's unlucky his CIO's a fool then (Score:4, Insightful)
Just a very short refutation:
counting numbers of security advisories issued for a product is an entirely useless metric when it's up to the creator of the product under what circumstances to issue an advisory. Red Hat could stop issuing security advisories for anything tomorrow, and by your metric, it would then be the Most Secure Thing Ever.
By counting advisories and then ranking on the basis that more advisories = less security you're essentially punishing good behaviour. It's not a _good_ thing to encourage companies to stop telling you about security issues.
Linux is free if your time is worthless. (Score:2, Insightful)
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
Linux is free if you have a brain. (Score:5, Insightful)
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.
Re:Linux is free if your time is worthless. (Score:5, Insightful)
"Linux is free if your time is worthless".
This is possibly one of the most useless quotes ever. Does it take zero time to build and deploy a solution on Windows? No. Does it take zero time to build and deploy a solution on any other platform? No. Building and deploying a solution on any platform takes time. So what is the point of this quote? If it is to state that building and deploying software takes time, then it is stating the obvious, and needlessly singles out one platform, when the principle applies to all. If the point of the quote is to suggest that Linux based solutions require more time than those of other systems, then the evidence suggests otherwise, as studies have shown that the average Linux admin is able to support a greater number of servers than a similarly qualified Windows admin.
Linux is free. You can download it for free. You can run it on as many servers, with as many CPUs and users as you want, and you don't have to pay anything to anybody. That is what free (in this context) means: "Free: Without cost or payment." Nobody ever claimed that by choosing Linux you would have no work to do - that somehow, amazingly, your servers and systems would get built and deployed by magical Linux elves, who do your job for free. It's an absolute strawman argument.
Re:Linux is free if your time is worthless. (Score:4, Informative)
His point is that the cost of a RHEL license is only a tiny component of the TCO of a server. After that, if anything goes wrong, then the question is: is the price you pay for RHEL support less than the time it would take you to handle it yourself? Also, as someone else pointed out, RHN adds configuration management and faster patches. Time to set up some other system to management system configs; time to repair or replace hacked boxes because a centos patch was too slow... In the grand scheme of things, those may not be worth it. For example, in a fully-loaded 12-core system being used for virtualization hosting with a 4:1 cpu overcommit, RHEL only costs $.0019 per vm-hour.
Also, long term support is a big deal in enterprises. A lot of times large enterprise projects are built over the course of years. Having Red Hat means that when some change to a piece of hardware firmware causes some inexplicable OS crash 5 years after deploying. It may be very specific to your environment and your hardware and software. You can call up Red Hat, and if it hasn't been fixed, they will go in and fix the source code in order to fix it for you. There are cases where the systems and their function is worth hundreds of thousands or millions of dollars; having Red Hat able to "stand behind" Linux is worth paying for, for some people.
Re: (Score:3)
We had a large free solution deployed for several years. It was kind of aggravating to manage and finally invested in a commercial payed solution.
I just calculated that the commercial solution saved us the full price of the software and its support contract every 2 years on electricity. And that's ignoring the hundreds of hours gained from efficiency.
All operating systems are effectively free. If $120 every 3 years for Windows is a sizable expense per employee... your'e doing something horribly wrong at
Businesses look at Total Cost of Ownership (Score:3)
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 chan
Give Em A Call (Score:5, Insightful)
Give Red Hat a call. Seriously, if their sales department can't justify it for you, it's not justified.
Re: (Score:3)
This is really good advice. Not only will they give you some bullet points for making your case, but there's a good chance the account trip can give you a few discount points to try and win the business.
Re:Give Em A Call (Score:5, Insightful)
Fair answer... but I'd say truthfully, the SALES department isn't really the group you want to rely on if you need an honest answer. It's their job to maximize sales, so you can expect them to sugar-coat a lot of things and exaggerate the usefulness and capabilities of whatever they're hawking.
They're not bad if YOU already know you want the product and want some more ideas to make a good case for it. But what I'm seeing here is a guy who seems concerned that businesses the size of the one he's in are "supposed" to be buying Red Hat to help support the project, yet they're opting out because they feel they can get by fine with a free alternative that wasn't necessarily made available with intentions of companies like his using it to bypass paying for Red Hat.
To that, I'd say -- no, Red Hat is a commercial business like any other. They're not a charity. The CIO may be the smart one here. I haven't had to work with Red Hat support before, but my workplace pays a lot of money out in support contracts that generally get very little real use. I think they pay for them primarily as a form of insurance, out of FEAR of what might go wrong in the future. Regardless, if I looked back for the last 5-6 years at all the maintenance/support agreements we own and tried to actually cost justify them based on incidents where we used them? Wow ... that would easily average out to several thousands dollars for each hour of time spent on the phone for support!
Re:Give Em A Call (Score:4, Informative)
A salesperson who does not bend the truth is far and away the exception. Good on you. But more good on your employer who doesn't structure your pay to essentially require you to compete with your colleagues (on a quarter by quarter basis, not over time) who all DO bend it. Because if they did, you'd get let go if you fell behind, so you'd be similarly dishonest or let go. That's how the vast majority of sales organizations are structured.
Support and Release Schedule (Score:3)
Re: (Score:3, Interesting)
There are good and valid reasons why Centos is currently falling behind RHEL in doing updates. Red Hat is making it more difficult for Centos to keep up. This may not be intended to target Centos, but rather Oracle who has been using Red Hat's own work to sell a competing tech support service.
However, Centos gets caught in the crossfire. This [centos.org] email from Johnny Hughes lays out some of the issues that Centos now has to deal with that were never an issue before.
Here is what he has to say:
QUOTE:
Yes, and NOW
CentOS is F5 Networks (Score:3)
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.
What does support mean? (Score:5, Insightful)
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.
Re:What does support mean? (Score:4, Insightful)
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).
The real question is: Have you ever used your fire insurance? If no, do you think it would be a good idea to drop it? I'd call it excessive if you used it even once a decade. Most companies I know really have support because they can't afford to have a big staff waiting around for shit to hit the fan, but if shit hits the fan they can't afford extended downtime. What if your main man is on vacation or hospitalized or just left the company? The minor features and bugs that get fixed might be perks but that's not really why they're paying. And that's why the CIO's suggestion might work fine this year. And next year. And the year after that. But when your production server just keeps crashing and the backups just keep crashing because it's hit some ugly condition and you need people that really know the system and you need them right now, that's when you want support. But it's rather hard to argue with a man that think lightning never strikes.
Have it put into writing. (Score:2)
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 you
Re: (Score:3)
you don't want to be pulling your hair out at 2am in the morning... or worse yet, at 2pm in the afternoon, during a deployment/conference/expo/etc.
If you're deploying anything straight to production without testing that exact thing somewhere else first, you deserve whatever you get. RHEL can't cure that level of stupidity.
Tell me again what the problem is here? (Score:2)
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.
Typo in headline (Score:2)
How can I justify redhat or redhat-based distribution when there is debian?
Paid support (Score:2)
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.
Depends.... (Score:3)
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.
Re: (Score:2)
they'll struggle to maintain Linux without someone like Redhat backing them up.
I have to call that out. It has not been 1993 in almost 20 years.
What do you want? (Score:3)
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.
Re: (Score:2)
To be fair, CentOs is pushing out all the 6.1 security releases to 6.0 users (like myself), so it isn't quite as bad as you state. Granted, it isn't great, but the systems are still fairly secure.
That said, I would be lying if I didn't admit I have been looking at Scientific Linux, only because I cut my teeth on RH back in the 90s and used to the layout, and Scientific may have a better product when it comes to updates.
Go with CentOS plus one action (Score:3)
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.
Re: (Score:3)
Agreed. In addition. Businesses, and people, should toss distro_of_choice $25 per installed copy just to keep distro_of_choice around. If they like it enough to run a business on it, they should contribute in one way or another.
We use Centos at work... (Score:3)
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.
Re: (Score:3)
This is what pushed me away from CentOS after about a year or two. It makes it rather frustrating to compile your own stuff, due to the RPM hell that hasn't changed all that much since the early RH days (I'm talking 1990's). If a tarball doesn't come with a Spec file, you're fucked and will be spending an extra couple of hours figuring it out on your own - either that, or you install the CentOS-maintained version and install the source-built on over top, fingers crossed hoping you don't break some critica
How can you justify using Red Hat? (Score:2)
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 qu
Red Hat isn't a charity (Score:2)
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.
Security, CEO/CIO due diligence (Score:2, Interesting)
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 o
Support (Score:2)
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 sys
Get what you are told if you have it in writing (Score:2)
Liability (Score:3)
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
Why? Simple, lack of security updates (Score:2, Informative)
CentOS went three months without a single security update earlier this year, who in their right mind would touch it given that history?
Re: (Score:2)
A good backup plan (Score:2)
Ask the CIO: will we be opensourcing our software? (Score:2)
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.
Your CIO geenralizes a little bit strongly. (Score:2)
> 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.
Why do you want to (Score:2)
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?
Support = you (Score:4, Interesting)
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.
CentOS have been lagging on updates lately ... (Score:5, Interesting)
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 company size (Score:3)
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?
...the whistle you don't blow (Score:5, Interesting)
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.
Re: (Score:3)
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.
That's a great approach if you are interested in competing with your boss, and taking his job. But you'd better be sure you can do it before you get that aggressive, because if he's politically savvy -- and it's not likely he got to be CIO if he's not -- he'll recognize that you're setting yourself against him. Depending on his character and his level of confidence, he may do nothing, he may just put a mental black mark against you to be remembered during next year's performance reviews, or he may set out
Not just support (Score:3)
Just compare the release [wikipedia.org] histories [wikipedia.org]
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 [mail-archive.com]. 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.
EULA (Score:3)
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.
Re: (Score:3)
Be prepared to seek employment should you decide to let the "CIO" read this story.
It's very likely that a CIO who knows the difference between CentOS and RH and can take a risk of skipping support reads Slashdot on his own.