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.