On 14/12/10 02:15, Nico Kadel-Garcia wrote:
> On Mon, Dec 13, 2010 at 1:37 PM, Gé Weijers <ge@xxxxxxxxxxx> wrote:
>>
>>
>> On Mon, 13 Dec 2010, Nico Kadel-Garcia wrote:
>>
>>> RHEL is much better about that, although by now the "production" RHEL
>>> 5 is 4 years out of date, the "leading edge" RHEL 6 is now one year
>>> out of date after the lengthy release testing, and CentOS will always
>>> lag that.
>>
>> I believe "out of date" is the wrong wording. RHEL/CentOS 5 is maintained,
>> i.e. security issues and bugs are fixed. There's nothing "out of date"
>> about a tool that works and is cost-effective. RHEL 6 still has to prove
>> itself.
>
> From harsh experience, I'm afraid it's the right wording. You can only
> go so far with "backporting", and critical feature additions (such as
> the availability of GSSAPI in OpenSSH, warnings of local password
> storage in Subversion, git emacs macros incompatible with the out of
> date Emacs, and PHP dependencies unfulfilled for contemporary tools
> make it quite stale.
>
>> In my day job I support dozens of developer desktops that run CentOS 5 with
>> a modified kernel supporting non-standard devices. It takes a few hours a
>> week. Trying to track the bleeding edge supporting, say, Ubuntu would take
>> much more time.
>
> 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.
See this link for a more info:
<https://access.redhat.com/support/policy/updates/errata/>
What makes some of these backports tricky is that they work hard to
maintain ABI (Application Binary Interface). That means that if you
have an application using a specific library on RHEL/CentOS, that
application should not need to be rebuilt at all if an updated library
is installed. This gets even more difficult when looking at kABI
(Kernel ABI), where the kernel can not change things in a way which
breaks user space tools or libraries.
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).
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.
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.
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.
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.
kind regards,
David Sommerseth
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
