Hooking in some execution management bits. Most everything else is working. I could skip the fancy execution management, and just fork, but I want to be able to do a better job of logging and capturing output/signals. More to the point, with the bits I’ve got in place now, dust should be able to do the builds in parallel (everyone say “ooh” now). The only impediment to this could be RPM if you use it here.

Our documentation site is based upon wiki software from Mindtouch. I’ve liked their interface, it isn’t bad at all. It allows us to tier our content access, which is very important for our support models. In an effort to keep the site up to date, I did a yum -y update and it went through and updated. Including the wiki. Unfortunately, the new software has some terminal breakage. So, until we can unwind the breakage (or reform the site), the site will be down.

We work very hard for our customers. We take lots of lumps for our suppliers. Its our boxen, so if their stuff occasionally fails in our boxen … well its obviously our fault. Right? I am not disclaiming responsibility … we take ownership of every problem. So now imagine you are a customer, and you have a vendor who sends you (proactively) multiple sets of replacement SSDs. Walks you through the process of swapout.

* Strange personality traits: for some reason, I like listening to techno stuff while coding, and death/thrash metal while quoting ... hmmm [#](http://twitter.com/sijoe/statuses/10477947920060417) * Just read the arsenic bits. Now only if we can get gallium involved, my dissertation could have ... er ... applicability to something ... [#](http://twitter.com/sijoe/statuses/10478276933844993) Powered by Twitter Tools

So, as you might have seen from previous posts … I couldn’t fix what was broke in DKMS. We have some customers that insist upon the functionality, and we can’t fix the tool. So, rather than trying to force them to rerun our driver update scripts, we are automating the process. The idea is to make the whole process as easy as possible. Most of the management bits are done, the build bits come tomorrow.

Imagine you are working on a tool to figure out some driver module bits. Now imagine you need to parse driver version info bits. Imagine, much to your chagrin, you discover that … well … there is nothing close to a standard nomenclature. Imagine your horror thinking about all those hours you wasted on the clever –sanity switch which would sanity check what you have against whats in there. Now imagine being grumpy about this.

At InsideHPC, you can see me at the end of Wednesday night, trying to string words together sitting next to Rich Brueckner. Video turned out good. The laptop is my box (dude, I got a Dell!), and the little white thingy on the right with the blinking LED is the network connection. SC10 is a great place for supercomputing, and a terrible place for wifi. I find this curious … that we HPC types can’t seem to stand up wifi that scales to 14k people … :) The siCluster-NAS demo was done remotely (this is a good model for SC … making me think …).

After installing DKMS enabled drivers, and watching them not rebuild correctly on an update. At this point I think its worth replacing DKMS with something that does work.

We have multiple customers asking for systems with Intel Xeon 3+ GHz cores and 512+ GB of ram. Not just in financial services, but in engineering (NVH and other computing). Interesting development, and its nice to see this interest. It doesn’t hurt these large computing systems to have huge pipes to IO as well. This is a welcome development for us.

Like many other things today, this is a comedic horror show. Its god aweful, but you just can’t stop watching, and shaking your head. Apparently 70+% of US citizens want Israeli style airport security … which … curiously … works well. What we get instead is this. Scanning someone … who is entering the country, after having flown into the country? Really? What … they might bring nail clippers in and pollute our hotel rooms with dropped clippings?