Bitrot

One of my colleagues always signs his emails with the aphorism:

I'm not against progress, it's the change I do not like.

The origin of the quote is obscure. My colleague originally saw it attributed to Mark Twain but neither Google or a rather battered copy of the Oxford Dictionary of Quotations are in a position to confirm or deny this.

Whoever said it, it summarises the life of someone in research IT support rather well.

As technology advances - we want the things that are broken to be fixed and we want the things that are trundling along happily, and which the users depend on, to not break.

Of course, just because you want it doesn't mean you get it... any piece of computer code will have a finite life before the inevitable onset of bitrot.

Infuriatingly, the more sensible the developer, the earlier the bitrot sets in. When someone has resisted the urge to reinvent the wheel - and used libraries and packages from elsewhere - any major, incompatible change to one of dependencies will bring the whole thing crashing down.

Grid software - and academic research software in general - is funded from grants or written to fix a specific problem at a specific time. Development stops when the money does or when the people are needed elsewhere. Those who support the software have become very good at keeping it alive.

Take the NGS's own accounting client software - described in a blog post from last May and now available for download from its new home on Sourceforge. This consists of a set of Perl modules that crunch the accounting logs of local batch systems and deliver it safely to our accounting database.

The process involves lots of boiler-plate XML thrown around using SOAP over SSL secured HTTP connections. The developer, very sensibly, decided to leave most of the nasty stuff to other perl modules - including

• SOAP::Lite
• Net::SSLeay
• IO::Socket::SSL 
• AppConfig
• Template-Toolkit

All of these are available from the Comprehensive Perl Archive Network The original documentation advised downloading the modules using the Perl cpan tool - which downloads, builds, installs and tests modules and their dependencies automatically.

The cpan tool is very powerful and very useful., I would advise avoiding it like the plague.

Why? Cpan can only cope with one version of a module within a particular version of Perl. Many of the modules have moved on since the client code was written and the versions that cpan would install are incompatible with our account client.

The older versions are available from the www.cpan.org archive. They should be downloaded and installed in a directory outside the local perl install. You can use the PERL5LIB environment variable to add your local installation to the front of the list of places Perl searches for modules.

The same approach works with Python and compiled libraries with judicious use of the PYTHONPATH and LD_LIBRARY_PATH or LD_RUN_PATH environment variables.

It is not a cure for bitrot, but you can delay the inevitable by many years. You can get the progress without the change.