“Red Hat today officially announced the beta availability of Red Hat Enterprise Linux 5.4, which in my view is a lot more than a typical point release. Sure we’re all waiting for the big RHEL 6 release, but there are some major changes in RHEL 5.4. The most obvious change is the shift to the KVM hypervisor (as opposed to Xen). Xen is still in RHEL, but with RHEL 5.4, Red Hat is signaling its intention that KVM (eventually) is to be Red Hat’s preferred Hypervisor. It’s a preference that Red Hat execs have indicated at multiple points this year and should be no surprise since Red Hat now owns lead KVM vendor Qumranet.”
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.
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..
I disagree. Because the core problem is that Red Hat made very explicit promises to its customers, and then just arbitrarily broke them because it worked out better for their business model. Sounds like that same thing we point fingers at proprietary vendors for doing. If they had announced, ahead of the 5.0 release that “Hey, we’re going to go longer on the 6.0 release cycle”, that would be one thing. But they didn’t. Last I looked, which was not long ago, that same promise was *still* in their sales literature for RHEL5.[1] My customer would *not* have chosen RHEL if they had known what Red Had was going to unilaterally decide to do, for their own business reasons.
[1] http://www.redhat.com/f/pdf/rhel/rhel5_overview.pdf
Edited 2009-07-02 14:45 UTC
Red Hat has never shipped KVM with RHEL5 until now. If KVM is old in Centos it’s something that Centos added, follow up with them.
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.
You know things do take time to actually be built. Considering KVM really wasn’t in the kernel when 5.0 came out, you are pretty lucky to be even getting as much as you are. They do have a responsibility to not introduce a bunch of new crap that is buggy and crash prone. RHEL is suppose to be stable. You don’t get stable using the most current releases. Also, much of the management stuff is just being completed. KVM really isnt too useful in the Enterprise until they get all the management stuff built. If you want recent, use Fedora 11. If you need more stable, use Fedora 10. Just realize that you are going to be upgrading every 6 months. I am not a developer, but even I know you get to choose either stable or recent, not both. Every OS, even Windows is like this.