On Tue, Dec 14, 2010 at 4:40 AM, David Sommerseth dazo@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.