Slashdot Mirror
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."
Well actually 2-4 weeks it seems:
https://www.centos.org/modules/newbb/viewtopic.php?topic_id=22004&forum=37
Assuming no devs disappear or go on honeymoon ;-)
#include <sig.h>
Disclaimer:I love Debian's way of doing things; but wonder whether it (Debian) has any answer to what this Redhat release has to offer. Does it?
Debian offers a far wider selection of software backed up by the same reliability level as redhat. But, Redhat is able to feature enterprisey features earlier than other distros because it employs a large number of linux developers.
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.
Taxation is legalized theft, no more, no less.
Start seeding those torrents!
No, wait...
Save your wrists today - switch to Dvorak
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.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
RHEL 5.4 includes XFS support. (It also includes ext4, although I believe this is still a "Technical Preview" and not officially supported.)
I run into dep hell with Fedora quite often where every package includes every possible little feature requiring zillions of packages, but RHEL? rarely.
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/
Save your wrists today - switch to Dvorak
They're trying not to break API/ABI. They will with RHEL 6.
HP offers paid support for Debian in enterprise environments.
Interested in open source engine management for your Subaru?
As a coaster?
Python 2.x as well as 3.x will live alongside 2.4 quite happily. Just build your own RPM and you're golden.
/bin/sh, /bin/bash
/usr/local/python2/bin/python %buildroot/usr/local/bin/python2.6 /usr/local/bin/python2.6 %buildroot/usr/local/bin/python2-latest
Here... have a specfile for 2.6.2 and modify to your own heart's content... (IIRC you have to unpack the tarball, rename the directory to Python-2.6.2, and repack to make this work, but nothing else.)
%define dist %(uname_r=`uname -r | egrep 2.6.9`; if [ "$uname_r" != "" ];then dist_tmp="el4";else dist_tmp="el5";fi ; echo "$dist_tmp")
Summary : Python 2.6.2
Name : Python
Version : 2.6.2
Source : Python-2.6.2.tgz
Release : 1.%{?dist}
Group : Development
Packager : cheile
License : Open Source
AutoReqProv : no
PreReq :
BuildRoot : %{_builddir}/%{name}-root
%description
Python 2.6.2
%prep
rm -rf %buildroot/*
%setup
%build
./configure --with-threads --with-zlib=/usr/include --prefix=/usr/local/python2 --enable-bz2
make
%install
make DESTDIR=$RPM_BUILD_ROOT install
mkdir %buildroot/usr/local/bin/
ln -sf
ln -sf
%files
/usr/local/python2/*
/usr/local/bin/python2*
you could just store everything on /dev/null. It's faster than xfs and only slightly less reliable.
Do you even lift?
These aren't the 'roids you're looking for.
Okay, it's funny and true, yes, but do you guys have to post that comic on every goddamn Linux story?
OMG once you've tried the new malloc, you'll never go back to any "last gen" mallocs because this new one is like the shizzle. Seriously.
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/
http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.4/html/Technical_Notes/
Learning HOW to think is more important than learning WHAT to think.
Per-thread pools to reduce locking overhead. See the release notes for more details.
What exactly is funny about that comic? All I see is an inability to understand who is responsible for what (Linux kernel devs are responsible for Adobe Flash now?), and the fallacy that only one problem can be worked on at a time. Sure, jokes don't usually make much sense under scrutiny, but this comic was never funny, and is just an obvious troll.
*Less* reliable? At least /dev/null willl never lose your zeros.
On a serious note, I've seen XFS fail in a machine that was rebooted normally only once; that is, installed the system on a XFS partition, booted it up, shutdown -r now after 2 months... file system error. No bad blocks on the disk, just fs corruption during normal operation.
Icons with red hats?
http://www.dieblinkenlights.com
How do I point my pirated copy of RHEL toward the CentOS repos so I can update?
Seeing as how CentOS isn't ready yet, they undoubtedly don't have repos set up yet. And when they do, you might as well use CentOS itself.
I like how they circled back to the version numbers of 10 years ago. Ah, the good old days of kernel 2.0.36 and ext2. I remember the joy of getting my sound card working on that: "...and I pronounce Linux, Leenux".