On software maturity

Filed under: Geekiness — iain @ 18:43:31

This post was to be a rant. The subject of my ire was to be Ruby, a programming language about which I know next to nothing. I know so little about Ruby that if you kicked down my door, put a gun to my head and demanded that I code up Hello World in Ruby, I’d ask you to pull the trigger there and then so I wouldn’t get blood all over my monitor when you finally ran out of patience. In any case I almost certainly don’t have the interpreter installed on any of my machines.

Given that I knew so little about this language, how could I be girding my loins for an epic moan at its expense?

A mighty question. In fact it occurred to me that my complaint wasn’t against Ruby at all. The Ruby language was guilty only of being new, which is a common characteristic amongst young projects. Indeed, I realised I didn’t even have a complaint, against Ruby or anyone. Though Ruby is guilty of calling its packages Gems, which is somewhat lame.

At this point I need to take a step back and explain what I was doing and what it was that made me so upset.

I’d been evaluating cfengine. cfengine is a configuration management tool which you install on a bunch of servers to get them to behave the way you specify. Think of it as allowing you to provide rules on how you think the servers should be; rules which cfengine acts upon to bring the machines in line. So for example you might say "the Solaris machines need to have dtlogin turned off" and " the Linux machines need to have gcc installed." Slap cfengine on your machines with those rules and it will go away and Do Stuff to ensure that dtlogin is disabled and gcc is installed.

It’s pretty clever but it isn’t exactly what I was expecting. I wanted to be able to write my rules on a central server and have the other machines on the network connect to it and get instructions. Instead you have to roll all the rules out to all the machines and let them determine, based on your policies, what actions they should take.

In addition I found it a bit of a hassle writing out all the rules, because there’s no way to create macros within the configuration. You have to come up with your own solution, eg m4.

As an aside, one name I saw popping up quite a lot when I was researching cfengine was Luke Kanies. This chap had some good ideas, wrote some interesting articles and came up with some hacks. His thoughts were definitely worth absorbing.

Even with the benefit of his and others’ ideas, I wondered if maybe I was barking up the wrong tree with cfengine. I wondered if there were alternatives. Commercial software for managing large groups of servers exists. I even know a guy who works for one of the vendors. But it isn’t cheap and cfengine is open source.

Eventually I came across Puppet. The software itself is open source but it isn’t hacked together by one university professor in his spare time; it’s developed by a commercial entity which sells support and installation consultancy. All this sounded good, though when I read that it was written in Ruby I was put off. For a start I know nothing about it and furthermore I was a bit worried about how I would run it on some of the machines on the network. Solaris 6, HP-UX and ancient Red Hat machines will happily run cfengine (written in C) but would they handle a new-fangled language like Ruby?

I was about to pass Puppet by when I happened to glance at the lead developer’s name.

Luke Kanies.

If this guy gave up hacking on cfengine and formed his own company to make something better, I decided I would give it a try.

I installed Ruby on two test machines and followed the Puppet installation instructions. Everything worked first time. Great! Then I decided to check out the command line help for the Puppet tools.

puppetd –help, instead of printing out a nice usage message, told me that help was unavailable because I didn’t have RDoc::usage, whatever that was.

Over the next hour I figured out that:

  • RDoc is a Ruby module which allows you to write documentation in your code. When you call RDoc::usage it parses markup in your script to produce the documentation on screen. ie it’s like perldoc.
  • RDoc used to be a third-party module that you had to install into Ruby. As of Ruby 1.8.2 it was bundled with the main software package.
  • I had Ruby 1.8.1.

Of course there was no documentation at all on how to get RDoc installed. Why would there be? As of Ages Ago (scaled to the lifetime of the Ruby language) it was included with the language. And if you were trying to install it yourself you’d surely know how to do so, because surely you wouldn’t be using such an ancient version of Ruby except by choice. The Puppet homepage states only that RDoc is "often not available" which reminded me somewhat of that joke about a lost helicopter pilot.

So there I was, annoyed that I couldn’t get help on a tool without reading through the script because the ability to parse out the documentation wasn’t available in the version of the language I had.

And that’s when I reflected that older versions of Perl probably didn’t have perldoc. That they didn’t have many of the useful modules that nowadays you get for free whenever you install the language. That in a few years people probably won’t even believe that there was a time when you had to make explicity checks in your code for whether RDoc::usage actually worked. It’s just how the software will grow and mature over time.

Incidentally, if you’re reading this in the future, everything I said is true; you really couldn’t assume that RDoc was available. Now get off my lawn.

No Comments »

No comments yet.

RSS feed for comments on this post.

Leave a comment

You must be logged in to post a comment.

Powered by WordPress