Red Hat Enterprise Linux 5.4 Released

An anonymous reader writes "The fourth update in the Red Hat Enterprise Linux 5 family is released. From the press release — this version includes kernel-based virtual machine (KVM) virtualization, alongside of Xen virtualization technology. The scalability of the Red Hat virtualization solution has been incremented to support 192 CPUs and 1GB hugepages. Other updates including GCC 4.4 and a new malloc(), clustered, high-availability filesystem to support Microsoft Windows storage needs on Red Hat Enterprise Linux. This article covers the upgrade procedure for RHEL 5.4 from the previous version."

Handy upgrade article

[Anonymous Coward]

Not only is it only the obvious yum upgrade, but it doesn't even work on my RHEL 5.3 box- I get a ton of dependency errors on devel packages which I have to remove first. Fun Fun.

Re:Debian still in the game?

[Darkness404]

The thing about Debian is that its not -meant- for use in enterprise. Its more of a general purpose distro. Yes, your pretty much going to get the same level of reliability if you chose RHEL or Debian stable, but you have to remember that Red Hat has a lot more -paid- people to do all the "boring" tasks that Debian has to rely on volunteers for, so enterprise features are generally first to go into a Red Hat distro.

Re:Oh joy...

[mcrbids]

Now I just have to wait for my office to upgrade, and I'll get to spend another six months in Dependency Hell!

As a LOOOONNNNGGGG time RedHat user, what is this "Dependency Hell" that you speak of?

Rarely, I'll run into a dependency failure when using lots of 3rd party repos. Typically I just try again in a day or two, to find that the 3rd party repo has "caught up" with the main branch and order is restored. And even in this case, I still have a stable system afterward, it's just not updated until the deps are satisfied.

Sorry, but while deps were a royal pain back around RedHat 6.0 or so, since Yum/RHN came along, the deps problem has all but vanished for me. And if you are having deps problems with your 3rd party vendor, you need to look at your 3rd party vendor, not RedHat. If your 3rd party bothers to make RPMS and put up a repo (the latter is astonishingly easy once you get past the "build an RPM" part, which is usually just to use CheckInstall and your standard ./configure && make style packaging) then your deps problems should similarly all-but-disappear.

Methinks your software vendors are lazy.

Re:XFS

[nxtw]

RHEL 5.4 includes XFS support. (It also includes ext4, although I believe this is still a "Technical Preview" and not officially supported.)

Re:Oh joy...

[Anonymous Coward]

I run into dep hell with Fedora quite often where every package includes every possible little feature requiring zillions of packages, but RHEL? rarely.

Hugepages

[ultrabot]

Since it may not be obious to everyone what hugepages are, here's a link that may work out for you:

http://lwn.net/Articles/188056/ [lwn.net]

Re:Python

[Loconut1389]

They're trying not to break API/ABI. They will with RHEL 6.

Re:Debian still in the game?

[bconway]

HP offers paid support for Debian in enterprise environments.

Re:new malloc()

[chill]

glibc new MALLOC behaviour: The upstream glibc has been changed recently to enable higher scalability across many sockets and cores. This is done by assigning threads their own memory pools and by avoiding locking in some situations. The amount of additional memory used for the memory pools (if any) can be controlled using the environment variables MALLOC_ARENA_TEST and MALLOC_ARENA_MAX.
MALLOC_ARENA_TEST specifies that a test for the number of cores is performed once the number of memory pools reaches this value. MALLOC_ARENA_MAX sets the maximum number of memory pools used, regardless of the number of cores.

The glibc in the RHEL 5.4 release has this functionality integrated as a Technology Preview of the upstream malloc. To enable the per-thread memory pools the environment variable MALLOC_PER_THREAD needs to be set in the environment. This environment variable will become obsolete when this new malloc behaviour becomes default in future releases. Users experiencing contention for the malloc resources could try enabling this option.

http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.4/html/Release_Notes/ [redhat.com]
http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.4/html/Technical_Notes/ [redhat.com]

Re:new malloc()

[joib]

Per-thread pools to reduce locking overhead. See the release notes for more details.