Slashdot Mirror
Red Hat To Help Develop CentOS
An anonymous reader writes with news that Red Hat and the CentOS project are "joining forces" to develop the next version of CentOS. For years, CentOS has been a popular choice for users who want to use Red Hat Enterprise Linux without having to pay for it. Some of the CentOS developers are moving to Red Hat, but they won't be working on RHEL — they say the "firewall" between the two distros will remain in place. CentOS Project Chair Karanbir Singh said, 'The changes we make are going to be community inclusive, and promoted, proposed, formalised, and actioned in an open community centric manner on the centos-devel mailing list. And I highly encourage everyone to come along and participate.'
I suspect few desktop users run an OS targeted for "servers" where stability is the number one goal?
2.6.0 came out in 2004, 3.0 (the next after 2.0.39) in 2011. You are not being very precise saying 2.6 related to redhat kernel. But, about to your point, Redhat/centos 5.x came with kernel 2.6.18 (released in 2007, still had the same kernel version in RedHat 5.10 that came out last october), and Redhat 6.x, that came out in 2010, had kernel 2.6.32 (released in 2009). As enterprise distribution, what matters is stability, and certification for 3rd party software, not having the latest versions, all is tested with an specific kernel version, and that kernel (and in general, packages) are kept in the same version, backporting/patching fixes when necessary, and you won't have to worry about a newer version of a sofware changing a configuration file format or keywords and stopping working after updating. Anyway, you can still install extra repositories (like EPEL) that will give you newer versions of some packages.
If you want to use something bleeding edge, you can try Fedora, Ubuntu, or another of the desktop distributions
I have had occasion to run into a kernel bug (back when AMD64 was still a new adventure) and, due to being at a large organization that regularly paid Red Hat various sums of cash, was put in direct contact with high level support. I provided them with my analysis of what was apparently going wrong and a C program to reproduce the failure in a short time (otherwise it would only occur naturally after a system had been running jobs for several weeks to months). Within a day or two they sent back a custom patched kernel that fixed the issue, and later rolled that fix out generally in the next update release (though, admittedly, that second part took quite some time). I might be a competent programmer but diagnosing and fixing a fundamental problem in the kernel and then being on the hook if it has undesirable side-effects isn't something I'd want to do myself, nor could I expect such a rapid answer from the community for what was basically a small corner-case problem, but one that was affecting our business. Having the support is what made the difference.
Of course, for many cases, self support and community support can be good enough, but all it takes is one major issue where you can't solve the problem and you're losing revenue and reputation, and all the sudden that "expensive" support starts to look really cheap in comparison.
And I also agree, stay far far away from Oracle Linux if at all possible (heck stay away from Oracle altogether if you can, but that's frequently impractical).
Its actually about time. We old timers remember when RedHat was free and support was the money maker for RedHat. Then they split to RHEL and Fedora, that was bad and caused a lot of initial distrust of RedHat. Fortunately, RedHat didn't screw everyone and is doing largely the right thing.
The problem with the RHEL/Fedora split was it made two different strategies. If it were not for CentOS, RHEL may have lost a lot of business. Now that Oracle wants to steal RedHat business, keeping CentOS viable keeps the mind-share of people who neither need nor want support using the equivalent of RHEL while RedHat keeps its customers.