Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Red Hat Software Businesses Linux Business

Red Hat Readies RHEL 5 for March 14 Launch 129

Posted by Hemos from the coming-out dept.
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."
This discussion has been archived. No new comments can be posted.

Red Hat Readies RHEL 5 for March 14 Launch More

Red Hat Readies RHEL 5 for March 14 Launch

Comments Filter:

  • "Enterprise Linux" (Score:5, Funny)

    by EveryNickIsTaken ( 1054794 ) on Tuesday March 06, 2007 @09:41AM (#18249360)
    At some point, one of these Enterprise editions had better have a Starfleet logo on it.

    • Re: (Score:1)

      by armanox ( 826486 )
      I think we can pull that off. We'll take and start replacing the redhat logos with the starfleet insignia. But, it should wait until the version of RHEL is 1701, so that we can call it the USS Enterprise Edition.

    • Re: (Score:1)

      by Ed Avis ( 5917 )
      Unfortunately due to trademark issues with the Starfleet Foundation they had to change the name and logo to 'Barflotilla'.

    • Re: (Score:3, Funny)

      by Brian Stretch ( 5304 ) *
      They're waiting for Intel to develop the exploding plasma conduit components. They got close with the P4.
    • Only if it ships with a phaser set to "dematerialize" in the box. Oh how I longed for one of those when I was a sysadmin, and had to deal with end users. Of course, I would have settled for the much lower-tech, biomaterial-based, Louiseville Slugger, most days.

  • R Hell (Score:2, Interesting)

    by pzs ( 857406 )
    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 bork

    • Re:R Hell (Score:5, Interesting)

      by MartinG ( 52587 ) on Tuesday March 06, 2007 @09:50AM (#18249460) Homepage Journal
      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: (Score:1)

        by pzs ( 857406 )
        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.

        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 packag

        • Re:R Hell (Score:5, Insightful)

          by tobiasly ( 524456 ) on Tuesday March 06, 2007 @10:44AM (#18250054) Homepage

          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.

          • Funny enough, *BSD and pretty much anything that supports pkgsrc, Debian, Ubuntu, Linspire, Freespire all happen to support multiple different versions of different packages within a single "distro". Many support it for FREE.

            Some even allow multiple version installs at the same time as is intended by the software program (multiple gccs, pythons, etc) instead of some single "blessed"/core system version.

            Why do packages have to be vendor locked to the OS release? We don't put up with it with Microsoft's stu

        • Re:R Hell (Score:5, Informative)

          by Wdomburg ( 141264 ) on Tuesday March 06, 2007 @11:02AM (#18250306)
          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 (Score:4, Interesting)

        by Raleel ( 30913 ) on Tuesday March 06, 2007 @10:17AM (#18249750)
        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.
        • I agree with you and Martin. I have run several dozen RHEL2, 3 and 4 boxes in the past. While RHEL isn't my distro of choice, there's not much wrong with it. Debian just does some things slightly better.

          If you color in the lines as far as packages go, RHEL is a remarkably stable OS. Coupled with enterprise support that most PHBs will like, it is a fine arsenal in any sysadmin's cache. Step outside of those lines, and you've defeated the purpose of having a distro with package management, and you might as we

        • Re: (Score:2)

          by div_2n ( 525075 )
          I guess it depends on what you use it for. RHEL4 was in no way acceptable as an enterprise file server in an Active Directory environment IMO. The reference package in the base install is many revisions behind the most current stable (3.0.24). There are bugs present that makes configuring AD authentication support a very rough ride. Not only that, but the behavior is not one I found reliable.

          I am sure version 5 will have much newer packages, but will be woefully outdated in a very short amount of time. With

          • Re: (Score:2)

            by ahodgson ( 74077 )
            I guess it depends on what you use it for. RHEL4 was in no way acceptable as an enterprise file server in an Active Directory environment IM

            The whole point of RHEL is that packages don't change. You can always package your own Samba, though, and update over the core packages. Samba's actually pretty easy to do this with, you can probably just grab a Fedora dev SRPM and recompile it ... a lot easier than a core scripting language. In fact, most applications are easy to package newer versions for and run o

            • Re: (Score:2)

              by div_2n ( 525075 )
              >>> You can always package your own Samba

              And lose support for Samba on that system. Then you must ask--what are you paying for?

        • I use RHEL4 compatible distro called Scientific Linux CERN 4 (SLC4) on my laptop. I need it to run some CERN software (mainly Geant4 [cern.ch] and ROOT [root.cern.ch]). 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

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

        I think it depends on the KIND of stability you are looking for... There is stability in the fact that nothing changes, and there is stability in terms of operational reliability.

        The problem with the former, is that modern third party software tends to be incompatible with ancient versions of software that a

        • Re:R Hell (Score:5, Insightful)

          by d3xt3r ( 527989 ) on Tuesday March 06, 2007 @11:16AM (#18250500)

          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: (Score:2)

          by ahodgson ( 74077 )
          If you need to update core packages that often, you should probably run Fedora.
          • Maybe there'll be a more *BSD-like Linux distro someday that doesn't make the core OS dependent on so many external user level packages, or at least allow core packages to coexist with user-installed packages, such as 2 versions of PHP, or stuff like python as python's native install already supports.

            Some reason, /usr/local | /opt seems very forgotten.
        • If you need php5, compile it. It's not that hard. Hell, you can compile and install an entire LAMP stack from source in under an hour in a non-root home directory as long as you know which modules you need. The LAMP stack changes a lot more than the base OS does, so IMO it's better to compile it yourself no matter which distro you use.
          • Well, for production that is indeed what I have to do. I have to have the entire web stack compiled with all the special features we use, and some very specific versions of libraries. Everything goes in /usr/local. It's a challenge, because there are patches released all the time for one module or another, which frequently requires rebuilding a large chunk of modules due to dependencies.

            That said, people also choose RHEL so they don't HAVE to maintain everything by hand. With CentosPuls containing PHP5, you

    • RHEL is certainly a distro that is aimed at stability rather than the latest features. It is Red Hat's policy that they will not upgrade any package past the minor version that originally shipped with that release. So if it shipped with Python 2.2.3 then it will never go past 2.2.x. They will backport security or stability patches from later releases if necessary.

      If that's not the policy you're looking for in a distro, then RHEL is not the distro for you. That said, I have had lots of luck in compiling SR

    • Re: (Score:2)

      by Jokkey ( 555838 )
      It should be noted that there are third-party projects to add the flexibility and newer versions you want, like CentOS Plus [centos.org] (includes PHP 5, Postgres 8, MySQL 5, and others) and PyVault [python.org] (Python 2.4).
    • Welcome to RPM hell.

      Which is why I switched to Ubuntu and FreeBSD long ago from redhat. The conspiracist in me thinks rpm was invented as a way to keep you on the upgrade trendmill. I spent lots of money in the past upgrading linux distros before I had high speed internet access and could apt-get or use the ports. RPM is truly terrible and yum does not solve anything other than to download some other packages that might be required with it. Upgrading is still a nightmare.

      I guess commercial software vendors

      • Re: (Score:2)

        by ahodgson ( 74077 )
        Upgrading an RPM distro with yum is exactly the same as upgrading Ubuntu. Well, unless you deliberately shoot yourself in the foot by installing RPM's from a different distro.

    • RedHat isn't to blame for your problems.

      We had similar problems. However all you have to do is when you install the newer version of python, do make altinstall instead of a make install. When you need the newer version, you just do /usr/bin/python2.4 when you start your app. Python takes care if it all. Really simple.

      As for your php problem. Remove all of the php rpms and install from source. It does not invalidate your support (at least it hasn't invalidated ours). You can get multiple version of ph

    • Re: (Score:2)

      by Deagol ( 323173 )
      We had an RHEL3 box which had a truly ancient version of Python installed - more than 2 years old.

      While no fan of Redhat (anymore), this is just a lame complaint.

      You know, Solaris and it's commercial brethren didn't always include the open source tools we've come to expect these days.

      Before AIX, Sun, IRIX, etc. all had open source repositories with binaries rolled into the native package format (these days, often provided by the vendor itself!), we admins got along just fine either compiling most sour

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

      If you have some scripts that absolutely got to run with the newer version, then compile your own and put it in /usr/local. That way you don't bork the base system and you can still do what you want in our own little /usr/local sandbox. The only way that would fail is if the newer version is not backwards source-compatible with whatever version of libc RHEL 3 us

    • Usually, you can get away with doing a build from source with some variation of --prefix=/usr/local/pkg, so as to not interfere with the native pkg.

      That's how I ran my newer custom builds of Apache, PHP, MySQL, and OpenSSL under RH7 and RHEL3. It can get a bit tricky with OpenSSL, due to the runtime linker and some libs, but generally thats what /usr/local/ is there for [or at least that's what I have used it for].

      I have not looked into building Python, but as long as you leave the env alone, and specif

  • CentOS 5 (Score:5, Interesting)

    by Nighttime ( 231023 ) on Tuesday March 06, 2007 @09:48AM (#18249440) Homepage Journal
    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. [centos.org]

    • Re:CentOS 5 (Score:5, Interesting)

      by fimbulvetr ( 598306 ) on Tuesday March 06, 2007 @10:30AM (#18249870)
      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.

      • Re: (Score:1, Interesting)

        by Anonymous Coward
        Our server at work came with RedHat but now Runs CentOS (I think our RedHat subscription still has a year or so left), primarily because CentOS has all the goodness of RedHat without RedHat's 'prove your not a crook' and 'is your subscriuption up to date' features.

      • Re: (Score:1, Insightful)

        by Anonymous Coward
        centos rocks

        Thanks god there are people paying for rhel if they can afford it though.
      • Centos has another HUGE advantage over the base RHEL - the CentosPlus repository. With Plus, you can grab php5 without needing to go out and grab srpms from fedora and make all sorts of manual changes to make it work, and building / maintaining your own packages.

        RHEL could gain a LOT more converts and increase value with their own version of Plus. Plus gives you the best of both worlds.

        • Re: (Score:1)

          by perbu ( 624267 )
          Can't you use CentoPlus with RHEL? I though Centos was supposed to be binary compatible with RHEL.

          • Re: (Score:2)

            by ahodgson ( 74077 )
            It would likely break your support contract, which is really the whole reason you run RHEL, isn't it?

            Technically the packages should work fine, though.

  • crash dump (Score:5, Interesting)

    by br00tus ( 528477 ) on Tuesday March 06, 2007 @09:52AM (#18249468)
    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 (Score:4, Informative)

      by Raleel ( 30913 ) on Tuesday March 06, 2007 @10:01AM (#18249566)
      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/ [redhat.com] describes it, including it's ability to do crash dumps over the net. A nice feature that comes with the enterprise level versions.

    • Re: (Score:2, Informative)

      by 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 [redhat.com]

      I've traced down a few causes of bugs with this, One might argue it m

  • Redhat Dominates enterprise (Score:1, Insightful)

    by Anonymous Coward
    Like it or not, Redhat dominates the enterprise corporate and government markets for Linux. RHEL5 is highly anticipated and looked forward to, it has many nice features listed. However, until it is released, any discussion about it is really rhetoric.

    As for being dominant, there is a thing in any industry that if you are the first, its very hard to lose that position. Redhat was first to the commercial sector. Other distributions qualities may rock, but Redhat was still first, and its position in the ma

    • Re: (Score:2)

      by crush ( 19364 )
      Here here. I am eagerly awaiting RHEL5, am currently having fun with Fedora Core7 Test2 and can't see what the point of this product announcement is on Slashdot. I hate posts like this. It's just marketing crap. Any sysadmin that's planning on upgrade is already aware of the issue. Give us something with some more meat.

      • Re: (Score:1)

        by bryguy5 ( 512759 )
        Except for us part time sysadmin's that are wanting for php5 support on a stable server os and would rather just browse through slashdot rather than hitting a dozen other vendor sites for info.

        • Re: (Score:2)

          by crush ( 19364 )
          The CentOSPlus repository has rpms for PHP5 since at least mid-2006. Still I take your point.
  • Is there a listing of the included RPM packages and versions of each? This is something that I find extremely useful, especially when deciding whether I want to upgrade to or use a particular release. Red Hat has historically made this information very hard to obtain, even with their Fedora line. Why is it so hard to just post a listing?

    • Re: (Score:3, Insightful)

      by Wdomburg ( 141264 )
      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 [distrowatch.com] has a table listing versions of the major packages.

  • boring == good (Score:5, Insightful)

    by heinlein ( 17425 ) on Tuesday March 06, 2007 @10:38AM (#18249954) Homepage
    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.

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

    What do they mean by proprietary platforms? Who knew RH was actively going after z/OS, OS/400, VMS, VxWorks, OSX.... what exactly consistutes a proprietary platform? One that only one vendor can create hardware for? Or one that there is only one vendor selling hardware/software/accessories for it?

    • Re: (Score:2)

      by aktzin ( 882293 )

      What do they mean by proprietary platforms? Who knew RH was actively going after z/OS, OS/400, VMS, VxWorks, OSX.... what exactly consistutes a proprietary platform? One that only one vendor can create hardware for? Or one that there is only one vendor selling hardware/software/accessories for it?

      I think by "proprietary" they mean mostly Unix systems from vendors like Sun, IBM and HP. But when it comes to IBM this goes both ways because Red Hat (and SuSE) run on most, if not all, IBM boxen:

      xSeries - I

  • RH5 Looks good (Score:3, Informative)

    by LatexBendyMan ( 989778 ) on Tuesday March 06, 2007 @10:40AM (#18249998)
    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!
  • Pi day! :) I wonder if it will be released at the exact time too?
  • Redhat addreses a problem many Linux distributions have: guaranteed compatibility. I needed Linux to run the FPGA design tools from Xilinx. Xilinx makes their software tools available for Windows, Solaris, and Redhat Enterprise Linux WS 3 and 4. And I learned the hard way why they only support RHEL--every Linux is so different that I had a hard time getting the Xilinx tools to work on Fedora Core 3 even (the Fedora that's most similar to RHEL 4) and gave up and bought RHEL 4. I'm a long-time Unix user,
    • I can't understand why you're trying to get the design tools that are certified against RHEL 3 and 4 to work in Fedora! Why not use CentOS [centos.org]? It's free and is a near-identical clone of RHEL (only differences are any references to Red Hat and its logos, both of which are trademarked). And, yes, you can install binary kernel drivers intended for RHEL onto equivalent CentOS machines without any compatibility issues.
      • Thank you for pointing out Centos.org, but you may have missed the part where I said "I'm not a Linux expert." I just read the CentOS.org website, and let's just say sites pirating movies and music are less cryptic in their intentions. If I hadn't bought RHEL and now recognize the numbering scheme of the versions, I would have had no idea that was RHEL 4 available. A quick google search found an article that said centos.org was asked by Redhat to remove all references to Redhat on the website, which expl

        • Re: (Score:2, Informative)

          by Frumious Wombat ( 845680 )
          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

    • Re: (Score:1)

      by Corson ( 746347 )
      Why did you try the "cutting-edge" Fedora rather than the RHEL clone CentOS?
  • 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.

  • RHEL3 (Score:2, Interesting)

    by joncombe ( 623734 )
    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.

  • For those who are interested here are the release notes [redhat.com]. The technology preview is particularly mouth watering. Personally I'm especially looking forward to GFS2.

Slashdot Top Deals

Sigmund Freud is alleged to have said that in the last analysis the entire field of psychology may reduce to biological electrochemistry.

Close