Red Hat Readies RHEL 5 for March 14 Launch

Rob writes "The wait is almost over. It may have taken two weeks longer than Red Hat would have liked, but Red Hat Enterprise Linux 5, the updated version of the company's commercial Linux platform, will be launched along with a bevy of new products and services on March 14. The delivery of RHEL 5, the fourth major commercial server release for Red Hat, will better position its Linux against Novell's SUSE Linux Enterprise Server 10 as well as Windows, Unix, and proprietary platforms. RHEL 5 has been cooking for more than two years and includes changes to the Linux kernel. In addition to the support for the Xen hypervisor, RHEL 5 also has an integrated version of Red Hat Cluster Suite, the company's high availability clustering software, as well as support for iSCSI disk arrays, InfiniBand with Remote Direct Memory Access (RDMA), and the SystemTap kernel probing tool."

Comments

"Enterprise Linux"

[EveryNickIsTaken]

At some point, one of these Enterprise editions had better have a Starfleet logo on it.

Re:"Enterprise Linux"

[Brian Stretch]

They're waiting for Intel to develop the exploding plasma conduit components. They got close with the P4.

Re:The wait is almost over?

[MartinG]

If you read the text a bit more carefully you will notice they were not specifically talking about you in particular. There exists a set of people who either use or intend to use RHEL. I imagine a subset of these are the ones likely to be waiting.

R Hell

[pzs]

My experience with RHEL was really not that good. We had an RHEL3 box which had a truly ancient version of Python installed - more than 2 years old. You couldn't force an upgrade, because packages could only be installed if fully compatible with that version of RHEL and that version of Python was the latest that was considered fully compatible. You couldn't do a major version upgrade to, say, RHEL4 without reinstalling the system. When I manually changed the version of Python by compiling it myself, it borked the package manager so it wouldn't get security updates anymore. I ended up with an old and a new version installed next to each other, which is fine, but I had to do all the work of getting them to coexist myself.

A similar story with PHP. To update from PHP4 to PHP5 was a good day of compiling and tweaking to make sure I could get it installed alongside a pukka packaged version of PHP4, thereby not upsetting the package system and invalidating our support.

I know their method is to restrict the versions to make it very well understood and easy to support. It just seems a bit pants to pay for a system that has less update capabilities than most of the free linuxes.

Peter

Re:R Hell

[MartinG]

We had an RHEL3 box which had a truly ancient version of Python installed

Do you realise how long ago RHEL3 came out?

You couldn't force an upgrade

I don't think your criticisms should be aimed at RHEL. If you wanted new packages over stability or wanted to be able to force upgrade then you picked the wrong distro. You are not their target audience.

If the stability of fedora is enough for your needs maybe you should look there instead?

Re:R Hell

[Raleel]

I agree with Martin's comments here. RHEL is Enteprise for a reason. It has long term support, it's stable. One might liken it to Debian stable, although it tends to be a bit more cutting edge than that, although not quite as cutting edge as testing, I believe (I could be wrong here. It's not exactly like I have done a one for one comparison of every package, so feel free to correct me).

I've been running Red Hat in an "enterprise" environment for about 8 years now. I've seen it go from an upgrade every 6 months to not needing an upgrade for the life of a box. Taking a look at our satellite server, I see 210 machines still subscribed to the RHEL 3, and even 13 subscribed to 2.1 (itaniums, hey, they still run!). These boxes are stable and secure, and I'm happy with that. They are performing their functions.

No doubt, it's not for everyone. Many people can't afford it, including myself in my personal life (alright, I could, but I really don't feel the need). Fedora is fine for those. Ubuntu is fine for those. Whatever other version you like is fine for those. If you want it to run with minimal upgrades, you stick with something that has support in some fashion for a long long time afterwards, like RHEL, where you can get security fixes for 7 years after release.

Re:R Hell

[tobiasly]

However, it's a bit disappointing that my employers were still paying a support contract on this box but the package updates that were part of this contract were more than 3 years old.

The point is that, even though the Python package may be 3 years old, if it's still under support, and tomorrow they found a security bug in that years-old version, you would still get a security patch for it.

I don't think it's too much to expect a little flexibility when you're paying for it.

That's the thing.. you're not paying for a little flexibility. You're paying for stability and maintenance. It may seem backwards to you but that's the exact sorta thing that most "enterprise" customers want. If they offered the sort of flexibility you're looking for, that would mean supporting multiple different versions of different packages within a single distro.

The reason they can offer such long-term support is that every user of every package in that distro is running the exact same version. It would simply not be economically possible for them to offer 7 years of support on a product if they allowed people to run whatever version they wanted, even as an option.

Re:R Hell

[Wdomburg]

I should say that I didn't buy or install this box. It was bought for a biological research institution and the guy who made the purchasing decision chose it because it was Dell's recommended choice. RHEL3 may be ancient, but it came on a fairly new machine, bought in early 2006, so they were obviously still selling it.

That seems a bit off. By early 2006 any current Dell would have been certified for RHEL4 (which itself was released early 2005). As a aside, license for RHEL are valid for any currently supported version, so even if it came imaged with RHEL3 you had right to install RHEL4.

It's fair enough that they focus on rock solid stability over new packages. However, it's a bit disappointing that my employers were still paying a support contract on this box but the package updates that were part of this contract were more than 3 years old.

The updates are not three years old. There was a new update published this morning. The base versions are old, but that's a feature, not a bug. When you're running production systems you want a stable platform with a reasonable deployment cycle, which is where RHEL excels.

I don't think it's too much to expect a little flexibility when you're paying for it.

When you pay for one of the enterprise platforms you're paying for stability not flexibility. It's actually more work for them to backport fixes to older versions than to blindly package newer ones, but new versions mean new bugs and incompatible changes. Some of us pay good money to avoid it, and RPM is flexible and easy enough for the few cases we actually need a newer version than what Red Hat ships stock.

Re:R Hell

[d3xt3r]

If you run an enterprise application, stability is critical in terms of both operational reliability and package versions. While I agree with you that some of the higher level applications that could be kept more "fresh", Enterprise Linux targets an audience that tends to run mission critical applications on their operating systems. These companies deal with a number of third party ISVs who certify their products on Red Hat Linux. If software package versions are changing constantly, ISVs will refuse to certify said changes due to the cost of doing so.

This was one of the problems with Red Hat's pre-Enterprise Linux audiences. ISVs saw Linux as a moving target. I think Red Hat does a good job of freshening what they can with their point releases.

Simply put, if you need bleeding edge software, you'll need to find it from Fedora or a third party repository. There are a number of repositories out there, AT-RPMs, Dag, RPM Forge, etc. that package applications for Red Hat Enterprise Linux. However, for Linux to be enterprise-ready, core stability (again in terms of versioning and reliability are a must.

Re:R Hell

[cortana]

Judging by http://idssi.enyo.de/tracker/status/release/stable , I would say that Debian is handling this the same that most other distributors have, i.e., lagging badly. mozilla.com have to take a lot of the blame for this.

Re:The wait is almost over?

[jimstapleton]

I stand corrected.

No, wait...

I sit corrected.

Re:The wait is almost over?

[hondamankev]

98% of all webhosting/VM companies and millions upon millions of corporate users I would declare as > 0 I'm personally anxious for this release. I loved RHEL 4's stability, but it was showing its age. 2 years in linux years is like, 10 dog years, which is like 120 people years.

CentOS 5

[Nighttime]

By looking at the release dates of CentOS 4.x and comparing them to the release dates of RHEL 4.x, it looks like we can expect to see CentOS 5 released on 28th March 2007.

The two weeks lead time would appear to be borne out by this CentOS FAQ entry.

Re:CentOS 5

[fimbulvetr]

This is far from offtopic. Centos is a complete build of RHEL5 from redhat's released sources, with RH's branding removed. The updates, etc, are then provided for free by the CentOS community. Centos is a great OS for people not needing RH's support, but needing RH's OS.

This is completely on topic, and I, like (probably) many other people, immediately wondered when CentOS's release would be after seeing this announcement.

crash dump

[br00tus]

One thing Solaris does well which Linux is still struggling with is crash dumps and crash dump analysis. I know it is easier with Solaris due to the integration between the OS and the hardware, as opposed to say Red Hat and a variety of supported vendors, but is definitely a nice thing to have. Especially if a system crashes and you bring it back up without a good analysis of what went wrong - you might have a $10000 system for the business unit (with everything included) yet if you don't know why it crashed, you're always nervous about the box. The Linux core team talks about having to get to the enterprise level, and Linux still has a way to go in terms of this, to get to the level of Sun and vendors like that in this respect.

Re:crash dump

[Raleel]

I do not know if it will fit your requirements, but redhat does have solid crash dump support. While it's a little old, http://www.redhat.com/support/wpapers/redhat/netdu mp/ describes it, including it's ability to do crash dumps over the net. A nice feature that comes with the enterprise level versions.

Re:crash dump

[Anonymous Coward]

If by still struggling you mean by, "only being available in every Red Hat (Enterprise) Linux since Red Hat 7.2", perhaps.

There is both netdump (dump to a remote host, via ssh), diskdump (dump to a partition) and the new to be in RHEL5 kdump (which does all kinds of neat things).

and re: debuging tools:

Its not for kids, but check out andersons paper on debugging vmcore files.
http://people.redhat.com/anderson/crash_whitepaper /index.html#toc

I've traced down a few causes of bugs with this, One might argue it might not be as point and clicky as other crash debuggers, but I'd rather have a skilled coder fixing bugs than someone who feels uncomfortable at the commandline.

Re:Red Hat doesn't matter anymore

[weeble]

You might want to consider who paid for writing the kernel.

How much effort was put in to fixing bugs by people paid for by Red Hat.

Software developed by Red Hat includes projects such as Network Manager, Totem etc.

This all costs money and Red Hat funds a lot of development. I do not see Ubuntu on the following list:
Top (kernel) lines changed by employer
(Unknown) 740990 29.5%
Red Hat 361539 14.4%
(None) 239888 9.6%
IBM 200473 8.0%
QLogic 91834 3.7%
Novell 91594 3.6%
Intel 78041 3.1%
MIPS Technologies 58857 2.3%
Nokia 39676 1.6%
SANPeople 36038 1.4%

http://lwn.net/Articles/222773/

boring == good

[heinlein]

RHEL (or, for me, CentOS) is boring. It's not meant to run on the latest gamer PCs or laptops. It doesn't include proprietary video drivers. All it does is serve up bits without interruption: databases, web pages, DNS, DHCP, LDAP, files, login shells. Work gets done. Customers get served. Employees get paid. All without any danger/excitement! Boring is a feature, not a bug.

RH5 Looks good

[LatexBendyMan]

I'm currently testing the RH5 release as we speak. I have to say this has to be one of there strongest releases yet (Network Admins are going to love this). One major difference your all going to notice is the install has changed alot, and the number of packages included in this release (Each package can contain up to 50 sub packages) It probably takes 10 or so minutes just to select all of them. Honestly the GUI hasnt changed much from RH4 or RH3 and I have yet to try out any of the cluster stuff or ISCI, Alot of developer tools in this release! I have to give props to RH on this release!

Re:When is Ubuntu Going to Compete with RedHat?

[jabuzz]

Because Ubuntu does not have a long track record of providing five years of product support. Once you deploy a server in a production enviroment doing OS upgrades is not something to be done lightly, and if it ain't broke I am not about to try fixing it. Knowing I can depend on RedHat to keep my servers secure to the point I will be binning the hardware first is very important.

Re:When is Ubuntu Going to Compete with RedHat?

[hondamankev]

3 words:

Developers
Develop...

wait, wrong thread.

3 words:

Support.
Support.
Support.

Re:When is Ubuntu Going to Compete with RedHat?

[gormanly]

Yep. And s/five/seven =)

Re:Where are the package listings?

[Wdomburg]

Hard to obtain how exactly? Go to ftp.redhat.com, look at a directory listing. RHEL5 isn't up yet, because it's not released, but there have been publicly available beta ISOs for months, so approximate versions are widely known. For example, distro watch has a table listing versions of the major packages.

Comment removed

[account_deleted]

Comment removed based on user account deletion

RHEL(L)?

[arthas]

I use RHEL4 compatible distro called Scientific Linux CERN 4 (SLC4) on my laptop. I need it to run some CERN software (mainly Geant4 and ROOT). These packages mostly work on other systems as well but they work best on SLC4 because they have been thoroughly tested on this platform. On other (newer) distros expecially new GCC4 compiler causes some annoying problems. I really like many things in this distro: stability (both as in "doesn't crash" and "doesn't change insert-name-of-software-package-here version unexpectedly", upgrades generally don't break anything, graphical installation/administration tools are great, etc. etc. etc... There is only one problem: lack of software packages. There is no good way to install new versions of some graphical apps. This is not exclusively Red Hat problem. It exists on all Linux platforms. The problem is that software developers have "works-for-me" attitude: "If I have the latest distro probably everyone else has it too." So they code apps using the latest versions of libraries. Since I use this software on my laptop (which is my primary computer right now) I need both stability of RHEL4 and preferably new desktop software (because new software offers generally better features and usability).

I'm annoyed by this situation because I can't install new tools when I need/want them. This is very inflexible (imagine that: I'm blaming Linux for inflexibility...) The only solution to this problem seems to be virtualization. RHEL 4.5 update (and probably SLC 4.5 as well) is going to have Xen domU support. Maybe it will be then painless to move, say to Fedora 7 or RHEL5 based SLC5 and run SLC4 using virtualization... One can only hope...

Re:Red Hat doesn't matter anymore

[Viol8]

>Kerberos/LDAP integration: If you don't know, this is what will enable SSO capabilities. (aka, what windows did with AD over 7 years ago.)

I think you need to learn your IT history a bit better. Unix has had single sign on capability since NIS (formerly Yellow Pages) was created back in the 80s (I believe version 2 was 1985) and linux has had it since pretty early on in its history. As usual Microsoft were last out of the stalls but made a big song and dance about it and pretended they'd re-invented the wheel yet again.

Re:Red Hat doesn't matter anymore

[walt-sjc]

Dude: work on your reading comprehension.

CentOS, via their Plus repository

Redhat doesn't HAVE a "Plus" repository, which is where CentOS puts recent versions of software for those that require it.

Since I can't get that for ANY price from RH, they actually have LESS value to me.

Here is a real world scenario. I have several racks full of blade servers. The hardware is identical. The configuration is identical. The software loaded is identical. These machines are all clones of each other. If I have a problem with the OS, it will affect all of them, and the fix will fix all of them. If cost of support of one machine is X, and I have N machines, the support cost and effort is not N*X, it's more like 2X. RH wants to charge me N*($Retail-20%) for "support." That's just not reasonable. RHEL is not Windows, and the Windows pricing model doesn't work for it.

Re:Red Hat doesn't matter anymore

[MostAwesomeDude]

I've used Red Hat back when it had to be installed from floppy, and have an FC6 box for dev work on my desk today. (Don't get me too wrong. My fileserver's Gentoo, and the personal laptop I'm on right now is Debian Etch.)

When you say that Red Hat is "greedy," do you mean that they are wrong for selling Linux? After all, people who buy Red Hat's Linux get support, oodles of manuals (good luck getting that brand-new SATA2 RAID card to work in Ubuntu without some arcane incantation halfway through your init (WTF is up with Ubuntu's init anyway? Sure, I appreciate that it's clean and nice-looking, but why is it so damn slow? Even Knoppix CDs boot faster on my friend's dev box than his Ubuntu installation does...)), and they also get a bit of a warranty, which is not something that comes with any flavor of free Linux.

I like Ubuntu much better than Red Hat e.g. package management etc. Yeah, I can't argue with that. Even today, APT still kicks yum out of the water when it comes to being non-buggy and working right. Of course, Ubuntu isn't exactly the best example; they clutter up their repos with an astounding amount of virtual packages.

Also, Ubuntu is nothing like Red Hat in their philosophy. Red Hat sells Linux in order to make a profit. Thus, they work on making their Linux fast, clean, and fully documented, in order to maximize sales. Ubuntu makes Linux in order to promote Linux's desktop share. Thus, they make their distro complete, with out-of-the-box support for proprietary drivers and with oodles of applications. Neither side is perfect: Red Hat's distro is not free if you want the enterprise support, and Ubuntu's distro is bloated and poorly designed for expert users.

Re:The wait is almost over?

[ePhil_One]

There exists a set of people who either use or intend to use RHEL. I imagine a subset of these are the ones likely to be waiting.

Actually, I imagine we'll still be waiting after March 14th. Now that RHEL5 is official, we will start waiting for vendor support, Oracle, EMC, IBM, etc. Making it official is just step 1. People who use RHEL don't rush to update.

The bad news is now my RHCE, earned under RH v8, is officially expired :(

Real-time... for next time?

[Corson]

The article doesn't mention real-time support so I guess RHEL-5 will not include such a feature. That's too bad because Novell already have it in SLERT and can price it as they want.

Re:Er, why didn't you try CentOS?

[Frumious Wombat]

Welcome to the joys of Linux. This is one of the rare times when posting a "So what's the difference between RHEL and Fedora other than $200/yr" to here might have been worthwhile. After you sorted out the responses telling you to compile everything from scratch continually (Gentoo), or use completely free GNU/Linux (Debian), or use completely free GNU/Linux with a tasteful graphical front-end and some thoughts about the end-user (Ubuntu), you would have found that Fedora is a testing version where ideas are tried. RHEL is a much more slowly evolving beast that takes only the pieces from Fedora that are reliable and proven, and then supports them for years. In a way, Fedora is like the old consumer RedHat Linux, except on speed as it tries to keep ahead of the curve with new drivers, interface ideas, cutting-edge software, etc. It's a good choice for personal use, but it doesn't track RHEL closely enough to be used for validation. (I tried for a while to use it as a development system for a RHEL-based cluster, and finally gave up over library dependencies. Fedora rapidly got too far ahead of the cluster libraries, and went unsupported too quickly)

Don't feel bad; it's hard to find a free version of RHEL, though Centos is the current leader. After a while, you understand why vendors support it or SuSE's equivalent. This is one of those cases where sighing and signing the check really would have been the right answer.

RHEL3

[joncombe]

I've not been at all impressed with RHEL. At work we use RHEL3. After an upgrade from RH7.3 we found that the C++ IOStream library was unable to open files >2GB in size. This is an issue with the C++ compiler version supplied with RHEL3. Red Hats' "solution" was that it would be fixed in RHEL4. Sorry, but in a product where support is the primary reason for paying, this is a very poor response.