On 14/12/10 02:15, Nico Kadel-Garcia wrote: > On Mon, Dec 13, 2010 at 1:37 PM, Gé Weijers <ge at weijers.org> 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