On Tue, Dec 14, 2010 at 4:40 AM, David Sommerseth
<dazo@xxxxxxxxxxxxxxxxxxxxx> 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.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
