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?"
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 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.
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.
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.
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. :-)
...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:Support and Release Schedule (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 the release process is MUCH harder.
Red Hat used to have an AS release that contained everything ... we build that and we get everything. Nice and simple. Build all the packages, look at it against the AS iso set ... done. Two weeks was about as long as it took.
Now, for version 6, they have:
Red Hat Enterprise Linux Server (v. 6)
Red Hat Enterprise Linux Workstation (v. 6)
Red Hat Enterprise Linux Desktop (v. 6)
Red Hat Enterprise Linux HPC Node (v. 6)
Red Hat Enterprise Linux Workstation FasTrack (v. 6)
Red Hat Enterprise Linux Server FasTrack (v. 6)
Red Hat Enterprise Linux Desktop FasTrack (v. 6)
Red Hat Enterprise Linux Scalable File System (v. 6)
Red Hat Enterprise Linux Resilient Storage (v. 6)
Red Hat Enterprise Linux Load Balancer (v. 6)
Red Hat Enterprise Linux HPC Node FasTrack (v. 6)
Red Hat Enterprise Linux High Performance Network (v. 6)
Red Hat Enterprise Virtualization
They have the same install groups with different packages based on the above groupings, so we have to do some kind of custom generation of the comps files to things work.
They have created an optional channel in several of those groupings that is only accessible via RHN and they do not put those RPMS on any ISOs ... and they have completely changed their "Authorized Use Policy" so that we can NOT login to RHN and use anything that is not on a public ... effectively cutting us off from the ability to check anything on the optional channel.
FTP server or on an ISO set
Now we have to engineer a compilation of all those groupings, we have to figure out what parts of the optional channels go at the point release and which ones do not (the ones that are upgrades). Sometimes the only way to tell is when something does not build correctly and you have reverse an optional package to a previous version for the build, etc.
We have to use anaconda to build our ISOs and upstream is using "something else" to build theirs .. so anaconda NEVER works anymore out of the box. We get ISOs (or usb images) that do not work and have to basically redesign anaconda.
We can't look at upstream build logs, we can't get all the binary RPMs for testing and be within the Terms of Service.
And with the new release, it seems that they have purposely broken the rpmmacros, and do not care to fix it:
https://bugzilla.redhat.com/show_bug.cgi?id=743229 [redhat.com]
So, trust me, it is MUCH more complicated now than it was with previous releases to build.
With the 5.7 release, there were several SRPMS that did not make it to the public FTP server without much prompting from us. And with the Authorized Use Policy, I can not just go to RHN and grab that SRPM and use it. If it is not public, we can no longer release it.
So, the short answer is, it now takes longer.
END OF QUOTE