Oracle's Take On Red Hat Linux

darthcamaro writes "For nearly three years, Oracle has had its own version of Red Hat Enterprise Linux, claiming the two versions are essentially the same thing. But are they really? As it turns out, there are a few things on which Oracle and Red Hat do not see eye-to-eye, including file systems and virtualization. The article quotes Wim Coekaerts, Oracle's director of Linux engineering, saying, 'A lot of people think Oracle is doing Enterprise Linux as just basically a rip off of Red Hat but that's not what this is about. ... This is about a support program, and wanting to offer quality Linux OS support to customers that need it. The Linux distribution part is there just to make sure people can get a freely available Linux operating system that is fully supported.'"

Comments

Is anyone actually using Oracle Linux?

[lacourem]

Serious question. My employer has recently stated that they would prefer us to use Oracle Linux for future installations instead of Red Hat. Just looking for some insight from someone else who has taken the plunge.

Some reasons for the Oracle case

[DiegoBravo]

I support a software product in a telco, and had talks with its IT managers about the Oracle Linux issue. They have lots of Red Hats but see the Oracle offering interesting (and are implementing it) because:

1) Linux (RedHat or others) are really stable systems (compared with other Unixes they had or have), so the support provider switch is not seen as a dramatic issue
2) They can save some cents without (apparently) giving anything. The RedHat support is little money for that kind of company, but a saving always looks good for the directors
3) They avoid one provider's negotiation as a whole (which is a big win: less paper, less meetings, less vendor talk, less decision process, etc.)
4) They mostly ignore the distributed filesystem issues, and for virtualization just apply the leader (VmWare), so the Xen/KVM/Xen-Oracle discussion is not too relevant
5) BTW, for some diverse reasons, their software providers seem to dislike CentOS (maybe the RedHat's negative marketing made its effect, who knows)

ooh the controversy

[mutantSushi]

I'm not THE most knowledgeable on the minutae of these, but all the bad blood about Red Hat/ Oracle seems silly: The whole point of "Free Software"/Linux is that any company does not "own" code or software (well, they still do, but give up any claim to interfere with others' use of it). Commercial Linux companies obviously need to make their money thru support services. So Oracle thinks they can compete against Red Hat in this area. Obviously, Red Hat as the signifigant maintainer/updater MAY have an advantage. All the end-users get to decide it themselves, and since the code-base is so close, it's relatively easy to switch back and forth. What is the problem when "Free Software" is working exactly how it's supposed to? So what if Oracle eats Red Hat's business for lunch without contributing back? Linux will still be improved by those who want to improve it. All that such a scenario would mean is that (if it occurs) the model of maintenance/support service subsidizing development may not work for all cases. If that's true, then so what?

Re:Total Flamebait

[MoreDruid]

Yes you get support from 1 vendor, however I recently had to deal with that vendor. There was already a support case, all kinds of log files uploaded for them to analyse and after 1,5 week they hadn't found the issue yet. What was the problem? at 4:20 every night 1 of the servers in a cluster of 4 went down. The issue was that updatedb was configured to run on OCFS filesystems, and updatedb is triggered by cron.daily. They had about 5 different engineers looking at our case. No solution, until someone from my company decided to dig a little further into the updatedb config. It seems that you shouldn't run updatedb on OCFS filesystems (we have another customer who has been doing that for more than half a year with way more nodes concurrently connected, but hey). Note: this happened after issuing a Oracle CRS (cluster software) update, the config had been running fine for more than a year. And Oracle support just kept on looking to the Oracle part, ignoring the OS stack. From Oracle Applications support I was told to "just update glibc from 3.2 to 4.x because there's a bug that's fixed in 3.6". Right. Break compatibility with all your major tooling and applications so you can run an Oracle App because they've been too lazy to test in an "old" environment (RHEL 4 U4).

In short: I'd rather deal with 2 or 3 independent vendors who know their shit (and know it well), than with 1 vendor who would - even when told differently - kept looking from the wrong POV.