That's unfortunate, because the impact of this bug could be far-reaching. Red Hat Enterprise Linux customers are undoubtedly susceptible, as are users of Fedora (Red Hat's community-maintained development branch) and CentOS (a free Linux distribution built from Red Hat's source code).
Fish or cut bait?
The immediate lesson to be learned from this incident is the importance of profiling your code. Prakash discovered the bug in the CentOS Perl interpreter using the Devel::NYTProf source code profiler. Had he not done so, he might have been hard at work chasing his own tail even now, fruitlessly trying to optimize away the bottlenecks in his own code -- as doubtless many other CentOS and Red Hat customers are still doing.
If your organization is affected by this bug, you have two options. First, you can always sit tight. The bug will have no significant impact on many Perl scripts, especially those that don't instantiate a lot of objects (which might be most of them). And the more people hear about the problem, the more likely it is that Red Hat will expedite a fix.
If that won't work, you could compile the Perl interpreter from source, as Prakash did. The process is straightforward and should be painless for anyone with basic Unix experience.
Doing so raises some issues, however. First, if you substitute homegrown binaries for the ones that shipped with your Linux distribution, you effectively waive any support contract for that particular tool. That hardly makes sense if you rely upon the tool for a mission-critical system or application.
Furthermore, who's to say that the version you build won't have some hidden bug or performance problem of its own? If Red Hat can screw up, so can you. It's a brave IT manager who would be willing to take responsibility for a custom built development tool on an enterprise-wide basis.
A better LAMP stack
Perhaps the best solution would be to find a software distributor that is willing to provide enterprise-class support for the open source application development platforms that you value the most. At the end of the day, maybe it's unrealistic to expect a single company -- a Linux vendor -- to provide comprehensive maintenance and support for the entire universe of open source software projects.
A number of companies have offered support contacts specifically for Perl. Most recently, Sun unveiled an enterprise-ready version of the LAMP stack at OSCON. In the past, however, such offerings have met with lukewarm response. Having chosen open source software on the basis of cost savings, the majority of customers choose to go it alone, rather than shell out for additional support contracts for software they can otherwise download for free.
Vipul Ved Prakash's case is proof enough that this attitude must be curbed. For companies that rely on Perl for mission-critical applications, a robust, reliable Perl interpreter is every bit as important as a well-tuned Linux kernel. Unfortunately, realizing this is one thing; committing funds to it is another.