Sometimes, Windows wins

It should be clear by now that I am an advocate of free software.  I’m not reflexively against closed software though, sometimes it’s the right tool for the job.  Use of Windows is not a reason for mockery.  In fact, I’ve found one situation where I like the way Windows works better.

As part of our efforts to use Condor for power saving, I thought it would be a great idea if we could calculate the power savings based on the actual power usage of the machines.  The plan was to have Cycle Server aggregate the time in hibernate state for each model and then multiply that by the power draw for the model.  Since Condor doesn’t note the hardware model, I needed to write a STARTD_CRON module to determine this.  The only limitations I had were that I couldn’t depend on root/administrator privileges or on particular software packages being installed. (The execute nodes are in departments across campus and mostly not under my control.)

Despite the lack of useful tools like grep, sed, and awk (there are equivalents for some of the taken-for-granted GNU tools, but they frankly aren’t very good), the plugin for Windows was very easy.  The systeminfo command gives all kinds of useful, parseable information about the system’s hardware and OS.  The only difficult part was chopping the blank spaces off the end of the output. I wanted to do this in Perl, but that’s not guaranteed to be installed on Windows machines, and I had some difficulty getting a standalone-compiled version working consistently.

On Linux, parsing the output is easy.  The hard part was getting the information at all.  dmidecode seems to be ubiquitous, but it requires root privileges to get any information.  I tried lshw, lshal, and the entire /proc tree.  /proc didn’t have the information I need, and the two commands were not necessarily a part of the “base” install.  The solution seemed to be to require the addition of a package (or bundling a binary for lshw in our Condor distribution).

Eventually, we decided that it was more effort than it was worth to come up with a reliable module.  While both platforms had problems, Linux was definitely the more difficult.  It’s a somewhat rare condition, but there are times when Windows wins.

4 thoughts on “Sometimes, Windows wins

  1. Pingback: Tweets that mention Sometimes, Windows wins « Blog Fiasco --

  2. The ‘linux base install’ is what you tell your unattended system to do. The rest is easily achieved with help of your favourite configuration manager, like cfengine ( or puppet or chef or whatever you use. Installing additional software on hundreds/thousands of nodes is really easy if you have a configuration manager. We use cfengine (version 2 at the moment, version 3 appears to be even better but 2 works for us, so why bother upgrading it now. I’ll wait until there is a new version of Automating Linux and Unix System Administration, Second Edition with all the details about cfengine 3) .

    The same thing applies to Windows, really.

    At work Perl is routinely installed as part of our unattended installation procedure for Windows machines. If for whatever reason it is not installed, then it gets installed (and updated) by wpkg ( If you only have a C: drive then you can basically copy the c:\perl folder to another Windows computer. If you require associating the *.pl extension with the perl.exe binary, it requires a bit more work, but if I recall correctly you just need to use ftype and add the perl.exe binary to the %path%, nothing really shocking and easily scriptable.

    So basically keep a Windows computer with an updated Perl version and distribute that one to the rest of your park with wpkg, server manager or whatever you use to manage your Windows computers. If I need a particular module, I install it on my ‘master’ Perl machine and the next day or when wpkg re-runs it is distributed all over the place.

  3. I understand the idea of using config managers to install packages, we use cfengine 2 to manage approximately 3000 machines. The issue is that at the Purdue campus there are many separate IT groups. I don’t have any control over what is installed on the machines maintained by those groups and so cannot rely on anything that doesn’t come with the system by default. Politically, it is not possible to bundle extra software (e.g. ActivePerl) with our Condor package.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>