To read all comments associated with this story, please click here.
What's most annoying is that after including an 18 to 24 month release cycle promise in their sales material for every release from 2.1 through 5.something, Red Hat decided to simply ignore that promise, without so much as an explanation and/or apology. At 18 to 24 months between major releases, RHEL makes a decent XDMCP/NX server. But now, midstream, they say "Oh, it's going to be more like 36 months this time. That works out better for *our* business needs.".
Some parts are not so difficult to update from third party sources. Like OO.o. But how about Evince? Updating it to a later version is a source code dependency nightmare. Important business PDF documents which I know open just fine in later versions of Evince, fail to open for my users. And we were supposed to have had an upgrade path by last March.
Edited 2009-07-01 20:36 UTC
This is the first time I've heard an Enterprise customer complain about a lack (?!?!?) of major version changes.
RedHat decided that they rather re-base major changes (KVM, FF3, Evolution, kernel driver upgrades, etc) and delay RHEL 6 until it's ready.
As someone that ships proprietary software around RHEL, I can only agree.
- Gilboa
I agree that that's a long time, but in Redhat's defense, that is an issue with the desktop chosen, not RHEL itself. GNOME is a dependency nightmare, but thats part of what make it work the way it does, its got its hooks fairly deep into the core of the system. Problem is that there is a point where it ceases to just be a gui overlay.
In contrast, if you were running KDE,XFCE,Fluxbox, etc...you could freely move between desktops with very little dependency on the core. KDE-Redhat group releases new builds regular of KDE, but its not to difficult to compile.
When it comes to the desktop, let put blame where it belongs, and that's the desktop project. GNOME, as much as i like it, has always had this issue, it is virtually impossible to change the version of gnome on a system, without upgrading pretty much everything thats not a server process lol. KDE is MUCH better in this regard, not being to picky about the underlying OS, but KDE4 has been a bit of a disaster thus far.
Pick your poison..
Indeed, that's correct. And I have never upgraded the version in CentOS-Extras, because newer versions were unstable. I have built newer versions of KVM, but there were always show-breaking problems for some of the users beta-testing it.
Things may have gotten better now, but I am not actively involved with CentOS anymore.







Member since:
2005-07-06
I'm using CentOS 5.3 (aka the "free" version of RHEL 5.3) at the moment and its kvm release is woefully old (kvm-36, qemu-0.9.0, libvirt-0.3.3, virt-manager-0.5.3). Considering that Red Hat bought Qumranet and made a big splash about virtualisation in RHEL 5, it's astonishing that the various KVM components are so ancient (anything up to 18 months old!), especially since they had chances to update them with RHEL 5.1, 5.2 or 5.3 and simply didn't.
Current versions are kvm-87 (yes, 51 releases after the one shipped with the current RHEL 5.3!), qemu-0.10.5, libvirt-0.6.4 and virt-manager-0.7.0. If RHEL 5.4 doesn't ship with those versions or something very close to them, then I will be staggered (again!).
Because of this stagnation, I find I cannot use KVM "as is" in the current RHEL 5.3/CentOS 5.3 releases - it simply doesn't work well at all and it's currently an embarrassment that Red Hat need to address with the 5.4 release.