with the latest spam surge in progress, admins seem hell-bent on using non-functional methods to fight this. So our legitimate mails get blocked, since we are on particular ISPs. This is nuts. Ok, I am going to lay into the RBLs here. Unless you have evidence that our IPs have been spamming, you should not try to stop mail. Evidence of spamming is, curiously enough, spam traced back to our IP addresses.

No news is good news. No issues, just precautions. This does bring up the issue of security. PHP appears to be quite exploitable. Sure, code in any language can usually be made to do things unexpected if fed unanticipated input, and the input is not correctly scrubbed. Just as a precaution, it looks like running PHP based sites ought to be done in terms of virtual machines without write access to local storage.

Netapp makes good points in their response to the paper on average failure rates. Ignoring the intrinsic marketing in their document, the information in there is invaluable. As indicated before, PT Barnum would be pleased with the vendors of the higher priced product promising, but not delivering, higher reliability. We had noticed this for a while: failure rates are about the same. And in this case, why would you use the more expensive product which promises lower failure rates?

For decades, I have been debating friends and colleagues talking about high performance computing, specifically parallel computing. They doubt that parallel computing techniques will ever go “mainstream”. That is, that there will ever be a large upswing in the number of users of parallel programming techniques and methods, or for that matter codes which use parallel programming effectively. I argue that this will occur, when such usage gets to be “easy”.

We have been asked to do some benchmarking of CCS systems using a number of codes. I wanted us to do better ports of the codes, so that they get at least performance parity with Linux. There is lots of FUD eminating from the groups about superiority in one aspect or another, and we want to ignore that, fix the bottlenecks, and get good performance on windows. The last time we dealt with something like this was with Solaris 10 (and to a lesser extent, OSX before that).

Saw this on /.. I heartily agree with the premise. The idea is put up, or, well … ya know … Unfortunately, Microsoft is quite likely to ignore this. Give it no notice. Which is a shame. If they have a claim worth litigating, it is likely that they would be asked if they tried other remedies first, such as asking to have the offending code removed. Here you have a large group of people basically saying “wheres the beef … er … code”?

From today’s HPCWire. What Professor Snir said for programming HPC also holds true for designing HPC systems and clusters. Anyone can take group of machines and “turn them into a cluster”. Heck, you can even ask your local, neighborhood MCSE to do it for you. And it may work well for some set of problems. But what happens when performance goes into the dirt on a critical code, and you don’t understand why?

About a year ago, we were exploring working with Sun to resell CPU cycles with application frontend units. We were going to run Linux on their machines. Seems Sun no longer is doing this. A customer asked us to provide dedicated cycles to them, for their app. Sun doesn’t seem to enable this anymore. Moreover, their entire “utility computing” model is based upon non-dedicated Solaris 10. This is unfortunately a non-starter.

So we had the little … I dunno what to call it … fiasco, mebbe? where we were promised a reasonable comparison between a JackRabbit and a Thumper, and did not get it (a reasonable out-of-box comparison, no one I know who promises accurate comparison purposefully de-tunes one platform before comparing). I am not going to dive back into that mess. When we are paid to benchmark, or when we do it on our own, we never, ever start out by ignoring the vendor/authors on what makes it slow/fast.

More people are picking up the drive story. I expect to hear rebuttals any time now from the big expensive disk players. FWIW: we have been talking about this for a while. Lots of our partners have observed these things. MTBF is a great way to estimate things. The model appears to be broken, as it is not 5-20% off. But 5-10x off. This is important. If you develop a theory, and it mispredicts something by a significant amount, you have, really, one option for your theory.