Unfortunately, enterprises tend to pre-purchase shared storage and buying 8TB of disk when you only need 1TB of space tends to get you noticed during economic downturns.

There will always be a market need for small, fast drives, and to bring this back to the original guy's point - it's because by some very practical considerations, several performance metrics per raw TB have actually declined.

That may be so. The new drive may indeed have four times the raw read throughput. But how much larger are they? Five times.

And even more tellingly, look at the seek performance. I looked up those two drives you mentioned. You'll find it's unchanged at 8.5ms. So we're seeking at the same speed, for more data.

In practice, then, in terms of throughput per provisioned GB, we are 24% worse off, and in terms of seek time per megabyte we are TEN times worse off today!

To illustrate what I mean, based on those numbers above: slurping 10TB off an idealised JBOD array of those newer drives would take 89 seconds; slurping 10TB off an idealised array of the older drives in parallel would take only 72 seconds. A similar (but far worse) story applies to random seek time performance, especially for busy transaction systems.

One might challenge the exact figures, but it doesn't matter - the point is, drive size is an important gotcha in storage performance optimisation today, and it's because performance has not really kept pace with drive size. The issue is not offset by the bigger caches they're turning up with, although that helps for some workloads.

We haven't talked dollars. The cost is important, but that's another dimension. Let's keep this to engineering chatter.

So what happens in shops that need really high performance? Well, if it's an application with lots of random reads but with hotspots, then cache will do nicely. But for raw random write performance i.e. the heavy transaction processing applications, it's gotta be more 15K RPM spindles at lower capacity. Or go crazy and solid state, but that's another party.

PALO ALTO (Reuters). PHP-based website reports scalability problems. Blames server hardware. Film at 11.

Privacy is not important and it's a myth that you ever had it. Your identity is not important. If it gets stolen, you can make a new one. In the meantime, you're just being another antisocial geek who didn't learn the value of networking.

The problem is, Perl is just a programming language, not a conceptual system. Arguably it is the antithesis of a conceptual system. Many teams then create their own application frameworks atop it (e.g. Mason, POE), and it's rare for these frameworks to be compatible since Perl offers so many variations in the construction of even standard programming artifacts like classes & objects.

In addition, the level of expression (i.e. TMTOWTDI) means in practice that highly varying programming styles occur throughout large, long-lived bodies of code.

As a result, significant Perl-based business applications tend to become hard-to-maintain hairballs of divergent style and subtly variegated concept.

The root cause: as I started with; the absence of a standard conceptual framework for Perl means that during the early phases of a project, it's much harder to reason meaningfully about the eventual form of the system than it is with, say, Java or .NET where many of the design patterns are explicitly standardised.

I wouldn't say that "Corporates Hate Perl". It's just the Perl as an application language doesn't suit the formal design & architecture process we're seeing increasingly as IT departments start to grow up and realise that they're not the most important people in the company.

That doesn't disqualify Perl from being a useful tool, and it'll always have a place in data transformation, but it does mean that Perl isn't going to be one of the general-purpose application programming languages of the future.