RHEL 6 - your sensible but lovable friend
Ubuntu it isn't
Ensure Ease of Recovery with Asigra’s Agentless Software
Review The first major update for Red Hat Enterprise Linux in more than three years hit last month, and judging by the traffic that took down Red Hat's download servers, it's long over due.
RHEL 5 came out in March 2007 with the Linux 2.6.18 kernel and while incremental updates have added kernel updates and new features, it's showing its age.
Of course, the whole point of running an enterprise distro like RHEL is that it isn't Ubuntu or Fedora, and it doesn't completely change all the rules every six months.
Still, there's a balance to be had, and even by enterprise standards RHEL 6 is a long time coming. But the RHEL 6 beta is here and the good news is that there's plenty to love.
For RHEL 6, Red Hat is using a Fedora development release based on the Linux 2.6.32 kernel - technically, it's a hybrid of several recent kernels. Red Hat engineers have hardened the Fedora base and added quite a few features - with a strong emphasis on virtualization.
One of the main goals for RHEL 6 was to make managing virtual servers as easy as managing physical machines, which means the bulk of the new software features are found in KVM. It also means that Xen is gone, though that's hardly surprising since Red Hat purchased Qumranet - creators of KVM - back in 2008.
A wide selection of disk formatting options include ext4
RHEL 6 builds on the KVM-based virtualization found in RHEL 5.5 and earlier releases, adding a number of performance and hardware support upgrades.
Also new for virtual guests is the SELinux sandbox feature that allows guest machines to run in isolated environments. The new sandbox features can be applied to just about any untrusted code you'd like to execute, but it's particularly handy with virtual machines.
Other improvements in the beta include changes to the way RHEL 6 handles multi-core chips. In theory, RHEL could use 64,000 cores in a single system image. Along with the better multi-core support comes the same support for new chip architectures that we saw in RHEL 5.5, including Intel's Xeon 5600 and 7500 and the Power7 from IBM.
Another big change in the RHEL 6 beta is the wide selection of disk formatting options, including ext4. You know a Linux feature has arrived when it makes its way to the conservative enterprise releases like RHEL and such is the case with ext4 file system, which is now the default filesystem format in RHEL 6. In addition to ext4, the XFS filesystem is now supported.
Next page: What ever you want
COMMENTS
Enterprise distributions
> "Of course, the whole point of running an enterprise distro like RHEL is that it isn't Ubuntu or Fedora, and it doesn't completely change all the rules every six months."
Can you clarify that? Are you saying that Ubuntu isn't an enterprise distribution?
Ubuntu Server LTS is an enterprise distro with (optional) commercial support and is supported for 5 years. Definitely not a 6 month rule changer. If you want a less stable distro, you can go for the non-LTS releases.
Fedora on the other hand is totally different and I'm not sure the two should be compared like that. I think the section of the article above is misleading.
Double-edged sword
When I switched from Red Hat (original, not RHEL) to Ubuntu as my main distro, it was exactly this dilemma that bothered me. I was not looking for an Enterprise release specifically, merely one that I would not have to upgrade every 6-9 months, but which would remain current enough that I could still get packages to compile.
Fedora became too volatile, and (I'm afraid), I was not in the market for paid support, which made RHEL unattractive to me.
I selected Ubuntu (then fairly new, I jumped on at Dapper), and have mainly stayed on LTS releases although I did put Jaunty on a netbook.
My experiences are that Enterprise or LTS releases have good and bad points.
If you remain too far behind the curve, it actually becomes quite difficult to add compile-from-source applications, but you do get good availability and stability. As my day-to-day system is a laptop which I used to plug in all sorts of miscellaneous hardware to try to get working (I was ahead of the releases for WiFi, 3G broadband, TV adapters, HomePlug adapters), I needed to be able to take what was currently being worked on, and try it. This became impossible if you fell too far behind the mainstream.
If, however, you follow the curve too closely, then for a period of time after an initial upgrade, you may have stability and functionality issues. Like many users, I had quite a challenging time when PulseAudio became the preferred sound system.
My answer is to remain on the previous LTS release until the new one is 3-6 months old. This allows you to remain fairly current, but avoid many of the teething troubles. I'm looking at Lucid on one of my systems, but will not switch from Hardy yet.
Of course, many enterprise systems will be installed for specific applications, rather than for general purpose use. For these, upgrade the system in line with the application. Once you have it stable, leave it for as long as you can (security updates excepted), and only consider an OS upgrade if the application requires it, or the OS drops out of support.
To all of the people who are complaining about major applications changing with upgrades, what the heck! Just put your favorite on *in addition* to the new one. They are likely to still be in the repository in most cases, and work as before, unless the package owner upgrades it significantly (I still rue the day that xmms became xmms2).
Re: RHEL Empathy v Pidgin?
@ozmark: exactly. It'd be news if we could strip the fracking thing down to remove the rubbish. Ever tried to remove cups printing support from a web server? 'Sorry, cups is required by gnome, gnome is required by gui-netconfig, gui-netconfig is required by base'. FFS.
IT infrastructure monitoring strategies
Agentless Backup is Not a Myth
Top 10 SIEM implementer’s checklist
Steps to Take Before Choosing a Business Continuity Partner
Enabling efficient data center monitoring
