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.
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.
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.
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.