Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×
Red Hat Software Businesses Linux Business Perl Programming

Bitten By the Red Hat Perl Bug 234

snydeq writes "Smart coders always optimize the slowest thing. But what if 'the slowest thing' is the code supplied by your vendor? That was exactly the situation Vipul Ved Prakash discovered when he tinkered with a company Linux box on which Perl code was running at least 100 times slower than expected. The code, he found, was running on CentOS Linux, using Perl packages built by Red Hat. So Prakash got rid of the Perl executable that came with CentOS, compiled a new one from stock, and the bug disappeared. 'What's more disturbing,' McAllister writes, 'is that this Red Hat Perl performance issue is a known bug,' first documented in 2006 on Red Hat's own Bugzilla database. Folks affected by the current bug have two options: sit tight, or compile the Perl interpreter from source — effectively waiving your support contract. If a Linux vendor can't provide comprehensive maintenance and support for the open source software projects you depend on, McAllister asks, who ever will?"
This discussion has been archived. No new comments can be posted.

Bitten By the Red Hat Perl Bug

Comments Filter:
  • by dougmc ( 70836 ) <dougmc+slashdot@frenzied.us> on Friday August 29, 2008 @11:39AM (#24795595) Homepage

    Installing your own perl under /usr/local, leaving the system one alone under /usr, that waives your support contract?

    Seems unlikely, and if actually true, remarkably stupid.

    (However, messing with the perl under /usr, that would be a mistake. It could easily break other things that depended on that specific version ...)

    • by Richard_at_work ( 517087 ) <richardpriceNO@SPAMgmail.com> on Friday August 29, 2008 @11:55AM (#24795875)
      No, it doesn't waive your support contract, but it does mean you will be relying on a subsystem that is not supported by the vendor - which validates the 'effectively' modifier in the original statement.
      • by no1home ( 1271260 ) on Friday August 29, 2008 @12:55PM (#24797003)

        Very true. And this has been an ongoing issue with Linux adoption... I have a friend who runs mega-million-dollar, mission-critical systems and they've had to move off of Linux in favor of (Sun? Don't remember right now). It isn't about functionality. It isn't about open source. It's about support. Red Hat, et. al. want to be enterprise systems, and claim to offer enterprise support. But they don't perform enterprise support. As indicated here, change something to fix a bug, and you don't get support for that piece anymore. More, they won't support a system that doesn't have the latest updates, which is a problem on mission-critical systems. We don't update needlessly, and we certainly don't update to 'today's' patch. We have to wait and be sure the patch is stable and provides an improvement without risking our mission.

        Until the players selling support realize all of this, Linux will be a difficult sell for such key systems (and the PHBs all think ALL their systems are mission-critical).

        Keep in mind, I say this lovingly.... I want Linux to succeed and prefer it over the popular alternative.

        • by /ASCII ( 86998 ) on Friday August 29, 2008 @01:19PM (#24797387) Homepage

          The company I work for does support for any Linux distribution, custom compiled packages, whatever. If the customer uses non-standard packages and oddball solutions, it often takes more time to solve their problems, but since we work by the hours, that's their problem.

          I find it hard to believe that businesses such as ours are unusual.

        • by KaZen ( 25922 ) on Friday August 29, 2008 @01:19PM (#24797397) Homepage

          This is nearly opposite my experience. I'm working at a very large Wall Street firm.

          Red Hat does *not* tell us: "Oh, I'm sorry you're not running the latest support pack, no support for you."

          We've had to run a modified GCC for a while and Red Hat, *again* didn't say "You've changed it, so support for you." What they *did* say was, "Can you reproduce this on *our* gcc?" Which again is better than We've gotten from some other vendors.

          We're still running AS4U4 in some places and RH has worked with us to track down bugs. Sometimes it ends with: "This was fixed in 4.5 please update." Sometimes it ends with "This is a bug, and here is the HF, please update to the released version when it becomes available."

          In fact I have a hard time sometimes of getting our Admins to open tickes with the *right* vendor, because they'd rather open a ticket with RH, because it gets solved sooner. (Course that is more a dig on HP, Veritas, EMC and some other "Enterprise Software" companies.)

          Unfortunately for Both us and RH, we don't like to update either, and even when RH has proven an update solves the problem, it's hard to get the Admins to actually update the boxen.

          • Re: (Score:3, Interesting)

            by Znork ( 31774 )

            Red Hat does *not* tell us: "Oh, I'm sorry you're not running the latest support pack, no support for you."

            I've found it's more likely that _I'm_ telling customers that we should patch to fix problems they have with Redhat systems than Redhat telling me.

            We're still running AS4U4

            Heh, we have some AS4U2 systems, with only selected patches applied. I suspect some customers have used software from 'enterprise' vendors who don't have quite as strict don't-break-stuff policies with their updates. I can sympathize

        • Re: (Score:3, Insightful)

          by DittoBox ( 978894 )

          Interesting. The entire reason we like Open Source is because we can change the code and fix bugs and make our lives better without being explicitly tied down to a vendor. But when I sign up with a vendor to provide support with things like this, I'm not able to fix those problems and worse off neither is the company that I signed up with.

          What's the point then?

        • by Grimwiz ( 28623 ) on Friday August 29, 2008 @01:44PM (#24797807) Homepage

          My experiences are the opposite to that listed above. RedHat have been more forgiving and sensible supporting live production systems than my experiences from SUN or Veritas. Both experiences were for mega billion-dollar companies.

        • Re: (Score:3, Insightful)

          by Kjella ( 173770 )

          Well, what do you expect? The whole thing is about a CentOS user complaining about how Red Hat is doing a poor job supporting RHEL. What do you know, if he and others actually paid Red Hat for support instead maybe they'd have money to actually do support. Everybody wants something for free, but then deal with what you're getting. Under the GPL he and CentOS is free to leech off what Red Hat is doing but they're basicly bitching their free support isn't good enough. You think I should go on the LKML and bit

      • Re: (Score:3, Interesting)

        by Yahma ( 1004476 )
        The fact he's using CentOS already implies he doesn't have a support contract from RedHat. So what's the big deal?
    • Re: (Score:2, Interesting)

      by corbettw ( 214229 )

      It does on any issues that crop up in the applications using the locally compiled Perl. What's so stupid about a vendor not supporting something you compiled yourself?

    • by Dolda2000 ( 759023 ) <fredrik@@@dolda2000...com> on Friday August 29, 2008 @11:58AM (#24795915) Homepage
      Even if it is true, the nice thing with a free operating system is that one can at least fix the bug oneself, support contracts voided or not. Try doing the same if there's a problem with Exchange or IIS.
      • Perl is not an operating system and is open sourced no matter the operating system you choose to run it on.

        Open source zealotry does not apply to the issue at hand.

        A better question is are you getting your money's worth from Red Hat's support? The distribution being open sourced doesn't relieve Red Hat from the responsibility of fixing an issue contained within their product that an end user is paying for.

      • In this case, the moral of the story is that this wouldn't have happened with Exchange or IIS, because there is no middle-man that could mess with their code.
      • If you were stuck with a closed OS like AIX, HPUX or Solaris you would still have the option of compiling perl from source.

        The nice thing is that the _app_, not OS, is free and thus he has the option of picking another way of working around the issue.

        That said, if this was a kernel issue, he would have no choice but to compile a new one in and totally void his support contract. Yes, he would have the option of doing it but then he loses the "support" that he paid for.

  • Who uses vendor Perl? It's like GCJ; if you don't really need it, it's good enough, but if you really need it, you download the real thing. And like java, it's easy to have multiple versions of Perl on your system.

    I guess that's snarky, but seriously. These guys were running a fancy production package on the crap perl install that comes with Fedora? They needed performance (and chose perl?) and they didn't look first at compiling perl from source? It doesn't take long at all, and the benefits are substantia

    • by timster ( 32400 ) on Friday August 29, 2008 @11:48AM (#24795767)

      Well, I'm anything but a hardcore Perl hacker -- just use it to pragmatically list some rubbish now and then -- and I've never even heard of compiling your own Perl.

      In truth, it's NOT like GCJ in the least. GCJ is a relatively immature JVM built from an entirely different codebase than the Sun JVM. "Vendor" Perl and "real" Perl ought to be substantially the same thing.

      Just like all the foundation-level vendor tools, I would expect Perl to be built correctly on any official distro release. I shouldn't need to build my own GCC, my own Python, my own X, or my own Perl.

      • by SatanicPuppy ( 611928 ) * <Satanicpuppy @ g m ail.com> on Friday August 29, 2008 @12:03PM (#24796027) Journal

        Well, I am harder core than the average schmo where Perl is concerned, so for me it's a requirement...The vendor version is always inferior. Most forums will tell you the same thing.

        But like I said, if you don't really need it, it's fine. I doubt the average user would ever run into this problem.

        • by amorsen ( 7485 ) <benny+slashdot@amorsen.dk> on Friday August 29, 2008 @12:49PM (#24796901)

          The vendor version is always inferior.

          The vendor version in this case has a bug fixed. The bug caused incorrect behaviour. In this case the vendor version is only inferior if you prefer fast but incorrect results. There isn't anything wrong with preferring fast incorrect results over slow correct results, but most people probably want slow and correct to be the default if given the choice.

          Fast and correct always wins, and the real Perl hackers are working on that. In the meantime we take what we can get.

          • by chromatic ( 9471 ) on Friday August 29, 2008 @01:32PM (#24797577) Homepage

            Fast and correct always wins, and the real Perl hackers are working on that.

            No released version of Perl ever had this bug. Red Hat pulled a patch from a development version of Perl and maintained it over released versions of Perl which did not need it. That's the source of this bug. The Perl developers fixed this bug before releasing the next stable version of Perl.

          • by jc42 ( 318812 ) on Friday August 29, 2008 @02:11PM (#24798169) Homepage Journal

            There isn't anything wrong with preferring fast incorrect results over slow correct results, but most people probably want slow and correct to be the default if given the choice.

            Well, I'd be a bit careful about making such general statements. There is evidence that people aren't generally that intelligent.

            I remember back in the 1970s, when I was at a large university that shall remain unnamed, and a bunch of CS people did a detailed study of the Fortran that accounted for fully half the runs on the campus's central mainframe (which shall also remain unnamed). They found that fully half the runs produced at least some incorrect output due to undetected integer overflows. The hardware gave interrupts for floating-point overflows, but for integers, it just set a flag bit, and you needed to test that flag to catch overflows. The compiler had an option to generate such tests, but it was off by default. The vendor said they did this because they had found that most customers preferred faster code.

            The local gang didn't believe this, so they did a bit of a survey. They asked lots of users of the Fortran code whether they would prefer their programs to catch all arithmetic errors if this meant that the code ran slower, or if they would prefer faster code that sometimes didn't catch errors. Roughly 90% of the people they asked this said that they'd want the faster code. Later on, I ran across references to similar tests at other schools, with similar results.

            Personally, I was shocked by this. This mainframe was used to do the computing for most of the scientific work on campus, and scientific computing was almost entirely done in Fortran. So half their data runs had undetected incorrect output. They now knew this, and they still preferred the faster speed to correct output.

            Somehow, I suspect that this situation hasn't changed. I've dug into various programming languages since then, to learn how they handle this and other potential sources of erroneous results. Most current languages still ignore things like overflow flags by default. Some have no way of enabling the tests of such flags.

            Yes, I know lots of ways of explicitly testing for such errors myself. I've done it a lot, because I know I can't rely on others to enable the builtin tests (when they exist) when they recompile the code. But when looking at other people's code, I almost never see anything that will detect overflows. When you're N levels deep in function calls, you usually have no way of verifying the possible range of the current function's args, so there's no way of proving that an overflow can't happen.

            Sometimes I'm amazed that our systems run as well as they do, given this sort of nonchalant attitude towards known sources of hardware errors. And I do a lot of paranoid, defensive programming, even though I know that my employers probably don't want it because it slows down the software.

          • by Karellen ( 104380 ) on Friday August 29, 2008 @04:57PM (#24801093) Homepage

            Reminds me something I heard a wise hacker say once, when someone tried to convince him that their new version of some code was better that his, because it ran in 10% of the time his did but produced (slightly) wrong results in a few cases...

            "If it doesn't have to produce correct results, I can make my version use no memory and run in zero time."

        • by jd ( 1658 ) <<imipak> <at> <yahoo.com>> on Friday August 29, 2008 @12:50PM (#24796903) Homepage Journal

          In general, that could be said of (almost) every single software package of any substance. If you want it to run well, you have got to roll your own. Well, almost. In theory, there's nothing to stop a vendor with a decent server farm gathering your system info then compiling the RPMs for you for that specific system, and/or having a set of stock ISOs rolled for, say, the five most-popular systems.

          A central build has the advantage over something like Gentoo in that vendors can usually afford better horsepower and can auto-tune the options per application better than the average Joe could ever hand-tune them. It's also more supportable, as the vendor then has the exact information for each package, as they would have had they rolled the RPMs from their own default configurations, which a totally user-defined setup would deprive them of.

          There's also the dependency hell and the namespace clash that "standard" distros suffer from all the time. I've never come across a distribution YET that supplies stock binaries that is capable of supplying ones that actually work together. First rule, guys, is that if package A is rebuilt, ALL packages in which A is directly or indirectly a dependency should automatically be rebuilt. It should not be possible, using JUST the stable packages (DEB or RPM), to get into a situation where packages barf or cannot resolve their own dependency requirements.

          (I won't even get into the issue of broken packages in the stable updates, where you cannot complete an install or a deinstall because the flippin' scripts don't work and don't cleanly handle the case where something breaks, effectively barfing over the disk and the package database.)

          The more I use Linux, the more I am convinced that the distros out there are operating on a flawed assumption. They work great, but only when that assumption holds true, but will catastrophically fail outside of those bounds. This assumption is that people will use the distro with a relatively narrow aim on relatively generic systems.

      • Re: (Score:3, Funny)

        by jc42 ( 318812 )

        Well, I'm anything but a hardcore Perl hacker -- just use it to pragmatically list some rubbish now and then -- and I've never even heard of compiling your own Perl.

        You certainly don't qualify as a perl hacker! NTTAWWT. ;-)

        From the very beginning, the primary (and recommended) way to get perl has been to download the source and compile it yourself. It's true that most unix/linux distros have included perl for a decade or so, and of course it's usually not the current version. But this is only a minor tim

        • by Christian Smith ( 3497 ) on Friday August 29, 2008 @12:49PM (#24796889) Homepage

          ... so it's easy to see how someone might be lazy and just use whatever the vendor supplies.

          Wow, I wouldn't want you managing my servers.

          Home compiled software can easily be a source of security holes, as tracking what you have compiled versus what is patched using vendor updates adds significant management overhead and another point of failure. As an example, a popular open source project had its website compromised because the maintainer used a self compiled version of CVS, and forgot about it. Had the maintainer used a vendor CVS, the security hole would have been patched by the vendor update.

          Lazy is good. If you can do the job and be lazy, that is a win-win.

          I wonder what went wrong with the RH release?

          The RH bugzilla ticket indicates this as the initial issue.

          So it appears RH have not applied this fix, perhaps because the patch is included with a more cutting edge perl than is considered safe for inclusion with RHEL. Certainly, it looks like it was fixed in perl 5.9, but that may be an experimental branch more akin to the old 2.[135] linux kernels (and no vendor would have touched them in an enterprise targeted distribution.)

          • Re: (Score:3, Insightful)

            by ppanon ( 16583 )
            A bunch of administrative scripts in Redhat are written in perl and python. Don't know if it's still the case, but a few years ago, it used to be that if your upgraded to the version from the next major release, some of them would break. So you could live with the current state of things, or you could rev the O/S. It's called stability through configuration management. Sometimes it's a bit frustrating, but in 99% of cases, it's a win.
          • by jc42 ( 318812 )

            Wow, I wouldn't want you managing my servers.

            Home compiled software can easily be a source of security holes, as tracking what you have compiled versus what is patched using vendor updates adds significant management overhead and another point of failure.

            Funny; pretty much all my past employers have had the opposite policy: Anything of importance, especially customer-facing servers, are rarely or never automatically upgraded from vendors' releases. They all seem to have learned this lesson the hard way, f

      • Re: (Score:3, Insightful)

        by rgviza ( 1303161 )

        > and I've never even heard of compiling your own Perl.

        I've been doing this for a very long time, in addition to compiling my own php, apache etc.

        If it's exposed, I compile it. If a 0day hits, I don't have the luxury of leaving the fate of my production security in some vendor's hands.

        At the negligence trial, where I'm being prosecuted because my box got pwned, the plaintiff's attorney is going to ask why I didn't fix it if I could. I can, so I do.

        If you are moving from packages to compiled stuff, it ta

    • Re: (Score:3, Interesting)

      I don't care what language you choose, 100x slower is going to make you want to fix the problem.

      However, I agree with your analysis that with something that's mission critical, you need to have the flexibility to compile and maintain the program yourself instead of relying on the vendor. In my view, you get the support contract for the things that aren't central to the business and you don't have 15+ people hired for.
      • by Bill_the_Engineer ( 772575 ) on Friday August 29, 2008 @01:06PM (#24797217)

        In my view, you get the support contract for the things that aren't central to the business and you don't have 15+ people hired for.

        I disagree. You pay Red Hat to provide a baseline server with all of the provided applications and languages. You pay Red Hat to provide timely updates for their distribution.

        You pay your 15+ staff to work on a custom application that may depend on something Red Hat provides.

        Now you may need to custom compile something as a short-term solution, but if Red Hat can't do something as simple as keeping their Perl interpreter working correctly I would seriously reconsider paying them any more money.

        Think about it. If your paid staff has to make a custom compilation of a vendor supplied application (and consequently keep it updated) then what are you paying Red Hat for? The days of paying Red Hat out of the goodness of our hearts are over. It's time for Red Hat to act like one of the big boys and earn their money.

    • Well the reason to want to use vendor perl is that perl does some very fancy file management stuff that makes it extremely fast for opening and closing files. So one presume a vendor could optimize this to their kernel.

      My guess here is that this is just the recurrence of the UTF-8/16 bug.

      Grep and Sort on unix set to UTF-8/16 as opposed to LANG = C (or Posix) are about three orders of magnitude slower on large files. (No I'm not exagerating). Recently this Bug showed up once again on the Leopard on mac.


      • by goombah99 ( 560566 ) on Friday August 29, 2008 @11:58AM (#24795929)

        here's an example of this on a mac OS 10.5
        perl -we 'for (0..1000000) { print rand(1),"\n"}' > /tmp/foo

        time sort /tmp/foo
          real 0m36.169s
          user 0m35.731s
          sys 0m0.264s

        echo $LANG

        setenv LANG C

        time sort /tmp/foo > /tmp/foo2
        0.966u 0.201s 0:01.27 91.3%

        SO for a small file it's 40 times faster when not defaulting to UTF-8

        Perl on leopard however appears to assume LANG=C bey default and is quite fast. As is grep.

        • by jc42 ( 318812 )

          Hmmm ... I tried that example on my Mac running 10.4.11 and perl 5.8.6, and the two sort times differed only by 1 in the third decimal place.

          Maybe I should update the perl on that machine and try it again.

    • Re: (Score:3, Interesting)

      by Ed Avis ( 5917 )

      I always use the vendor perl on Fedora. Why should I pretend that I am cleverer than the people who did the work to package perl for my distribution? And this particular bug does not change my view of the our relative intelligence.

      There's also the issue of using rpm to maintain your system, which like many good habits is a bit of a pain at first but soon becomes indispensible. Even when I wanted to upgrade perl to 5.10 (with Fedora 8, since 9 wasn't out yet), I preferred to build 5.10 as an RPM based on

    • ...why? (Score:3, Insightful)

      by XanC ( 644172 )

      Can you be specific about how the vendor compiling Perl is inherently worse than anyone else doing so?

      This is what distributions are for: to package and/or compile software so that users don't have to. What makes Perl so special that it's suddenly "inferior" when handled that way?

  • by stjobe ( 78285 ) on Friday August 29, 2008 @11:41AM (#24795631) Homepage

    Yeah, well, good on mr Prakash I guess. Good thing he had the option of rebuilding from source, I can think of a few other operating systems and applications where that simply isn't an option.

    So, score one for open source I guess, headline be damned.

    • So, score one for open source I guess, headline be damned.

      OK, you win a point for open source, but only if you promise to criticise everyone who ever writes a snarky one-liner about how wonderful the Linux world is compared to any alternative platform because you can just "{package manager} {get command} {package name}".

      Oh, and if you explain how all the companies forming behind major OSS projects like Linux are actually doing anything valuable in exchange for the money they get paid if they can't even provide robust support for the packages concerned and a high q

      • Re: (Score:3, Informative)

        OK, you win a point for open source, but only if you promise to criticise everyone who ever writes a snarky one-liner about how wonderful the Linux world is compared to any alternative platform because you can just "{package manager} {get command} {package name}".

        Why are those benifits mutually exclusive?

        Over 99% of the time you can install common software with a single apt/yum command and have it work perfectly. Occasionally, when a packaging mistake is made, it's reasonably straightforward for an expert

    • Let's see him rebuild VBscript or C# from source to get his speed up.

      This is what open source is about.

  • by SirGarlon ( 845873 ) on Friday August 29, 2008 @11:41AM (#24795637)
    Just because Red Hat made one high-profile mistake, doesn't mean their support service is without value. Jump to conclusions much?
    • by canUbeleiveIT ( 787307 ) on Friday August 29, 2008 @12:00PM (#24795969)
      Just because Red Hat made one high-profile mistake, doesn't mean their support service is without value.

      Perhaps not, but I know that they will never get another dime of my money.

      For years, I always purchased Red Hat even though I never had occasion to use the support that came with it. I was (and still am) bought into the FOSS concept and wanted to make it work for me and my business. But I stopped sending RH my money sometime about 8.0, when I called their support to try and get some help with a printer issue. I would have been satisfied if they had been able to get either one of my printers (HP LaserJet 1100 or LaserJet 4L) to work with RH. A surly woman with almost unrecognizable English--obviously reading off of a cue card--tried for a few minutes and then dismissed my support case with the comment that "RedHat doesn't work with all printers." When I mentioned that I had paid for the RedHat just so that I could have support, she hung up on me. I called back to get another support person with an equally incompetent and rude tech.

      Eventually, someone at experts-exchange.com gave me the answer to my problem. Now I just download Centos and if I need support, I pay someone on a case-by-case basis.
    • by porkThreeWays ( 895269 ) on Friday August 29, 2008 @12:00PM (#24795987)
      It's a jump to conclusions mat!
    • Just because Red Hat made one high-profile mistake, doesn't mean their support service is without value. Jump to conclusions much?

      That's not the point. The point is that 1) Red Hat won't fix it, and 2) if you fix it yourself, you invalidate your service contract.

      There appear to be workarounds as mentioned, but it shouldn't come to that.

  • by Anonymous Coward on Friday August 29, 2008 @11:46AM (#24795725)

    If it is "supplied by CentOS" then it was compiled by "CentOS" not Red Hat. Red Hat Enterprise Linux enterprise had a hotfix for this weeks ago. So if Vipul had been using a Red Hat product, he would not have had this problem.

    • by Anonymous Coward on Friday August 29, 2008 @11:58AM (#24795917)

      And recompiling doesn't invalidate his support contract; as a CentOS user he doesn't have one.

      The summary is bullshit.

    • Re: (Score:2, Informative)

      by ccharles ( 799761 )
      I'm fairly certain that Red Hat has not yet released an official fix for this. Also, the bug has been in their Bugzilla for almost a year now. Even if they had released a fix "weeks ago", it would be far too late.
    • by SuperBanana ( 662181 ) on Friday August 29, 2008 @12:18PM (#24796307)
      Every time Redhat releases a hotfix, CentOS grabs the source and compiles it. They use the exact same toolchain to compile the exact same source. The only difference between a redhat package and a CentOS package is that CentOS has replaced "Redhat" everywhere, because Redhat started using trademark law to keep them from doing what the GPL entitled them to do (it got so bad that at one point, Redhat was threatening CentOS over even mentioning Redhat on their website.)

      Let's keep our eye on the ball, here: this is a known bug, in Redhat's bug tracker, since 2006. Fixes have been commonplace since 2007, and only just now did Redhat get around to fixing the problem. The question remains: what good is Redhat over CentOS (the only difference being logos and a support contract) if they ignore a major performance bug for two years?

      • The GPL does not invalidate Trademarks. Red Hat owns the trademarks in question and was well within their rights to ensure it is used the way they wanted it to be used. At no point did Red Hat try to use trade mark law to keep the CentOS project "from doing what the GPL entitled them to do." In fact, RH goes out of its way to make repackaging RHEL much easier. They are not required to release source RPMs, but they do anyway. Red Hat just doesn't want you identifying your recreated distro as RHEL.
      • "Redhat started using trademark law to keep them from doing what the GPL entitled them to do"

        This is a serious attack. Frankly, I cannot accept it at face value without your backing it up. Can you explain how Redhat was violating the GPL?

        Just because all the code is GPLed doesn't mean that every bit on the distro disk is GPLed.

      • I use both RHEL and CentOS. RHEL is on our production machines and CentOS is what I use for proof-of-concept and non-production machines. RedHat fixes show up a few weeks before CentOS, though I do often just rebuild the SRPM directly on CentOS. Never had a problem building the source RPM either.

        CentOS doesn't do the same thing as RedHat. They take RH packages and rebuild them without modification except for vendor tags. Though they do maintain their own bug lists, it's RedHat that does the heavy lifting.

    • If it is "supplied by CentOS" then it was compiled by "CentOS" not Red Hat. Red Hat Enterprise Linux enterprise had a hotfix for this weeks ago. So if Vipul had been using a Red Hat product, he would not have had this problem.

      A hotfix weeks ago for a problem that's been there since 2006? So he would have had the problem only slightly less longer than he did. Let's face it, redhat dropped the ball on this one.

  • by russotto ( 537200 ) on Friday August 29, 2008 @11:46AM (#24795729) Journal

    ...then what good is the support contract anyway? Either stop paying for it or make enough of a stink that they fix it. Of course, RedHat being an enormous company won't pay attention to anyone making a stink unless they are an enormous customer, which is a problem in both open-source and proprietary worlds. At least there's a workaround in the open-source world, one better than object patching the binary...

    • by pembo13 ( 770295 )
      Please see the referenced bug report before claiming they aren't fixing bugs.
    • Re: (Score:3, Funny)

      by KaZen ( 25922 )

      Except he *wasn't* paying for the support contract!

      By definition if you are running CentOS, you are saying, "I'm so smart I don't need a support contract. If something goes wrong I'll fix it myself." And then he complains about getting bitten by the "Red Hat Perl Bug".

      If Red Hat is so Horrible (And by extension CentOS), why is he running it? If vendor supplied component X is worthless, why isn't he running Gentoo? Oh, that's right, because having a stable platform is *valuable*. But, it would appear, n

  • Modules (Score:3, Interesting)

    by haeger ( 85819 ) on Friday August 29, 2008 @11:49AM (#24795793)

    We used "modules" in a similar situation. http://modules.sourceforge.net/ [sourceforge.net]

    There was a lot of development where I worked before. Things were written with dependancies to specific versions of programs. They would "probably" work with a later version but the developer didn't want to risk that and neither did the business side, so we implemented modules and let the devoper load the version s/he needed.

    "module load perl" would always load the latest version but if you depended on a specific version you could always do a "module load perl/5.5.8" which would set environment variables to only get things from that version.

    Worked like a charm.


  • Article is a troll (Score:5, Insightful)

    by wrook ( 134116 ) on Friday August 29, 2008 @11:50AM (#24795801) Homepage

    Cent OS is *not* an OS that Red Hat provides support for. So, in terms of support, you get what you pay for. The bug is fixable by recompiling Perl? Great. Submit the fix to the maintainers. End of story.

    But, supposing that you *did* pay for support and you ran into this problem... It's a known bug with low priority. So get them to fix it. You're paying for support. Hold your vendor to their promises.

    And if they don't fix it, find another vendor. That's the beauty of open source. If you need support and your current supplier sucks, you can find another.

    But it's completely disingenuous to complain that recompiling your Perl binary will void your support contract *when you have no such contract*.

    • by A beautiful mind ( 821714 ) on Friday August 29, 2008 @11:58AM (#24795921)
      Still think it's [redhat.com] a troll?

      This is what a perl core hacker [perl.org] has to say about the issue:

      It seems that there is still a problem with RedHat's packaged perl 5.8."8"**. RedHat seem to have an aggressive policy of incorporating pre-release changes in their released production code. This would not be so bad if they actually communicated back with upstream (i.e. me and the other people on the perl5-porters mailing list), or demonstrated that they had sufficient in-house knowledge that they didn't need to. But evidence suggests that neither is true, certainly for 5.8.x

      Let me stress that there has never been this problem in any released Perl, 5.8.7, 5.8.8, 5.10.0, and it won't be in 5.8.9 either when it comes out. The problem was caused by changes I made in the 5.8.x tree that RedHat integrated. End users reported the first bug something like 2 years ago, and RedHat closed it as "upstream patch" rather than reporting back "you know that pre-release change you made, that we integrated - well, it seems to have some problems"


      For their versions affected, RedHat merely need to put out a patch integrating changes 31996, 32018, 32019 and 32025 which FIX IT, are documented as FIXING IT, and are from NOVEMBER 2007.

      • by imroy ( 755 )

        RedHat seem to have an aggressive policy of incorporating pre-release changes in their released production code.

        Great, so it's a repeat of the GCC 2.96 debacle.

        Oh, and the link went to the wrong journal entry. Here's the right one [perl.org].

    • by Chirs ( 87576 )

      And if they don't fix it, find another vendor. That's the beauty of open source. If you need support and your current supplier sucks, you can find another.

      Theoretically, yes. But if your current distro provides board support for a dozen specific hardware boards, you've made version-specific modifications to the kernel and userspace, all your hardware vendors have validated against your current software vendor, and you've gotten your end product certified based on the current software vendor.....in practice it becomes extremely difficult to switch distributions.

  • Well that's one issue with using pre-built things is that you it may not have been optimized for your usage or in the case of Perl, general usage. I kid! I kid! :P At least open source allowed an option. But I would be careful about compiling your own for everything. There are cautionary examples of how this could lead to problems. [xkcd.com]
  • Wrong title, wrong article, wrong on just about every level of troubleshooting application performance benchmark.

    It only affects x64_86 branch on old 5.8.8 perl package, not just Red Hat.

    • by makomk ( 752139 )
      Nope - as far as I can tell it's a Red Hat only bug due to a Red Hat specific patch, and it affects all platforms. (Well, the patch is included in official Perl releases, but only together with other changes that avoid the performance issues.)
  • If is a critical to your business, then why are you relying on a general-purpose vendor to provide it to you?

    Compiling your own textutils or findutils? That's ridiculous. Compiling your own X11 Server? Lunacy. But if you're building a perl application, it probably makes sense to have tight control of your perl interpreter, down to the compiler options, packages installed and binary builds.

    An example from my real life: At some of my employers we've built our own Apache binaries, our own Ruby interpreters, e

    • Control the things that are closest to your application. Let outside vendors cover the infrastructure that isn't. That's just good engineering practice.

      I agree. Using a generic build of any mission-critical software wastes resources, and every unused-but-still-enabled feature is a potential security problem.

      I'm typing this on my development Linux box. It runs a custom kernel, precisely matched to the hardware and my requirements. My policy is that stuff I use all the time (e.g. networking) is compiled in to the kernel, while stuff I don't use all the time (e.g. usb mass storage, udf file system) is modules that I can load as needed. My main applications

  • by MSG ( 12810 ) on Friday August 29, 2008 @12:18PM (#24796309)
    I don't know how many projects have asked Slashdot not to link to bugzilla. It makes the system unusable for the developers trying to get work done.

    Here's the text currently in the bugzilla entry (edited to meet slashdot's filter requirements):

    Bug 379791 - perl bless/overload performance problem
    Summary: perl bless/overload performance problem
    Status: VERIFIED
    Product: Red Hat Enterprise Linux 5
    Component: perl (Show Red Hat Enterprise Linux 5/perl bugs)
    Version: 5.2
    Platform: All Linux
    Priority: urgent Severity: high
    Target Milestone: rc
    Assigned To: Marcela Maslanova
    QA Contact: desktop-bugs@redhat.com
    Whiteboard: GSSApproved
    Keywords: ZStream
    Depends on:

    Reported: 2007-11-13 07:14 EDT by Nigel Metheringham
    Modified: 2008-08-29 10:30 EDT (History)
    Fixed In Version:
    Release Notes:

    Description From Nigel Metheringham 2007-11-13 07:14:04 EDT

    RHEL5 perl shows the same performance issues as the Fedora 7 perl did - see
    Bug #196836 and Bug #253728

    This has been demonstrated in the recent perl update perl-5.8.8-10.el5_0.2

    Same fix needs taking across to RHEL, ideally as a update release rather than
    waiting for next major release cycle.

    I do not have RHEL5.1 to test against right now, but the timing of the Fedora
    fixes leads me to believe these would be much too late for the 5.1 release

    -- Comment #2 From Martin Kutter 2007-11-30 05:24:01 EDT --
    The issue can be observed running the benchmark script from the recent
    SOAP::WSDL package.

    To do so, download SOAP-WSDL-2.00_24 (and its dependencies) from CPAN, run perl
    Build.PL && perl Build, cd into benchmark and run perl -I../blib/lib 01_expat.t

    This is the Output from RHEL4:
    perl -I../lib 01_expat.t
    Name "DB::packages" used only once: possible typo at 01_expat.t line 2.
    Benchmark: timing 5000 iterations of Hash (SOAP:WSDL), XML::Simple (Hash), XSD
    Hash (SOAP:WSDL): 4 wallclock secs ( 3.48 usr + 0.01 sys = 3.49 CPU) @1432.66/s (n=5000)
    XML::Simple (Hash): 7 wallclock secs ( 7.19 usr + 0.03 sys = 7.22 CPU) @692.52/s (n=5000)
    XSD (SOAP::WSDL): 6 wallclock secs ( 6.06 usr + 0.01 sys = 6.07 CPU) @823.72/s (n=5000)

    And this (with reduced n) is from RHEL5 (different machine, perl-5.8.8-10):

    Benchmark: timing 500 iterations of Hash (SOAP:WSDL), XML::Simple (Hash), XSD
    Hash (SOAP:WSDL): 1 wallclock secs ( 0.59 usr + 0.00 sys = 0.59 CPU) @847.46/s (n=500)
    XML::Simple (Hash): 1 wallclock secs ( 1.06 usr + 0.00 sys = 1.06 CPU) @471.70/s (n=500)
    XSD (SOAP::WSDL): 11 wallclock secs (11.34 usr + 0.01 sys = 11.35 CPU) @44.05/s (n=500)

    Increasing the number of runs shows the O(n^2) nature of the performance problem
    - increasing the number of runs by a factor of 10 increases the runtime for the
    XSD bench by a factor of nearly 100:

    Name "DB::packages" used only once: possible typo at 01_expat.t line 2.
    Benchmark: timing 5000 iterations of Hash (SOAP:WSDL), XML::Simple (Hash), XSD
    Hash (SOAP:WSDL): 6 wallclock secs ( 6.19 usr + 0.03 sys = 6.22 CPU) @ 803.86/s (n=5000)
    XML::Simple (Hash): 11 wallclock secs (11.20 usr + 0.02 sys = 11.22 CPU) @ 445.63/s (n=5000)
    XSD (SOAP::WSDL): 851 wallclock secs (847.36 usr + 2.28 sys = 849.64 CPU) @ 5.88/s (n=5000)

    -- Comment #3 From RHEL Product and Program Management 2007-12-03 15:47:35 EDT --
    This request was evaluated by Red Hat Product Management for
    inclusion, but this component is not scheduled to be updated in
    the cur
  • for free from http://www.activestate.com/Products/activeperl/ [activestate.com] since it is not effected by this bug. Seriously, this is far from the first time that Red Hat has botched the dynamic language environments it ships.

  • by flyingfsck ( 986395 ) on Friday August 29, 2008 @12:38PM (#24796659)
    If he can fix his own problems, then why exactly is he paying RedHat for 'support'? I have filed and fixed numerous bugs in my distro of choice. He should do the same.
  • Hope you're just as happy if they stop "giving" cents to FOSS.
  • That's what we did. Download the SRPM for RHEL5's perl (currently unreleased), and pull the perl-5.8.8-U28775.patch. Download the SRPM for your RHEL4-based OS, edit the spec to include:

    Patch28775: perl-5.8.8-U28775.patch

    And then make sure to then add:

    %patch28775 -p1

    Somewhere in the patch section.

    You then get "official" RH perl with the patch for the reblessing. It took me about 30 minutes to do all that my first time, including dusting off my RPM setup and knowledge.

    Should RH have fixed it 2 years ag

    • Re: (Score:3, Insightful)

      by Jimmy King ( 828214 )

      Man, I wish I would have been able to see this post 8 months ago. I fought with this at work for many weeks. We had a CMS that some contractors developed which used DBIx::Class heavily. They developed it on a SuSE box and had no issues. Then it was deployed on Red Hat (yeah, yeah. Not my choice to have the dev environment different than the live one. I've brought it up several times in the past.) It ran like total crap on the RH machines. Then the contractors left and the project was passed to me, w

    • Sorry about that, this is in RHEL 5. I used the FC7 SRPM when I made my patch (back in April).

      Still principle's the same--just get your current SRPM (e.g. perl-5.8.8-10.el5_0.2.src.rpm), go get the latest FC SRPM (e.g. perl-5.8.8-28.fc7.src.rpm), find the U28775 patch file, add it to the spec, rebuild your original SRPM with that patch file in its spec, etc.

      Geez, what was with me and question marks in that post? I need to preview a little longer.

  • If speed is so important for the author of the article, wouldn't something written in C using libxml be a better choice than using (what I'm assuming) are XML modules written exclusively in Perl?

    • Re: (Score:3, Informative)

      First off, you shouldn't have been modded Troll. It's a legit question. *shakes fist at mods*

      It's not all-or-nothing. The code doesn't have to be super fast, just fast enough. Perl can (when running at it's normal speed) accomplish the needed task at a sufficient speed. If Perl couldn't get it done fast enough when running properly, then yes it would be the wrong tool for the job.
  • by stupido ( 1353737 )

    1) CentOS is *not* a RedHat product. So, Vipul, you don't lose any support... because you're entitled to none!

    2) For the sake of clearing the FUD with RedHat's bugzilla's policies, here are some details on how it works:
    - There's no rule that patches applied on bugzilla are to be reported upstream! Some (large) packages have over 100 patches applied. How would *you* feel if RedHat spammed you every time they applied a patch to whatever software you wrote?
    - Upstream devs can register to receive any and all bu

  • by doomicon ( 5310 ) on Friday August 29, 2008 @03:52PM (#24799637) Homepage Journal


    Bug since 2006 in an "Enterprise" Operating System. So they haven't been able to get some spare body to rebuild perl?

    Maybe I'm a bit jaded as I have had extensive dealings with Redhat support. I find it funny that for the longest time Redhat pushed their certifications so damn hard, but don't require their own support technicians to know anything beyond scripted responses.

  • A bug that the official vendor doesn't want to fix, so the customer goes back to the original source, compiles it and fixes the problem himeself...

    When's the last time you saw this sort of 'complaint' about a Microsoft product. It may start the same, but the ending is very very different.

"Even if you're on the right track, you'll get run over if you just sit there." -- Will Rogers