Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Bitten By the Red Hat Perl Bug

kdawson posted about 6 years ago | from the 100x-between-friends dept.

Red Hat Software 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?"

cancel ×


Sorry! There are no comments related to the filter you selected.

Redhat? (0, Troll)

Adolf Hitroll (562418) | about 6 years ago | (#24795551)

I don't mean to troll but real haxorz use Debian or Slackware...

Re:Redhat? (-1, Offtopic)

Anonymous Coward | about 6 years ago | (#24795609)

You mean real h4x0rz like Sam Hocevar, who ran Debian last, put predictable pseudo-random number generators in their SSH packages.

who will? (1)

Neotrantor (597070) | about 6 years ago | (#24795555)

you will yourself, isn't that the whole point?

waiving your support contract? (5, Insightful)

dougmc (70836) | about 6 years ago | (#24795595)

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

Re:waiving your support contract? (5, Insightful)

Richard_at_work (517087) | about 6 years ago | (#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.

Re:waiving your support contract? (5, Informative)

no1home (1271260) | about 6 years ago | (#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.

Re:waiving your support contract? (5, Insightful)

/ASCII (86998) | about 6 years ago | (#24797387)

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.

Re:waiving your support contract? (5, Interesting)

KaZen (25922) | about 6 years ago | (#24797397)

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:waiving your support contract? (1, Interesting)

corbettw (214229) | about 6 years ago | (#24795897)

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?

Re:waiving your support contract? (4, Insightful)

Dolda2000 (759023) | about 6 years ago | (#24795915)

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.

Re:waiving your support contract? (1)

Bill_the_Engineer (772575) | about 6 years ago | (#24796989)

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.

Re:waiving your support contract? (1)

tkinnun0 (756022) | about 6 years ago | (#24797237)

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.

Re:waiving your support contract? (1)

segfaultcoredump (226031) | about 6 years ago | (#24797373)

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.

Re:waiving your support contract? (1)

KaZen (25922) | about 6 years ago | (#24795935)

You would have no support contract for the /usr/local/* version of perl. And if that is what runs your multimilliondollar app, running with no support is typically not an option.

Red Hat would still support you if came across a bug in /usr/bin/perl. But their fix might not be useful for your /usr/local/bin/perl, even if it were the same bug.

Re:waiving your support contract? (0)

Anonymous Coward | about 6 years ago | (#24796135)

But Redhat has apparently known about this bug for 2 years so that support contract doesn't seem so great if they won't fix the problem.

Re:waiving your support contract? (1)

CautionaryX (1061226) | about 6 years ago | (#24796405)


Using your support contract? (1, Informative)

Anonymous Coward | about 6 years ago | (#24795971)

If this benchmark was a real issue for your production systems and you had a support contract with Red Hat you would obviously have requested and gotten a hotfix from them already. Done.

That is what support contracts are for to get support and fixes timely even if the generally available package is still going through the full support cycles. Sure CentOS is great and very cheap, but you would go to Red Hat to get timely support and updates if something like this is a real business concern.

That's what you get. (2, Insightful)

SatanicPuppy (611928) | about 6 years ago | (#24795601)

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 substantial, even aside from not having this bug.

Re:That's what you get. (4, Insightful)

timster (32400) | about 6 years ago | (#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.

Re:That's what you get. (4, Insightful)

SatanicPuppy (611928) | about 6 years ago | (#24796027)

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.

Re:That's what you get. (4, Interesting)

amorsen (7485) | about 6 years ago | (#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.

Re:That's what you get. (3, Insightful)

jd (1658) | about 6 years ago | (#24796903)

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:That's what you get. (2, Funny)

jc42 (318812) | about 6 years ago | (#24796127)

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 time saver during installation. I've often upgraded to the current perl while installing systems, and I've always found it easy.

The idea that a perl user wouldn't even have heard about the easy availability of the source is sorta surprising. That's the way you're supposed to get it, after all. The standard textbooks start off telling you where to get it (or at least they did the last time I looked at one, which has been a while ;-).

OTOH, perl does have a bit of a reputation for being solid and without any problems, so it's easy to see how someone might be lazy and just use whatever the vendor supplies. I wonder what went wrong with the RH release?

Re:That's what you get. (3, Insightful)

Christian Smith (3497) | about 6 years ago | (#24796889)

... 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:That's what you get. (2, Interesting)

moderatorrater (1095745) | about 6 years ago | (#24795785)

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.

Re:That's what you get. (3, Interesting)

Bill_the_Engineer (772575) | about 6 years ago | (#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.

My guess is it's the UTF bug (2, Interesting)

goombah99 (560566) | about 6 years ago | (#24795799)

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.

About ten years ago this showed up in Perl on Redhat. Then it went away. I bet it is back.

I think the reason it comes and goes is it depends on if things are compiled to default to UTF-8/16 or to ascii.

Example of the UTF-8 default "bug" (3, Informative)

goombah99 (560566) | about 6 years ago | (#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.

Re:That's what you get. (1)

foobat (954034) | about 6 years ago | (#24795907)

could you explain what's crap about perl in fedora?

according to those perl guys, the fedora guys are quite good

from this blog []

"â It has been a different matter for 5.10.0 in Fedora. For that, the maintainer has been very communicative, and so we were able to help him fix problems and get Perl 5.10.0 into Fedora Core 9."

Re:That's what you get. (2, Interesting)

Curien (267780) | about 6 years ago | (#24797013)

It's not a Fedora vs Red Hat thing; it's a 5.8 vs 5.10 thing. Apparently, there are different package maintainers for the different versions, and the 5.10 guys are much better about working with the upstream.

Re:That's what you get. (1)

castle (6163) | about 6 years ago | (#24795975)

You can have third party applications (GASP Enterprise ones even) that are based on Perl, or are capable of using Perl to access their API. If following this, you install a non OS Vendor version of Perl, and have other problems requiring support your support headache could forseeably increase.
In this kind of scenario (though you are likely someone who trashes Perls performance and think it beneath your favored language(s)) 100x slowdown affects you greatly, and will negatively impact business.

Re:That's what you get. (0)

Anonymous Coward | about 6 years ago | (#24796161)

Perl can run plenty fast! See Radiator (

Re:That's what you get. (2, Interesting)

Ed Avis (5917) | about 6 years ago | (#24796469)

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 the Fedora source package for 5.8 and a new upstream tarball. That way I got a smooth upgrade when the official perl 5.10 package was included with Fedora 9 - the same smooth upgrade as all the other packages in the distro.

Multiple versions of perl on the system? No thanks. This isn't Java where you have a dozen crappy third-party apps all insisting on their own exact version of the interpreter or they won't be 'certified'. Just take one good version - preferably the package that comes with your distro, which you know thousands of others are using and testing - and stick with it.

...why? (2, Insightful)

XanC (644172) | about 6 years ago | (#24796699)

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?

Re:That's what you get. (1, Informative)

Anonymous Coward | about 6 years ago | (#24796865)

The reason to run vendor code is support. Suppose your CTO gave you a few million dollars to spend on purchasing a computer cluster and writing some software to parse logs or convert files or whatever these guys were doing. This is a large investment for the company, needed to get some critical analysis done fast every day. Now you've set it all up and you go download some recent version of an interpreter from a group of developers ranging from semi-paid to hobbyists that was released a couple of months ago to run it. If this interpreter breaks, runs slowly, leaks memory, or otherwise fails you, your expensive cluster is sitting idle, and your deadlines aren't being met, who is to blame? Only you. Even worse, for you the only problem is that you might get fired, but for the company, there will be serious trouble explaining to investors and customers why some core part of the infrastructure isn't working and the company can't meet the consumer demands it said it would. This is why businesses buy software with support. If you're a hobbyist running a personal project or even some admin at a real business doing something non-critical, and you want to use random recent software you downloaded off the net, go ahead. But if your business depends on it, it's worth having a team of experts ready to help with any issues as soon as you call, as well as the knowledge that your software has been built and tested by a proven profitable company and the potential for getting compensation if things go wrong.

yum (1)

ilovesymbian (1341639) | about 6 years ago | (#24795603)

How difficult is it to install the latest Perl with yum install perl?

You'd get the latest version anyway. :)

Re:yum (1)

jm4 (1137329) | about 6 years ago | (#24795899)

It would probably be pretty difficult considering Red Hat doesn't use yum, but that's really just semantics. The main problem is the vendor-blessed version- and the one in the repository whether you use yum on CentOS or up2date on Red Hat- is the one that contains the bug.

Re:yum (3, Informative)

ccharles (799761) | about 6 years ago | (#24795991)

Actually, they do. yum is the default package manager in RHEL ever since version 4, I believe. In any case, you are correct that the repository that yum talks to contains the buggy Perl. It looks like this should be fixed for RHEL 5.3, but I wouldn't bet on it.

Re:yum (2, Insightful)

foobat (954034) | about 6 years ago | (#24795937)

the latest version supplied by redhat that is. Which is what the problem is all about.

Red Hat on CentOS? (0)

Anonymous Coward | about 6 years ago | (#24795615)

Why blame Red Hat when it's a package running on a non-Red Hat system?

Re:Red Hat on CentOS? (2, Informative)

Ritz_Just_Ritz (883997) | about 6 years ago | (#24795721)

Um...because CentOS is basically Redhat Enterprise Linux with the proprietary bits stripped out. So if the bug appears in RHEL, it will also appear in CentOS.

Personally, I always stash a copy of the latest version in /usr/local as another poster already mentioned. I've tripped on this bug before as well.


Re:Red Hat on CentOS? (2, Informative)

ccharles (799761) | about 6 years ago | (#24796021)

I can confirm that the bug also exists in the current 5.2 release of Red Hat Enterprise Linux.

Re:Red Hat on CentOS? (3, Insightful)

KaZen (25922) | about 6 years ago | (#24796089)

Except that if they were paying Red Hat for support, they would have been given the hotfix when they called in to diagnose the problem.

It seems a little odd to complain about Red Hat support, when in fact they weren't paying Red Hat for support.

Re:Red Hat on CentOS? (0)

Anonymous Coward | about 6 years ago | (#24796285)

So, basically, CentOS is LIKE Red Hat, but it's not.

Basically, a raw steak is like a cooked steak, but I wouldn't eat the raw steak.

Re:Red Hat on CentOS? (1)

Endo13 (1000782) | about 6 years ago | (#24796495)

No, the steak is the same. It just didn't come with the house vegetables and mashed potatoes.

Re:Red Hat on CentOS? (1)

fracai (796392) | about 6 years ago | (#24796991)

Mmmm... vendor perl.

Car Analogy Version (1)

Tetsujin (103070) | about 6 years ago | (#24797341)

No, the steak is the same. It just didn't come with the house vegetables and mashed potatoes.

Or... It's like the Civilian Hummer - in place of weapon and armor fittings, they put in cup holders...

Old versions in repos: Not unique to redhat (2, Insightful)

Spy der Mann (805235) | about 6 years ago | (#24796355)

My distro is PCLinuxOS and the latest available kernel is 2.6.22.something. I've found myself having to compile a lot of packages from source because they haven't been added to the repos.

And I've heard of similar problems in Gentoo.

Maybe it's part of the deficient development cycle of some apps? i.e. no stable versions, and keep fixing bugs and adding features (and bugs) at the same time.

Good thing it was open source (4, Insightful)

stjobe (78285) | about 6 years ago | (#24795631)

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.

Re:Good thing it was open source (1)

Anonymous Brave Guy (457657) | about 6 years ago | (#24796969)

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 quality default installation. If the default packages don't work properly and you just have to rebuild from source anyway, why not just set up your own Linux installation with only those packages you actually care about and use, rely on the community for support, and let the Linux distro companies go bust?

Mod parent up (1)

Kludge (13653) | about 6 years ago | (#24796975)

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

This is what open source is about.

Don't throw out the baby with the bath water (4, Insightful)

SirGarlon (845873) | about 6 years ago | (#24795637)

Just because Red Hat made one high-profile mistake, doesn't mean their support service is without value. Jump to conclusions much?

Re:Don't throw out the baby with the bath water (5, Interesting)

canUbeleiveIT (787307) | about 6 years ago | (#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 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.

Re:Don't throw out the baby with the bath water (4, Funny)

Just Some Guy (3352) | about 6 years ago | (#24796751)

Eventually, someone at gave me the answer to my problem.

You had me until then.

Re:Don't throw out the baby with the bath water (3, Funny)

porkThreeWays (895269) | about 6 years ago | (#24795987)

It's a jump to conclusions mat!

Re:Don't throw out the baby with the bath water (1)

Mr. Underbridge (666784) | about 6 years ago | (#24796115)

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.

Re:Don't throw out the baby with the bath water (0)

Anonymous Coward | about 6 years ago | (#24796629)

Red Hat issued a hotfix for RHEL customers. So they *did* fix it. It'll eventually make its way to CentOS. I guess you get what you pay for.

Re:Don't throw out the baby with the bath water (1)

dacut (243842) | about 6 years ago | (#24796911)

Oh, they've made a bunch of lower-profile mistakes with the company I work for. We have about 50k RHEL installs across our sites; actual issues with their image (especially the kernel "improvements" in RHEL3) that affect production servers are routinely ignored or dismissed.

We've considered dumping them, but this is the main supported Oracle platform -- and we're too invested in Oracle to switch away. I realize the plural of anecdote is not data, but our experience is not unique.

anonymous coward (0)

Anonymous Coward | about 6 years ago | (#24795641)

I would be thankful I had the option of fixing the issue myself. Support contracts on freebsd and linux have always been overrated in my mind when you
are used to solving issues yourself or with the community that uses it. Mailing lists are more helpful to me then the vendor in most cases.

It's not just perl (0)

Reality Master 201 (578873) | about 6 years ago | (#24795657)

I swear everything runs slower with Redhat compiled binaries, even basic shell utils like grep, sed, and awk.

Re:It's not just perl (0)

Anonymous Coward | about 6 years ago | (#24795727)

I totally agree! I thought Ubuntu was slow, but then I tried Fedora.. boy was I wrong! How can anyone even use Fedora or anything Red Hat based productively? How the hell did they manage to slow things down like that? Did they compile everything with profiling and debugging on ?

Re:It's not just perl (2, Informative)

tchuladdiass (174342) | about 6 years ago | (#24795833)

I noticed this too, but then found the cause. By default, your language setting is en_US.UTF-8 (echo "$LANG" variable). This includes unicode support, so any text utilities such as grep have a bit more work to do when searching through files (UTF-8 uses 8 bits for normal ascii charcters 0-127, but uses 16 or 24 bits for extended unicode characters). To fix this, change LANG environment variable to "en_US" (
Previewleave off the "UTF-8") prior to running these tools (if you don't need unicode support). To change the language permanently on bootup, change it in /etc/sysconfig/i18n.

Heck, this might even fix this perl "bug" (I haven't looked at it yet though).

Re:It's not just perl (2, Informative)

Reality Master 201 (578873) | about 6 years ago | (#24795893)

Maybe, but I'm not completely convinced. I have my locale to en_US.UTF8 on my Gentoo machines and they're still markedly faster.

CentOS it NOT Red Hat (5, Informative)

Anonymous Coward | about 6 years ago | (#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.

Re:CentOS it NOT Red Hat (5, Insightful)

Anonymous Coward | about 6 years ago | (#24795917)

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

The summary is bullshit.

Re:CentOS it NOT Red Hat (2, Informative)

ccharles (799761) | about 6 years ago | (#24796053)

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.

CentOS is compiled using the same tools and source (4, Insightful)

SuperBanana (662181) | about 6 years ago | (#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?

Re:CentOS is compiled using the same tools and sou (0)

Anonymous Coward | about 6 years ago | (#24797017)

You got it wrong:

"Every time Red Hat releases a hotfix, CentOS grabs the source and compiles it, sometimes weeks or months after Red Hat made it available."

There, fixed it for you.

Seriously, if you want to judge Red Hat's performance using a lagging-behind derivative distro, you are on crack. Even the CentOS guys recommend you [] to use RHEL if you're so picky about faster releases and/or fixes.

If they aren't fixing simple bugs... (3, Interesting)

russotto (537200) | about 6 years ago | (#24795729)

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

Re:If they aren't fixing simple bugs... (1)

pembo13 (770295) | about 6 years ago | (#24796019)

Please see the referenced bug report before claiming they aren't fixing bugs.

Re:If they aren't fixing simple bugs... (3, Funny)

KaZen (25922) | about 6 years ago | (#24796273)

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, not valuable enough to pay for.

Red Hat bitten by its own poor security (-1, Offtopic)

Wills (242929) | about 6 years ago | (#24795739)

I'm surprised nobody is mentioning that Red Hat was itself recently bitten by another sort of bug - a security breach. Red Hat's servers were breached and an openssh trojan installed with correct Red Hat signature. Sadly, it seems that the breach happened because Red Hat was in the peculiar habit of keeping the package signing machine networked and accessible from the internet.

link (1)

Toffins (1069136) | about 6 years ago | (#24795945)

Here's the full story. []

Diagnostic perl one-liner (0)

Anonymous Coward | about 6 years ago | (#24795759)

FTA: diagnostic perl one-liner

time perl -e 'use overload q( sub {};my%h;for (my $i=0; $i 'main';print STDERR "." if $i % 1000 == 0;}'

Re:Diagnostic perl one-liner (0)

Anonymous Coward | about 6 years ago | (#24796187)

You are missing a few things in there....

(Like the test condition, the what to do if we don't meet the test condition, etc)

And I think some of the other things got chopped out as it does absolutely nothing except immediately quit.

The ECODE tag can help a lot in cases like this (I wanted PRE, but it isn't in the allowed HTML list anymore)

(OK, I pulled this from [] and while I haven't run it, it seems like it should work, as it has the missing parts. (Searched on Google for the "use overload q" thing and found this)

use overload q(<) => sub {};
my %h;
for (my $i=0; $i<50000; $i++) {
$h{$i} = bless [ ] => 'main';
print STDERR '.' if $i % 1000 == 0;

stuff into file, then time ./filename

Modules (2, Interesting)

haeger (85819) | about 6 years ago | (#24795793)

We used "modules" in a similar situation. []

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 (4, Insightful)

wrook (134116) | about 6 years ago | (#24795801)

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

Re:Article is a troll (5, Informative)

A beautiful mind (821714) | about 6 years ago | (#24795921)

Still think it's [] a troll?

This is what a perl core hacker [] 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.

Re:Article is a troll (1)

Chirs (87576) | about 6 years ago | (#24796193)

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 practice it becomes extremely difficult to switch distributions.

Compiling your own (1)

UnknowingFool (672806) | about 6 years ago | (#24795823)

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

Linux Support Contract (1)

janeuner (815461) | about 6 years ago | (#24795843)


RHEL != CentOS (0)

Anonymous Coward | about 6 years ago | (#24795853)

hey redhat do you provide any support for CentOS actually

easy... (0)

Anonymous Coward | about 6 years ago | (#24795961)

There are a couple fixes here... re implement the Perl code in Java and gain 50%, or re implement in C if you are a man.

Why is it disturbing? (0)

pembo13 (770295) | about 6 years ago | (#24796109)

The summary said it is disturbing. According to the Bugzilla report, the performance issue arouse as a result of a necessary patch. I can see how this would be disagreeable... but how is it disturbing?

Bitten by Perl, not Red Hat (1, Flamebait)

layer3switch (783864) | about 6 years ago | (#24796151)

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.

Compiling your own is the right answer. (1)

j.e.hahn (1014) | about 6 years ago | (#24796191)

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, etc. Why? Because we didn't want someone else making version choices for us -- we wanted verified, controlled versions of these key pieces of our software platform.

I know dev teams that build their own GCC because they want very specific feature sets and don't get what they need from their distributions, or because they want conformity across a wide range of platforms.

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

Re:Compiling your own is the right answer. (1)

spaceyhackerlady (462530) | about 6 years ago | (#24796553)

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 (apache, python, gcc) are all up to date, and compiled from source. They are a precise match for what I need.

Needless to say, this box rocks.


Don't link to bugzilla (4, Informative)

MSG (12810) | about 6 years ago | (#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:
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 current Red Hat Enterprise Linux release.  This request will
be reviewed for a future Red Hat Enterprise Linux release.

-- Comment #4 From ritz 2008-02-22 06:50:04 EDT --
Patch -

_TEST_ packages with the above mentioned fix can be found at -

-- Comment #5 From ritz 2008-02-22 06:51:25 EDT --
Steps to Reproduce:
1. Use the test script below

use overload q(<) => sub {};
my %h;
for (my $i=0; $i<50000; $i++) {
   $h{$i} = bless [ ] => 'main';
   print STDERR '.' if $i % 1000 == 0;

as an executable file "".

2. Type

$ time ./

and the program will print 50 dots.

The program should complete in less than 1 second, but takes much longer under

-- Comment #6 From Marcela Maslanova 2008-04-28 09:28:58 EDT --
This issue was solved with patch perl-5.8.8-U28775.patch in F-8. It's also
working fix for RHEL-5.

-- Comment #7 From RHEL Product and Program Management 2008-06-02 16:28:35 EDT --
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update

-- Comment #8 From Nigel Metheringham 2008-06-05 06:32:08 EDT --
Confirmation that the RHEL5.2 perl package (perl-5.8.8-10.el5_0.2) has not
been fixed so RHEL still has a perl package which is effectively unusable
for many applications (ie anything using DBIx::Class, SOAP etc).

-- Comment #10 From Amos Shapira 2008-07-16 07:26:04 EDT --
Can anyone point to an alternative perl package which can be used on RHEL5.2
instead of the default one?


-- Comment #11 From Marcela Maslanova 2008-07-16 07:40:00 EDT --
What should this alternative do?

I'll fix this problem for 5.3, so it will be in next update.

-- Comment #13 From Peter 2008-08-07 12:38:26 EDT --
Will the new package be backported to RHEL5U2 ?
I would not like to be forced to upgrade 60 servers in order to get perl bug

Any timescale estimations ?
It has really big impact many critical applications.

-- Comment #14 From Marcela Maslanova 2008-08-08 02:42:52 EDT --
This bug will be solved in RHEL5U3.

-- Comment #15 From Peter 2008-08-08 03:43:01 EDT --
Well, it does not answer any of my questions.

-- Comment #16 From Ludek Smid 2008-08-08 03:54:45 EDT --
(In reply to comment #13)
> Will the new package be backported to RHEL5U2 ?
> Any timescale estimations ?
> It has really big impact many critical applications.

Since Bugzilla is not a customer support tool, it's unlikely that you can
receive response in this way.

I recommend to contact Global Support Services
[] to escalate this request.

-- Comment #17 From Peter 2008-08-08 04:50:29 EDT --
Well, it does not answer any of my questions.

-- Comment #18 From Peter 2008-08-08 04:55:19 EDT --
> Since Bugzilla is not a customer support tool, it's unlikely that you can
> receive response in this way.
> I recommend to contact Global Support Services
> [] to escalate this request.

I did it 3 days ago (many of my friends over a week ago)
and RH does not even bother to comment on it.
RH Support is not the best place to ask for support.

-- Comment #26 From Peter 2008-08-21 07:07:02 EDT --
I just received hotfix from RedHat, the test script above runs 50 times faster on
patched perl comparing to default on RHEL4.5 but i still see slowness when
using perl::DBI with Mysql
I will hopefully post some more detailed examples soon

-- Comment #27 From Peter 2008-08-21 07:10:23 EDT --
"comparing to default on RHEL5.2" - of course

-- Comment #28 From Ask Bj&#248;rn Hansen 2008-08-25 15:20:07 EDT --

What is/was RedHat trying to fix with whatever patch to Perl 5.8.8 that
introduced this problem?

    - ask

-- Comment #29 From Florin Andrei 2008-08-25 16:01:56 EDT --
Congrats, you're on Reddit now:

-- Comment #30 From Dag Wieers 2008-08-25 22:21:35 EDT --
And on Steve Ballmer's blog as well:

-- Comment #31 From Nigel Metheringham 2008-08-26 07:09:09 EDT --
Note that the blog article[1] that is causing the current surge of activity
says that:-

  1. The patch this bug report links to only mitigates the performance
     slow down due to bless/overload  (it appears to be 30x faster than
     current stock 5.2 perl, but still 2x slower than own built perl --
     - figures were taken from response by "Chad Johnson")

  2. There is still an exponential performance slow down even with
     the patches applied - it just kicks in in a different manner.
     Meaning that the basic tests we have been using to show this bug
     may be inadequate.


I would suggest a more thorough review of the patch prior to update or 5.3
release, especially in light of the hate you currently appear to be gathering.

-- Comment #32 From Dave Cross 2008-08-26 09:59:15 EDT --
There's a blog post by the Perl Pumpking about this issue. He includes details
of the patchsets that Red Hat are missing.


-- Comment #33 From Marcela Maslanova 2008-08-26 10:09:14 EDT --
Yeah I know about it. I'm still working on it.

-- Comment #37 From Marcela Maslanova 2008-08-27 10:59:26 EDT --
*** Bug 460095 has been marked as a duplicate of this bug. ***

-- Comment #42 From Peter 2008-08-28 06:47:16 EDT --
I am sorry about that, but it seems that RH Support wakes up after i state
publicly it does not do it's job properly.
So I am doing it again:

RedHat Support is not the best place to ask for support.

And Yes, Mrs Quality Assurance Analyst i am very unhappy about the way
Redhat deals with this issue.

May i (i guess not only me) get perl 5.8.8 package for RHEL5 stripped of
all of these broken patches.

But If Steve Balmer's laugh did not wake you up i am afraid nothing else would.

-- Comment #44 From Stepan Kasal 2008-08-28 12:09:04 EDT --
(In reply to comment #28)
> What is/was RedHat trying to fix with whatever patch to Perl 5.8.8 that
> introduced this problem?

The patch is necessary to fix

This is a bug in perl-5.8.8 which causes "overload and rebless" being
incorrectly; it's a real-life problem affecting modules on CPAN, e.g.,

Netcraft confirms it! (0)

Anonymous Coward | about 6 years ago | (#24796451)

Red Hat is dead!

Snark Comment (0)

Anonymous Coward | about 6 years ago | (#24796511)

Any clown relying on Perl for performance ... well ... they deserve what they get. Perl is for non time critical applications.

Has happened before (1)

propanol (1223344) | about 6 years ago | (#24796527)

Red Hat has a history of supplying packages with flaky patches. One of the kernel updates for RHEL5.1 was supplied with a backported patch for an NFS-related problem which ended up breaking caching, introducing serious performance issues that made NFS almost unusable when working with multiple files/directories. Red Hat was quick to come up with a patch after the bug had been reported - however, it only applied cleanly to their testing kernel (candidate for the next RHEL update) and refused to introduce it in the mainline kernel package, which forced us to backport the fix ourselves and keep local revisions for about half a year.

Apparently, an issue of similar origin (i.e. bug introduced by Red Hat-specific patch) is currently affecting 3ware/Areca RAID performance when used in conjunction with the RHEL5.2 mainline kernel and Red Hat is refusing to release a maintenence update to correct the error. Won't be fun for those who've got such hardware and are bound by support contracts to use only Red Hat-supplied kernels.

Re:Has happened before (1)

flyingfsck (986395) | about 6 years ago | (#24796921)

Hmm, now if you are able to do all that yourself, why exactly are you paying for a support contract?

or install ActivePerl ... (1)

hobbs (82453) | about 6 years ago | (#24796597)

for free from [] 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.

Why is he using RH anyway? (2, Interesting)

flyingfsck (986395) | about 6 years ago | (#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.

Re:Why is he using RH anyway? (1)

prestomation (583502) | about 6 years ago | (#24796967)

He's running CentOS so we can only assume/hope he's not giving a cent to Redhat.

Doesn't surprise me... RedHat isn't that awesome (0)

Anonymous Coward | about 6 years ago | (#24796799)

For goodness sakes people- use a different distribution! Even employees of RedHat don't even exclusively use RedHat. While RedHat was a cool idea back in the late 90s, and I'll admit the IPO was rather exciting (before it happened at least), they are the M$ of Linux distributions.

nig6a (-1, Troll)

Anonymous Coward | about 6 years ago | (#24797029)

on baby...donc't BSDI is also dead, Give other people More gay than they pallid bodies and serves to reinforce

A lot of people hapily not giving a cent to RedHat (1)

pembo13 (770295) | about 6 years ago | (#24797179)

Hope you're just as happy if they stop "giving" cents to FOSS.

Use RHEL5 patch with RHEL4 SRPMs (1)

Kostya (1146) | about 6 years ago | (#24797253)

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 ago. Oh yes. For this, RH should be burned in effigy. You could say that everyone already knows about this, except that some of us poor slobs keep discovering it anew :-( []

Yeah, that's me discovering it all on my own. Fun!

But honestly, when has RH ever gotten the perl interpreter completely right. From RH 4 all the way to today, the general opinion is that you should build your own perl interpreter from the freshest, stable release. RH has a long history of screwing up perl patches or being slow to get the latest in. This one (#28775) is just the worst in a long history of messing up perl for RedHat :-(

And I *like* RedHat. I have used them for years now, and I continue to recommend them as the gold standard for enterprise deployments. So I'm not saying this as a hater, just an annoyed schmuck who continues to use them (I'm probably just lazy at this point).

Re:Use RHEL5 patch with RHEL4 SRPMs (2, Insightful)

Jimmy King (828214) | about 6 years ago | (#24797385)

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, where I had to profile the code and then do a ton of searching to find the bug. I tried several of the reported fixes that were documented at the time and nothing resolved the performance issues.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>