Slashdot Mirror

← Back to Stories (view on slashdot.org)

Red Hat Enterprise Linux 5.4 Released

Posted by timothy on from the progress-continues dept.

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

110 comments

  1. Linux Distro Flamewar in by TheBilgeRat · · Score: 0

    5...4...3...2...

    1. Re:Linux Distro Flamewar in by Anonymous Coward · · Score: 0

      I use Snow Leopard 10.6

    2. Re:Linux Distro Flamewar in by CannonballHead · · Score: 4, Funny

      As a coaster?

  2. CentOS 5.4 in 3..2..1... by BestNicksRTaken · · Score: 4, Funny

    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>
    1. Re:CentOS 5.4 in 3..2..1... by operator_error · · Score: 2, Funny

      Real Devs don't vacation, OR go on honeymoons.

    2. Re:CentOS 5.4 in 3..2..1... by hansamurai · · Score: 1

      Assuming no devs disappear or go on honeymoon ;-)

      Or "crawl into a hole."

      http://www.centos.org/modules/news/article.php?storyid=381

      --
      Reviewing just the first hour of video games.
    3. Re:CentOS 5.4 in 3..2..1... by pak9rabid · · Score: 1

      I'm looking forward to Oracle Enterprise Linux 5.4!

      *ducks*

    4. Re:CentOS 5.4 in 3..2..1... by cowbutt · · Score: 1

      So no updates for the recently-released CentOS 5.3 for a while either (according to this thread).

    5. Re:CentOS 5.4 in 3..2..1... by Anonymous Coward · · Score: 0

      I'm looking forward to Oracle Enterprise Linux 5.4!

      *ducks*

      Quack.

      Oracle EL 5.4 devs: "We're going as quack as we can!"

  3. Handy upgrade article by Anonymous Coward · · Score: 1, Informative

    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.

    1. Re:Handy upgrade article by Anonymous Coward · · Score: 0

      follow up to self- looks like my RHN subscriptions somehow got reset- I was no longer subscribed to RHEL 5 workstation, but still, that article was useless.

  4. Debian still in the game? by bogaboga · · Score: 1

    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?

    1. Re:Debian still in the game? by whatajoke · · Score: 5, Insightful

      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.

    2. Re:Debian still in the game? by Darkness404 · · Score: 2, Informative

      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.
    3. Re:Debian still in the game? by bconway · · Score: 3, Informative

      HP offers paid support for Debian in enterprise environments.

      --
      Interested in open source engine management for your Subaru?
    4. Re:Debian still in the game? by iYk6 · · Score: 1

      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?

      Exactly what is it that Debian might have an answer to? What does this Red Hat release have to offer that isn't in every other large Linux distro?

    5. Re:Debian still in the game? by Richard+W.M.+Jones · · Score: 1

      Debian offers a far wider selection of software

      and Red Hat supports the software for 7+ years, in the original version, backporting all the nasty security patches to it for you.

      Rich.

      --
      libguestfs - tools for accessing and modifying virtual machine disk images
    6. Re:Debian still in the game? by rbanffy · · Score: 1

      I am sorry to destroy your fantasies, but Debian is used in a lot of enterprises. The only drawback of using Debian is that pointy-haired bosses frequently will be confused because they are unable to write a check for support to a Debian Corporation or something like that and this is not what PHBs are used to do.

      What creates this distorted perception is that Debian tends to appear in companies that give a little more autonomy to the tech areas than Red Hat and those companies don't have the required PHB density to appear in most "corporate IT" magazines.

      That said, I have nothing against Red Hat. It's a fine distro that comes attached to hefty support fees and lots of "enterprisey" features appear in RH before they appear in Debian. And a couple things in RH really suck: For instance, I really love the way Debian organizes the Apache configuration files. I also think Debian's package management is much better than Red Hat's (and that is a critical issue to me - I want the system to be able to update itself with next to no disruption). OTOH, I would have liked Debian a lot more if it weren't for that SSH problem it had a couple years back. Recreating all the keys was not fun.

      --
      http://www.dieblinkenlights.com
    7. Re:Debian still in the game? by Anonymous Coward · · Score: 0

      Red Hat offers one feature that may sound useless to most users, but in corporate environments it means a lot:

      FIPS and Common Critera certification. This means that RedHat took the time and expense to have an independant lab do detailed security analysis on the OS and stick a tag of approval. No, this doesn't mean that it is more secure than other distros per se, but it means that RedHat put their money where their mouth is.

      FIPS certification on apps and operating systems is very important if you are in an environment subject to HIPAA, Sarbanes Oxley, and other regulations. If something happens, you can CYA and point to the OS maker. Without the certifications, the paper trail and CYA ends, and now shareholders now have a chance to sue, and the SEC has the ability to press criminal charges.

    8. Re:Debian still in the game? by rbanffy · · Score: 2, Funny

      Icons with red hats?

      --
      http://www.dieblinkenlights.com
    9. Re:Debian still in the game? by rbanffy · · Score: 1

      Oh... The requirement to reinstall the whole system every time you do a major upgrade (say, from 4 to 5).

      --
      http://www.dieblinkenlights.com
    10. Re:Debian still in the game? by Anonymous Coward · · Score: 0

      Debian could be as fast as Red Hat if they quit wasting so much time arguing about their politics.

    11. Re:Debian still in the game? by jabuzz · · Score: 1

      Lack of a in advanced long term planned update support is one drawback of Debian. Redhat's seven year support offering is very useful. We have only just recently ditched our last RHEL3 boxes, and we have significant numbers of RHEL4 boxes that are not going to be upgraded anytime soon.

      Another is there is very little third party software that supports Debian either. So for example we use IBM's GPFS and TSM extensively. You hackor this onto Debian but don't bother ringing IBM tech support if you have a problem. The same I imagine goes for Oracle or DB2 or SAP or ...

      Don't get me wrong I have been using Debian at home now since 1994, but in a workplace server environment it takes a lot to beat RHEL/CentOS, and for me Debian is not even close.

    12. Re:Debian still in the game? by Anonymous Coward · · Score: 0

      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?

      Exactly what is it that Debian might have an answer to? What does this Red Hat release have to offer that isn't in every other large Linux distro?

      For instance, say you run a nice Pseries box from IBM. You want to use advanced hardware features like Dynamic Logical Partitioning of memory and CPU, or possibly Linux in a Virtual I/O LPAR (maybe even run your Virtual I/O (VIOS) servers on Linux!). Maybe you want to run something like LX86, which allows you to run x86 binaries on the Power architecture. Then you run on Redhat. (or Suse). Mostly Redhat.

    13. Re:Debian still in the game? by Anonymous Coward · · Score: 0

      I'd like to see more data to substantiate this claim. I can't believe that this comment was rated +5, Insightful with absolutely no statements to back up his claim at all. I'm not saying what he's saying is true or false, it's simply unverified and probably doesn't more moderation than a 1.

    14. Re:Debian still in the game? by rbanffy · · Score: 1

      Agreed. The main reasons I see RH boxes around is not RH support but Oracle, IBM and Realmedia. Still, this still amount to a handful of boxes.

      I would fire someone who uses it to serve static HTML.

      --
      http://www.dieblinkenlights.com
    15. Re:Debian still in the game? by turbidostato · · Score: 1

      "Lack of a in advanced long term planned update support is one drawback of Debian."

      Only if you approach with the wrong mentality. Why would you want really long term support when you have no less than a year window for a free and quite easy upgrade?

    16. Re:Debian still in the game? by JonJ · · Score: 1

      If you're inside a support contract you can upgrade to the latest version of RHEL free of charge, so what you do is keep your production boxes running and you setup a test environment with the latest RHEL and MySQL. What's the big deal?

      --
      -- Linux user #369862
    17. Re:Debian still in the game? by jabuzz · · Score: 1

      Why if the majority of your infrastructure is RedHat/CentOS would you install say SuSE or Debian to serve static HTML?

      Personally I would fire someone who did that.

    18. Re:Debian still in the game? by jabuzz · · Score: 1

      But lots of time why would I do that? A DNS server running on say RHEL 4 which is up to date is just as good as the day it was installed. The option to only need to reinstall when the box itself is ditched is in my opinion well worthwhile.

    19. Re:Debian still in the game? by simpz · · Score: 1

      To be honest I can't imagine you've ever had to admin too large a setup. If you have, they must be pretty cookie cuttered e.g maybe a web farm. If you have say 100 machines that a lot of which perform unique functions you'd not want to roll out a new OS release annually, just too much stuff changes/breaks.

      Or else consider you are an enterprise application developer you have to port/repair your app as libs change with a whole new OS release. And you end up supporting all the old OS versions out there as your customers don't or refuse to switch their OS annually.

      In these sorts of environments in businesses you'd never see your home, you'd constantly be repairing broken stuff, that's changed the way it works. I have Fedora on my desktop (to see where RH is going basically, and OK more bleeding edge than Debian) and I'm constantly having to fix stuff the broke with a major release, granted mainly closed source stuff (though not always), but there's a lot of that in business, e.g VMWare, NVIDIA, my sound is screwy at the moment, the NFS server was broken for a while. I'd hate that repeated times 100 odd effecting loads of users. We go through the same pain with a new RH release (though lesser) but at least it doesn't happen very often.

      Nothing against Debian, it's great, but in enterprise space the predictability of a 7 year OS release (and a new version of the OS every few years) is a major boon. But long term support doesn't excite unpaid devs enough for it to really happen in the totally free space.

    20. Re:Debian still in the game? by Bert64 · · Score: 1

      Yes, the primary drawback of RH/Centos is a lack of flexibility (enterprise customers don't want flexibility, they typically have a small number of specific needs)... Flexibility which simply isn't required if you're just planning to serve static HTML.

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    21. Re:Debian still in the game? by jsight · · Score: 1

      Why would you want really long term support when you have no less than a year window for a free and quite easy upgrade?

      The "quite easy upgrade" is often not quite as easy as you make it out to be. Why bother to do that on a box which 100% works already (and still has security patches available for years)?

      --
      Throw the bums out!
    22. Re:Debian still in the game? by jsight · · Score: 1

      Oh... The requirement to reinstall the whole system every time you do a major upgrade (say, from 4 to 5).

      Which OS has that requirement?

      --
      Throw the bums out!
    23. Re:Debian still in the game? by Anonymous Coward · · Score: 0

      People don't want to know about advanced OS features on advanced hardware, they would rather whine about dependencies for another 10 years.

    24. Re:Debian still in the game? by turbidostato · · Score: 1

      "A DNS server running on say RHEL 4 which is up to date is just as good as the day it was installed."

      That's true, but the last version is even better: software is still evolutioning so fast that it's hard not to see advantages aplicable to your environment at each major release (hey! now I can bind registries with LDAP, or hey! the new version supports views the way I need, etc).

    25. Re:Debian still in the game? by turbidostato · · Score: 1

      "To be honest I can't imagine you've ever had to admin too large a setup."

      That's true. The environment I manage is only about 100 servers, 25 of which are more or less the same (web servers JBoss-based while still each one with its own peculiarities). Hardly a "large" setup while still not a "short" one.

      "If you have say 100 machines that a lot of which perform unique functions you'd not want to roll out a new OS release annually, just too much stuff changes/breaks."

      Truly not. But I feel quite on point upgrading (not rolling up anew but just upgrading) each two years and a half if the upgrade goes quite comfortably. And you know what? That's the case since I use Debian.

      "Or else consider you are an enterprise application developer you have to port/repair your app as libs change with a whole new OS release."

      I -well, not "I" but the team at my company, does indeed have to port/repair our apps with each new OS release on Debian. But do you know what? They still have to do it for Red Hat (and SUSE) too. And being forced to work against Debian, SUSE and Red Hat, they feel Debian to be the easy part -or at least so they say.

      "And you end up supporting all the old OS versions out there as your customers don't or refuse to switch their OS annually."

      Debian doesn't move anually but more somewhere between each two/three years. And you know what? Most of our Debian users tend to be on "Debian Stable" whatever it is at the moment, while we still have to support Red Hat 3, 4 and 5 (at some dot releases at each of them -we are so unlucky that Red Hat tends to break our products even at dot releases) and the same goes for SUSE, mainly because our Red Hat (and SUSE)-base users "on't or refuse to switch their OS annually" (which is nothing but due to the "bad mentality" I already stated by the very beginning).

      "I have Fedora on my desktop"

      End of the argument. Whatever you say based on such assertion is completly out of scope (you even agreed to this later on your post).

      "We go through the same pain with a new RH release"

      You lost my point about Debian's "quite easy upgrade path", didn't you?

      Of course Fedora breaks things at each upgrade: it's meant to be that way since is the bleeding edge experiment from Red Hat.

      Of course you want as long as possible release support from Red Hat -ideally the whole life of your computer/service, since experience dictates that you are far better reinstalling and/or redeploying than trying to cleanly upgrade a system from RH 3 to 4 to 5. But that's not the only world you can get: I manage boxes, by the tens no less, out of the about one hundred I manage grand-total, that happily upgraded -even remotely from a different continent, from Woody to Sarge to Etch to Lenny (and some of them probably will be upgraded to Squeeze too, if not already decomissioned, a 2-to-3x factor older than others would say it's sane) with no or little pains at most. That means upgrading from 2001 to date so there you have your seven years period and then a bit more.

      "Nothing against Debian, it's great, but in enterprise space the predictability of a 7 year OS release..." ... is more than surpassed by the stability and open development style (which allows for almost three years release windows for those that care) from Debian.

      That's my fifteen year-span experience. I don't mean to own the ultimate truth but please, don't be too unpleased if I prefer my own *experience* backed opinion to your *wishful* thinking one.

    26. Re:Debian still in the game? by turbidostato · · Score: 1

      "Why bother to do that on a box which 100% works already (and still has security patches available for years)?"

      Because I don't manage a single box and all of a sudden you find that LDAP client from "current -2" doesn't play well with LDAP server from "current", and the same happens with Samba, and Java, and Amanda, and OO.org on the desktop and a dozen of others, so being able to easily upgrade so all (or at least most of) your machines are at the same OS release suddenly becomes a great win even if at the cost (much less than you seem to think, and obviously taken from your experience with Linux distributions that make their day each time you reinstall but that earn nothing from you "just upgrading") of a less than perfect upgrade from time to time (just to show you I'm not just trying to cover the problems, Etch->Lenny upgrade for WikiWiki is one of those "less than perfect" cases -it took me about three ours to tame it on our test environment; and the one for OpenLDAP was too slightly less than perfect -in that it took me about a quarter of an hour to build a proper config file for the new version).

  5. torrents by ultrabot · · Score: 4, Funny

    Start seeding those torrents!

    No, wait...

    --
    Save your wrists today - switch to Dvorak
    1. Re:torrents by StuartHankins · · Score: 0

      Actually this is a great idea. Torrents are a great way to help distribute any Linux distro or other free (as in license) software. It saves the organization money while requiring -- at least for most of us -- no additional costs on our end. Just like last night I downloaded OpenOffice 3.1.1 via torrent instead of using the regular download link. My ratio was > 2:1 this morning when I packed up the laptop to go to work.

    2. Re:torrents by Bootarn · · Score: 1

      Well, RHEL is a commercial product, so unless your organization feels like being criminal, it's not going to work in a legal context.

      It is, however, a good idea in general.

  6. Re:Oh joy... by mcrbids · · Score: 3, Informative

    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.
  7. XFS by LinuxWhore · · Score: 1

    I've got just one question: Does it support XFS yet? We use BackupPC, which generates millions of files, and easily fills an ext3 filesystem with inodes. This is the only thing that's keeping me from switching to RHEL/CentOS from Fedora.

    --

    I am MuchTall
    1. Re:XFS by nxtw · · Score: 2, Informative

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

    2. Re:XFS by Grant+The+Great · · Score: 1

      From the release notes, specifically: http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.4/html/Release_Notes/Filesystems.html yes it does support XFS and FUSE, but they say it's a "technology preview." So who knows what exactly that means.

    3. Re:XFS by Loconut1389 · · Score: 1

      You can always compile it in to your kernel. A college I worked for in the midwest rolled their own. They had their own RHEL repo mirror, and just added it with a slightly higher minor release and kernel-* was in the skiplist to prevent vid drivers from breaking everywhere.

    4. Re:XFS by Cheile · · Score: 1

      For Centos it is already in the CentOS Plus kernel. ( http://wiki.centos.org/AdditionalResources/Repositories/CentOSPlus )

      As others have mentioned it is available in RHEL as a preview which I believe means that it's available but they don't provide official support for it.

    5. Re:XFS by larry+bagina · · Score: 5, Funny

      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.

    6. Re:XFS by chill · · Score: 1

      Considering you linked the Release Notes, *you* should know what "technology preview" means.

      Technology Preview features are currently not supported under Red Hat Enterprise Linux subscription services, may not be functionally complete, and are generally not suitable for production use. However, these features are included as a customer convenience and to provide the feature with wider exposure.

      http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.4/html/Release_Notes/sect-Release_Notes-Technology_Previews.html

      --
      Learning HOW to think is more important than learning WHAT to think.
    7. Re:XFS by DeKO · · Score: 2, Interesting

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

    8. Re:XFS by DeKO · · Score: 1

      Oops, I mixed up /dev/null with /dev/zero. Never mind.

    9. Re:XFS by jabuzz · · Score: 1

      For CentOS 5 (and for that matter puka RedHat), you can get XFS on the vanilla RedHat kernel by installing kmod-xfs from the CentOS extras repository. Though now you don't need that at all.

    10. Re:XFS by drspliff · · Score: 1

      Actually it's infinitely more reliable than XFS, no chance of data corruption or hard disk failure, not to mention the code is so simple it's pretty easy to provide a formal proof that it contains no bugs.

    11. Re:XFS by spydum · · Score: 1

      Why not just mkfs.ext3 -N someAmountOfInodes?

    12. Re:XFS by Anonymous Coward · · Score: 0

      Recompile the kernel and add it yourself?

  8. 'yum update ; reboot'... by Anonymous Coward · · Score: 0

    ... instead of 'apt-get update ; reboot' ? Big deal ...

  9. Re:Oh joy... by Anonymous Coward · · Score: 2, Informative

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

  10. Hugepages by ultrabot · · Score: 4, Informative

    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
  11. Python by Samus · · Score: 1

    I know they strive for package stability and all but Python 2.4 was released in 2005. Can't we get something newer in there please?

    --
    In Republican America phones tap you.
    1. Re:Python by Loconut1389 · · Score: 5, Informative

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

    2. Re:Python by Cheile · · Score: 3, Insightful

      Python 2.x as well as 3.x will live alongside 2.4 quite happily.   Just build your own RPM and you're golden.

      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          : /bin/sh, /bin/bash
      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 /usr/local/python2/bin/python %buildroot/usr/local/bin/python2.6
      ln -sf /usr/local/bin/python2.6 %buildroot/usr/local/bin/python2-latest

      %files
      /usr/local/python2/*
      /usr/local/bin/python2*

    3. Re:Python by pembo13 · · Score: 1

      It sucks, but their position is understandable. Also, Python is fairly easily parallel installable.

      --
      "Thanks for all the money you paid to us. We've used it to buy off ISO among other things" -Microsoft
    4. Re:Python by rbanffy · · Score: 1

      "It sucks, but their position is understandable."

      No.

      I have Python 2.4, 2.5, 2.6 and 3.0 happily living in a Debian box. 2.4 for Zope/Plone, 2.5 because it's there, 2.6 for Django and 3.0 because I can.

      Just get Debian.

      Or Ubuntu. And you can even pay Canonical what you would pay Red Hat.

      --
      http://www.dieblinkenlights.com
    5. Re:Python by rbanffy · · Score: 1

      Can't they just symlink /usr/bin/python to /usr/bin/python2.4?

      Why would Python 3 (or 2.6/2.5) interfere?

      --
      http://www.dieblinkenlights.com
    6. Re:Python by Nimey · · Score: 1

      It's enterprise software with a support contract. You do /nothing/ that could potentially screw something up.

      If you need old RHEL with new Python, you compile it yourself or use a third-party repository, and don't expect support from Redhat.

      --
      Hail Eris, full of mischief...

      E pluribus sanguinem
    7. Re:Python by rbanffy · · Score: 1

      If an upgrade risks screwing something up, you are not doing it in an enterprise-grade fashion. You just don't put all your eggs in the same basket.

      And, as I said somewhere else, if you postpone your upgrades enough you will sure need Red Hat's support when you have to upgrade your mSQL database to MySQL 8.

      --
      http://www.dieblinkenlights.com
    8. Re:Python by gbjbaanb · · Score: 1

      but if you postpone upgrades long enough, you won't be running the current RH version, you'll still be on RH3 (for example). And then, yes, you will have problems upgrading and they'll be worse than if you upgraded every time a new version appeared, but you will have the benefit of your old setup working seamlessly.

      I would say that upgrading a system from MySQL 3 to MySQL 4, and then from 4 to 5, and so on, is only slightly less painful than waiting a few years and doing a big upgrade from 3 to 8 all in one go.

    9. Re:Python by tirnacopu · · Score: 1

      RedHat's support is so expensive, that at current hardware prices I twice chose to buy a new box, install all new stuff on it, migrate the service and throw the old one in the trash. This also offered an almost perfect rollback solution if the transfer went wrong.

  12. Oblig. XKCD by jabithew · · Score: 0, Troll

    The scalability of the Red Hat virtualization solution has been incremented to support 192 CPUs and 1GB hugepages.

    Here.

    Yes, I know an enterprise solution needs good virtualisation more than flash, it's still funny.

    --
    All intents and purposes. Not intensive purposes.
    1. Re:Oblig. XKCD by gbarules2999 · · Score: 2, Insightful

      Okay, it's funny and true, yes, but do you guys have to post that comic on every goddamn Linux story?

    2. Re:Oblig. XKCD by iYk6 · · Score: 3, Insightful

      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.

    3. Re:Oblig. XKCD by rbanffy · · Score: 1

      Real computers don't have ports for keyboards, mice or monitors.

      --
      http://www.dieblinkenlights.com
    4. Re:Oblig. XKCD by Abreu · · Score: 1

      Has it stopped being relevant?

      --
      No sig for the moment.
    5. Re:Oblig. XKCD by Simian+Man · · Score: 1

      The scalability of the Red Hat virtualization solution has been incremented to support 192 CPUs and 1GB hugepages.

      Here.

      Yes, I know an enterprise solution needs good virtualisation more than flash, it's still funny.

      I don't get this comic...I have seamless fullscreen flash (Fedora 11, Firefox 3.5, Flash 10, 64-bit). Do other Linux users seriously not have this???

    6. Re:Oblig. XKCD by Anonymous Coward · · Score: 0

      I don't get this comic...I have seamless fullscreen flash (Fedora 11, Firefox 3.5, Flash 10, 64-bit). Do other Linux users seriously not have this???

      Are you really that naive, assuming every Linux user has the same capabilities you have? There are still poor schmucks out there without SOUND for Christ's sake.

    7. Re:Oblig. XKCD by Anonymous Coward · · Score: 0

      Actually I found it quite funny.

      Yes, I know the kernel devs aren't going to make a better Flash plugin. Yes, I know many of their goals are aimed at enterprise and large scale scientific computing that I'll never deal with. That said, the cartoon isn't a troll, it's an honest critique from an average desktop Linux user's perspective.

      Here's the thing, though. I dont' use 1024 CPUs to get through an average day, so it doesn't annoy me. I do unfortunately have to deal with Flash, and its incessant crashing pisses me off to no end. It seems that there would be a lot more people annoyed by crashing Flash than the fact they can't run a billion CPUs. Yet what do we get? Code to support those billions of CPUs that probably works flawlessly, while Flash goes on pissing me off daily.

      It's just a statement on Linux on the desktop and how it seems to grow, change, and mature. Things that affect hundreds of thousands, if not millions of users on a daily basis never get fixed, while features 99% of us don't give a shit about keep showing up. When viewed as a whole, most of us to who run Linux and X on the desktop can sympathize with XKCD on that one.

    8. Re:Oblig. XKCD by Anonymous Coward · · Score: 0

      What's a matter baby, gonna take cues from someone called pudge_confirmer? That guy has less of a life I do as a professional troll. Don't let a class A douchebag detract from a Class B douche bag. Oh yeah and go back to Mexico you spic. Leave you women though faggot.

    9. Re:Oblig. XKCD by LizardKing · · Score: 1

      What exactly is funny about that comic?

      Not a lot. And in the strips where the author tries to come across as a maths expert he normally fucks up and ends up looking like a knobhead.

    10. Re:Oblig. XKCD by g1zmo · · Score: 1

      And in the strips where the author tries to come across as a maths expert he normally fucks up and ends up looking like a knobhead.

      Examples?

      --
      I have found there are just two ways to go.
      It all comes down to livin' fast or dyin' slow.       -REK, Jr.
    11. Re:Oblig. XKCD by Anonymous Coward · · Score: 0

      Dear douchebag,

      For the last time, I am a Mexican living in Mexico. I do not live, and have never lived, in the USA.

      While I admit I have been trolled into writing this, I will not bite anymore and will ignore you henceforth.

      Have a nice day!

    12. Re:Oblig. XKCD by Anonymous Coward · · Score: 0

      Shut up, dickweed.

    13. Re:Oblig. XKCD by alexborges · · Score: 1

      Furthermore, yes, in Mexico all workers have access to free health care by law. And it works....

      Welcome to the third wo.... nevermind.

      --
      NO SIG
    14. Re:Oblig. XKCD by LizardKing · · Score: 1

      Google it - there's a lot of math blogs out there.

  13. Re:Oh joy... by Culture20 · · Score: 1

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

    I ran into dep hell for the first time on RHEL4 (after years of running RH & Fedora machines) when x86_64 and i386 versions of something both got installed and confused rpm. I haven't seen dep hell in RHEL5 yet.

  14. new malloc() by hey · · Score: 1

    What's the new malloc() do?
    (Yes, I googled it.)

    1. Re:new malloc() by Anonymous Coward · · Score: 2, Funny

      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.

    2. Re:new malloc() by chill · · Score: 2, Informative

      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.
    3. Re:new malloc() by joib · · Score: 2, Informative

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

    4. Re:new malloc() by rbanffy · · Score: 1

      And no other distro has it?

      --
      http://www.dieblinkenlights.com
    5. Re:new malloc() by Trepidity · · Score: 1

      Doesn't look like it at the moment. It's a new feature in glibc 2.10, which isn't yet in Debian (not even unstable, though there's a version in experimental) or in the latest Ubuntu, though it looks like it's in the dev versions of the upcoming late-October Ubuntu release.

      --
      10 PRINT CHR$(205.5+RND(1)); : GOTO 10
    6. Re:new malloc() by rbanffy · · Score: 1

      I assume people who have hundreds of processor cores in one single box has in-house specialists that can integrate this kind of stuff into whatever distro they happen to like.

      --
      http://www.dieblinkenlights.com
    7. Re:new malloc() by GleeBot · · Score: 1

      Actually, it's more likely they're not using the standard library's malloc at all, so there's nothing to integrate. Just -lmy_custom_malloc and off you go.

      Replacing malloc is pretty common among performance fetishists. Back in the good ol' days, almost nobody used the standard library malloc.

    8. Re:new malloc() by GleeBot · · Score: 1

      Oh, and if you really, really care about performance, you don't even do dynamic memory allocation at all. You figure out exactly how much you'll need in advance, do it all in one go, and let the CPUs rip.

    9. Re:new malloc() by Anonymous Coward · · Score: 0

      Fedora 11 has glibc-2.10.

      [root@xxx ~]# rpm -q glibc
      glibc-2.10.1-4.i686
      glibc-2.10.1-4.x86_64

    10. Re:new malloc() by hey · · Score: 1

      Thanks for the info.
      Seems like an improvement that would be very unlikely to have a downside.

  15. CentOS repos in RHEL by Anonymous Coward · · Score: 0

    How do I point my pirated copy of RHEL toward the CentOS repos so I can update?

    1. Re:CentOS repos in RHEL by Simian+Man · · Score: 2, Insightful

      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.

  16. Re:Oh joy... by thule · · Score: 1

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

    That's not "hell!" Hell is when you get into a catch-22 with dependencies. A package that has dependencies that yum resolves for you is exactly how yum is supposed to work.

    Dependency hell is not just for Fedora/Redhat. I have had dependency hell with debian and gentoo.

  17. Re:Oh joy... by StuartHankins · · Score: 1

    Mod parent up. I've been using RedHat in some form since 5.2, and we use RHEL3, RHEL5, Fedora 8, and Fedora 11 in our company. (We use so many versions because it usually isn't important enough to switch from say Fedora 8 to 11 for a fileserver, but our mission-critical stuff is always on the latest and greatest. I will be scheduling the update to RHEL 5.4 within the next month.)

    I *have* seen problems when someone ran up2date/yum for every package at once from a fresh install of Fedora 8 (ok I admit it, it was me, I wanted to see what would happen). You are asking for trouble if you just haphazardly do that on Fedora or any other cutting-edge distro. Update a few packages at a time, run it for a few days to make sure nothing unexpected happened, then apply the patches in groups. It's common sense really -- if you update 150 packages at once you're bound to find something that doesn't update as expected. Sometimes that's as simple as a change in a config file. But as far as RHEL goes, it's stable. We've gone down twice, once from a thermal failure, and once from someone trying to hot-plug an external MSA30 (just coz it has hot-pluggable drives doesn't mean the whole damn thing is hot-pluggable).

    What you pay for is really good support when you need it, just a phone call away. We've had to call 3 or 4 times in 5 years (for how-to's) and they were great. The packages may be a year or so behind (for instance Samba is on the 3.0x series right now whereas the current is 3.3x and beta 3.4x is out) but the stuff is really really stable. No surprises, that's what I like.

  18. Re:Oh joy... by Nimey · · Score: 1

    I've never had those kinds of dependency problems with Debian. One simple "sudo aptitude update && sudo aptitude safe-upgrade" and some time, and I've got the latest.

    OTOH Debian is usually farther behind than Fedora or RHEL.

    --
    Hail Eris, full of mischief...

    E pluribus sanguinem
  19. shameless promotion by Anonymous Coward · · Score: 0

    "This article covers the upgrade procedure for RHEL 5.4 from the previous version."

    Since that article basically consists of "yum update", you've got to wonder if the "anonymous reader" owns the site, and just got a healthy traffic influx

  20. At least its more uptodate. by Anonymous Coward · · Score: 1, Funny

    I downloaded RedHat 5.4 and the think still has a 2.0 kernel and what XFree86 3. Where'd everyone get theirs, Doc Brown?? Plz don't wrap your responses around rocks and throw them at my glass house on the lake.

    1. Re:At least its more uptodate. by armanox · · Score: 1

      You downloaded Red Hat Linux 5.x, not Red Hat Enterprise Linux 5.x. Big difference.

      --
      I'm starting to think GNU is the problem with "GNU/Linux" these days.
  21. Re:Oh joy... by Bert64 · · Score: 1

    What you're thinking of is dependency bloat, which is pretty unavoidable with binary packages... You either compile support for everything in, and create lots of dependencies, or you compile support for nothing optional and make the packages useless for many users.

    Typically enterprise users care very little about efficiency or flexibility, it is not uncommon to see a quad core server with a complete install of RHEL (including all the X11 gui stuff) on a massive hardware raid array, doing nothing but running bind etc.

    --
    http://spamdecoy.net - free throwaway anonymous email - avoid spam!
  22. Version 5? But I still use Red Hat 5.2.. by Morky · · Score: 2, Funny

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

    1. Re:Version 5? But I still use Red Hat 5.2.. by Anonymous Coward · · Score: 0

      I made a VMware image with Red Hat Linux 6.2 and I'm amazed how often it *still* gets downloaded. Sometimes I think people are confusing it with Red Hat Enterprise Linux 6 but that doesn't seem to be the case.