One of the things all HPC vendors have to deal with is competition. This is fine, doesn’t worry me. Fair competition can be quite good, and even exciting. Its the unfair competition that bugs me. Suppose we have a potential customer X. Said customer works with us, we generate benchmark data, show them what we can do with well tuned systems. Customer likes it. Asks us for a quote. We provide one, and the price is good.

At my day job, we have delivered a number of dual processor workstations to customers over the years with really nice nVidia graphics. Recently, a customer bought 2 4-core workstations, really nice nVidia graphics, and 32 GB ram, with 1 TB RAID disk. Then another asked for 4-core and 8-core workstations, which we provided. Now one of our larger customers is asking for 8-core and 16-core workstations with 32 GB ram.

The market has been consolidating behind various OSes for a while. Reducing the number of ports reduces ISV costs. It reduces end user management headache. Curiously enough it also reduces the engineering costs of the relevant hardware vendors, but don’t tell a few of them that, as they still perceive value where they feel they can be different. Unfortunately I have a sense of mayhem in two of the converged OSes, Linux and Windows.

Tracking this one down was fun. It turns out someone, either in SuSE-land or Linux-land, has decided that HZ is a dangerous macro to expose to users. Dangerous. Therefore, they wrap it in a kernel cloak. Which has the net effect of breaking large swaths of code which happen to use the quite innocuous HZ macro. Grrrrrr. digging through and dereferencing all the included header files I found this … ` #ifndef _ASMx86_64_PARAM_H #define _ASMx86_64_PARAM_H #ifdef KERNEL

Working on simplifying and refactoring some Makefiles for DragonFly. Yeah, will mention what it is eventually. In the makefile, I build a bunch of perl modules. The previous version of this system had a pre-pulled set of CPAN modules, and all the bits had file system names like DBIx-SimplePerl-1.8.tar.gz Which is nice and easy to deal with. In order to make sure we can use this for updating as well, I thought it would be nice to exploit CPAN and the module name without the version.

Why does SuSE insist on re-inventing wheels that others have done a far better job of inventing? I don’t get it. Specifically I am referring to not using yum in favor of their zypper and zmd and … C’mon SuSE, get with the program. Use yum. So we can stop messing around with yet-another-broken-thing-that-promises-to-be-better-someday. The yum “packaged” with SuSE is old, and broken. Worse, it sometimes, mysteriously fails. And even worse, it is effectively impossible to upgrade to the latest version.

Well, this might not be the most appropriate title for this. I need to explain this, but first let me point to the article/email in question. Now that I have pointed to it, I want to note that there is a deeply profound set of statements in this email, which seems to be a series of responses to a discussion. Bear with me. In this email, Linus Torvalds discusses some things about the licensing of Linux.

See here. Though apart from getting the author mixed up with the editor …

I do quite a bit of Perl programming work in support of our products. Perl is sometimes (mistakenly IMO) called a scripting language; it may have been designed to handle that in the past, but it has evolved over the decades into something far more powerful. But it also has this … well … implicit sense of humor about it. Maybe this is what pisses off people advocating other programming languages.

I’ve been talking for the better part of the last decade about one of the more serious problems looming for HPC, and frankly for all computing. Call it a data deluge or exponential data growth, whatever you would like. At the end of the day it means that you have more data than before, and it is growing faster than you think. Usually much faster than Moore’s law which gives you an order of magnitude about every 6 years.