[CentOS] Issues with CentOS in enterprise

Wed Dec 15 02:41:14 UTC 2010
Nico Kadel-Garcia <nkadel at gmail.com>

On Tue, Dec 14, 2010 at 4:40 AM, David Sommerseth
<dazo at users.sourceforge.net> wrote:
> On 14/12/10 02:15, Nico Kadel-Garcia wrote:

>> Well, yes. But the edge on RHEL 5 is 4 years old,a nd RHEL 6 (end
>> eventually CentOS 6) will have been blunted for a year by the time
>> it's published. It's a problem if you try to backport contemporary
>> tools (which I do).
>
> RHEL/CentOS isn't supposed to be cutting-edge.  That has never been the
> intention.  It's supposed to be stable for 7-10 years.  And I believe
> CentOS strives for the same, as they basically just re-wrap and re-brand
> RHEL packages.
>
> That means that some of the software will stay behind, especially if
> there are no nasty bugs and security issues with them.  Other critical
> software pieces will be updated, especially when it is related to bugs
> which endangers the stability or security of the system.  But for an
> update of the software to happen, developers and tester strive to make
> sure it won't break compatibility or cause instabilities.
>
> The kernel itself is a brilliant example.  It's based on 2.6.18, but it
> contains a lot of features and hardware support which even came as late
> as in the 2.6.3x series.  Just look at the KVM support which came in
> RHEL/CentOS 5.4. KVM was first introduced officially in the 2.6.20
> kernel, IIRC.  In addition, security issues which has been located in
> all kernel versions which also affects the 2.6.18 based kernel is
> backported.

Backporting tiny bits of kernels to get a feature isn't enough, when
you refuse to upgrade the components that interact with it. Take a
good look at wireless device and graphics tablet support for examples
of tools that require more than just one "fix". This kind of thing is
a long standing issue since RHEL and Fedora splilt. Stability is good,
but wasting engineering respinning installation media is not.

> See this link for a more info:
> <https://access.redhat.com/support/policy/updates/errata/>

Been there, done that, submitted patches to EPEL and RPMforge on a
regular basis.

> And this stability has its cost ... that you will not find bleeding edge
> versions on most of the software.  There are some exceptions, but that
> is very seldom (Upgrading from Firefox 1.5 in RHEL5 to a 3.x based one,
> comes to mind).

Well, true. But it's so stable it's pushing up daisies. RHEL 6 was long overdue.

> When it comes to git support in Emacs, that is most probably due to that
> you try to install a newer git module in Emacs than what is supported.

Not. Emacs incorporated the vc-git.el module directly into emacs-22.
The later git modules are also not backwards compatible with the older
vc-git.el module, formerly published in git, and the older set of git
modules are not compatible with contemporary git. So unless I plant to
spend a lot of time going back and re-writing Lisp code (and I *HATE*
Lisp code), or find someone else more comfortable with it who's not
simply using Debian, Ubuntu, Fedora, Mandriva, or even CygWin, the
emacs modules are not usable in RHEL/CentOS 5 with git.

> And IIRC, you even need to pull in git via EPEL, as git is not even a
> part of the standard RHEL5 package set.  So in this case, git support
> isn't even expected in a standard RHEL/CentOS installation.  Like it or
> not, but that's how the RHEL/CentOS world is defined.

True. I've been trying to get it updated there: the EPEL version is
stuck at 1.5.5,

> And also take into consideration that RHEL6 is shipped with approx.
> 2.000 packages.  And there are over 10.000 packages available for
> Fedora.  Such a limited package scope is needed to be able to provide
> stability.  And this stability is why so many loves to run
> RHEL/CentOS/ScientificLinux instead of many other Linux distros on their
> servers.

And they're actually supporte, rather than happenstance assembled and
published, which is great. i don't discount this. It's just gotten too
darned *old*. I went through the same thing with RHEL and CentOS 3 and
4, but RHEL 6 is particularly late.

> For the desktop side, I personally do see this restricted package list
> and long lasting package support (7-10 years) as a much more difficult
> barrier.  But for the server side, I'm happy it is as it is.  It gives
> me less to worry about.
>
> So if you want a bleeding edge environment, go for Fedora.  What goes in
> here might go into RHEL and then CentOS with time.  What's not going
> into a new RHEL release might show up in EPEL, especially if you take
> care of that to happen.  You can have that power if you want to.

I find RPMforge more workable and responsive: The "we refuse to
replace any RHEL published components" general policy of EPEL is
unacceptable for tools like Subversion and MRTG and Nagios.