TAG | redhat
As I keep getting asked by customers when they can expect Red Hat Enterprise Linux 6, I thought it was worthwhile to make a post on the subject. This is a reasonably long post, but the simple answer to the question is that I don’t know, but my educated guess would be Q4 2010, and that we’ll have a firm(er) date by the end of June. Please note that I’m not a Red Hat employee, although my company is a Red Hat partner, and that nothing in this post is official in any way, shape or form.
Red Hat Enterprise releases have been traditionally 18-24 months apart, and on that basis one might have expected RHEL6 to have been released sometime between October 2008 and March 2009, as RHEL5 was released in March of 2007. So what’s taking Red Hat so long, and when can we expect RHEL6?
There are a number of reasons for the delay, but the biggest is related to the Fedora Project, who create Fedora, on which Red Hat Enterprise is based.
For Fedora releases up to version 6, on which RHEL5 was based, the Fedora Project was run very much as an in-house Red Hat project, with contributions from the wider Open Source community. Post FC6, the Fedora Project was much more run by the Open Source community, with Red Hat contributors. This seems to have led to a shift in focus from fixing bugs to implementing new features. This isn’t necessarily a bad thing – Fedora exists to be the ‘bleeding edge’ of development, pushing at the boundaries in a way Red Hat are obviously unable to do with an enterprise focussed product like RHEL. Unfortunately, Fedora 9, on which RHEL6 was to be based, released with a large number of critical bugs and stability issues. Red Hat made the decision that they therefore couldn’t base RHEL6 on this release, and instead poured man-power into the Fedora Project, fixing bugs and generally improving stability as much as possible.
The evidence is that RHEL6 will now be based on Fedora 12, which was released in November of last year. The was a gap of just under a year between Fedora 6 and RHEL5, so this would point to a release in Autumn of this year.
The other issue that has caused delays to RHEL is that of virtualisation. RHEL4/RHEL5 utilised the Xen hypervisor for their virtualisation. In September 2008 Red Hat purchased Qumranet, whose staff included the leaders of the KVM project, an alternate virtualisation technology. KVM is very much seen as the future for Linux virtualisation, and Red Hat immediately made it clear that this was the direction they would be pursuing. RHEL 5.4 included KVM as a ‘technology preview’, so clearly much progress has been made integrating it into the main Red Hat release. It’s therefore likely that this is no longer holding up RHEL6.
I expect the final release date for RHEL6 to be announced at the Red Hat summit at the end of June. There have been some suggestions that RHEL6 itself will be released at the summit. Unless Red Hat release a beta within the next couple of weeks, I’d say this looks distinctly unlikely.
Some of you may have heard about the kerfuffle surrounding poor Perl performance on Red Hat 5/CentOS 5 – it got a bit of attention on reddit/digg. Red Hat had been issuing hot fixes to people who complained, but now Karanbir Singh has created an updated Perl package.
This issue should be fixed in RHEL/CentOS 5.3, but until then, if you’re experiencing slowness I’d advise installing this – after appropriate testing on staging/UAT servers of course.
The final version of Django 1.0 has been released. Debian packages are available from the unstable repository and these should install cleanly on Ubuntu too.
As I noted previously with the Alpha releases, an RPM for RHEL5/Centos can be built by doing:
python setup.py bdist_rpm
Note you’ll need an updated MySQL-python library installed, which can be found below.
MySQL-python-1.2.2-1.x86_64.rpm
If you’re not using a 64bit server, you can download this source RPM and rebuild via rpmbuild –rebuild:
Red Hat have released a security advisory detailing an intrusion on their servers. The attacker apparently managed to sign some compromised OpenSSH packages.
There is a parallel Fedora announcement, and although it seems that Fedora wasn’t affected they are issuing new package signing keys as a precaution. Red Hat use a hardware device for signing their packages, so they can make sure no further compromised packages can be created without having to re-distribute new signing keys.
Red Hat Network wasn’t compromised, so although the signed packages were created, there is no risk to those whose only means of obtaining packages is via RHN (ie, most Red Hat users).
Whilst there certainly isn’t any need to panic, this is sure to cause concern amongst those running Red Hat.
I’ve just put up an long-ish article I’ve written comparing five different server distributions. I fully realise that by doing so I’m opening myself up to hundreds of flames from outraged fans of <insert OS here>, all complaining that I’ve treated their pet distro unfairly.
Given that I’ll probably be accused of bias anyway, I better declare mine: the server that is serving you this page runs Ubuntu, as does the one running the main Bashton site. Many of our internal-facing servers run CentOS. My desktop runs Ubuntu, and my laptop runs Debian. Other staff have their own bias of course (particularly those who are Debian developers..), but as it was just me writing the article I don’t see that as relevant.
Please make your comments here and hopefully we can start some form of a useful debate, rather than the ‘distro X is the best’ discussions these things usually descend into.

