Matthew's Journal

I have an ITIL course next week, which has made me start thinking about ITIL again. My experiences of ITIL have led me to the view that it's largely harmful; what am I missing?

Starting with the ad hominem, it arose from the civil service, which does not have a stellar record of IT delivery. Also, it has an institutional dislike of specialists, which I think informs some of the ITIL philosophy.

My first grumbles with ITIL are about jargon; it has a special word for all sorts of things which means you have to be ITIL trained to understand what people are going on about, which I don't think results in clear communication. Also, it insists on talking about "customers"; I think this is harmful because it sets a relationship up between IT and IT's customers, rather than treating colleagues as colleagues who work together in collaboration. It often seems to miss the opportunity for IT to provide some guidance into what the users of a particular service might need.

Then there's the procedural obsession - everything has to have its own Capital Letter Management Process. In my experience, this leads to a lot of process (and water-fall style setting plans in concrete) at the expense of anything that might be considered agile delivery or informal interaction between teams. While in theory ITIL lets you do continual service improvement, this often feels like an afterthought - there's too much weight of procedure to do anything like rapid iterations in collaboration with users. And there tends to be considerable procedural siloization between development and operations, which further makes any sort of rapid deployment / devopsy model difficult.

Finally, ITIL seems to result in organisations where everything has to be Managed and Approved by Management. So you have a Change Management Process which disenfranchises your IT experts, because before they can do anything they have to produce a pile of paperwork which goes to a Change Management Board (made up of management) who get to say yes or no to a proposal. The effect is that your IT experts don't feel trusted to do their jobs (because they aren't) and are disempowered to improve things - you can't scratch an itch quickly, because some remote bit of management has to weigh in before you can actually do anything.

Git has become the de-facto standard revision control system, so one of the things I've been doing recently at work is moving our old Subversion repositories to git[0]. git svn is a plausible tool, but it's more designed for continued inter-operation between git and svn than for a one-way export. For example, because tags in svn are basically specially-named branches, they end up as branches in the resulting git repository, which isn't really what you wanted.

Thankfully, the internet has plenty of handy tutorials on how to improve on git svn's default operation, so the resulting git repository is a better starting point for future development. Probably the best of these is The git book's article. Two of the steps are to turn the "tags as branches" into proper tags, and to rename the remotes/* branches to local branches:

#tag-branches into tags
$ cp -Rf .git/refs/remotes/origin/tags/* .git/refs/tags/
$ rm -Rf .git/refs/remotes/origin/tags
#remotes/* branches into local branches
$ cp -Rf .git/refs/remotes/* .git/refs/heads/
$ rm -Rf .git/refs/remotes

It may[1], however, turn out that there is nothing in .git/refs/remotes/origin/tags/, even if there were tags in your svn repository and git branch -a shows the relevant branches! This will be vexing. Furthermore, there will only be a few branches in .git/refs/remotes/. What is going on?

The answer is that git has tidied up .git/refs because it has run git pack-refs for you. That means that there is now a file .git/packed_refs which has lines of the form:

7c8a5686b698a61a33c4a6c73776da20b5ede635 refs/heads/origin/protocol2

This is the equivalent to having the file .git/refs/heads/origin/protocol2 containing 7c8a5686b698a61a33c4a6c73776da20b5ede635 (i.e. that the tip of the origin/protocol2 branch is 7c8a568...).

So what? Well, it now means you can achieve the tidying up that the above shell runes do by editing .git/packed_refs (carefully!). For example, I used emacs' query-replace function to replace refs/remotes/origin/tags/ with refs/tags. And joy was unconfined.

So I wrote this in case anyone else trips over this feature (so feel free to link to this post). If I have some tuits I might try and get the git book updated, too...

[0] Also taking advantage of this opportunity to re-structure them somewhat with git filter-branch and friends, but that's not really relevant right now.
[1] More likely if your repository was large or complex

Back in December 2007, I installed linux on my Mac Pro (my work desktop machine), following the instructions on http://wiki.debian.org/DebianOnIntelMacPro (some of which I edited in the light of my experience). 18 months later, I'm spending an increasing proportion of my time at work running linux rather than OSX. Mainly this is because Debian has a sensible 64-bit toolchain, something that Apple still haven't managed to get right. Also, fink is a hacky mess, whereas Debian's amd64 distribution works Just Fine.

There are some flies in the ointment, though. The mactel-linux patches aren't in the mainstream kernel, so there's a certain amount of faff involved in building a kernel; I've not made audio work as yet, but I've not tried very hard (it is a work machine, after all ;-). The biggest down-side, by a country mile, however, is firefox. It's dreadful. Every so often (sometimes more than once a minute), it'll just start chewing 100% of one of my CPUs, even if I've not looked at a web-page for a while. Talking to people on #chiark, it seems I'm far from alone in having these random cpu-chewing incidents. I do wish there were a decent Free graphical web browser.

The python interface to databases is increasingly irking me; I have a load of working code that talked to an Oracle database (via cx_Oracle), that I now want to make talk to a Postgresql database (via pgdb). This is far too much pain. Firstly, there are 5 different parameter styles for python database modules (and the two modules concerned use different ones), secondly there seems to be no specification as to how types should be returned - so while cx_Oracle returns date objects (sensibly!) for date columns, pgdb returns strings instead (why???).

Bah.

At work, I have a 2x 2.66 GHz Dual-Core Xeon Mac Pro with 12 GB of RAM, that I use for some fairly intensive disease simulation work. I deal with reasonably large data-sets; whilst my own code will happily build 32- or 64-bit on OS X, I use other tools (python, R, gnuplot, etc.) that come as 32-bit by default on OSX (or through fink). Building them 64-bit on OS X has proved painful - even with Leopard, the 64-bit stuff is a bit half-arsed (presumably because Apple don't want to ship two versions, one for 64-bit platforms, one for 32-bit), and there's only so much fighting with build-systems I can do before I want to smash things.

So, I figured I might as well try installing a proper 64-bit OS; it would enable me to have a completely free-software system to use as well. Debian wiki has some instructions, which seemed like a good starting point. The 'net is, however, full of a lot of confused and confusing discussion of the issues. I won't duplicate those instructions here (although I will be editing that page in due course). Suffice it to say that up to the "reboot" point, everything went smoothly. I have a second hard-disk which I wasn't using, so I installed onto that, leaving about half of the disk free for future deployment.

The machine rebooted, rEFIt offered me a linux option, I selected that, and after a pause, was offered "Missing operating system" on a line by itself. That error message isn't found in the rEFIt source, which was confusing - I spent some time thinking it was an error from a bit of the Mac's firmware, so fiddling with different partition schemes, partitioning using Disk Utility, etc. These were all blind alleys. The key observation (which was pm215's) was that rEFIt contains syslinux_mbr.h, and, indeed, the following code snippet:

    if (!HaveBootCode) {
        // no boot code found in the MBR, add the syslinux MBR code
        SetMem(SectorBuffer, MBR_BOOTCODE_SIZE, 0);
        CopyMem(SectorBuffer, syslinux_mbr, SYSLINUX_MBR_SIZE);
    }

So I went looking at the beginnings of partitions (and indeed, in the MBR of the disks themselves) to see what was there. Sure enough, there was LILO on the second disk drive, but Syslinux's MBR on the first disk drive's MBR (i.e. the disk I boot OSX from)!

rEFIt does seem to rather assume you're only using one disk drive (see the gptsync utility, which only looks at the first disk), so it seems that when asked to boot linux, it observed the lack of MBR on the first disk, stuck a syslinux MBR there, and tried to boot it. syslinux then produced the "Missing operating system" error that had so frustrated me.

The work-around is to install your bootloader of choice into the MBR of the first disk (OS X doesn't use the MBR for booting, so this is safe), and then all is well. rEFIt now starts LILO on the first disk, which will happily boot Linux off /dev/sdb2.

That's all good. There are a few wrinkles remaining, though:

• Filesystems - linux will read hfsplus filesystems, but can only write to them if the journal is disabled. Leopard doesn't let you un-journal a filesystem from the GUI, although you can do so using the command-line diskutil disableJournal [force] command. You don't want to do this on a volume that isn't carefully backed-up! Similarly, although ext2fsx exists, that only manages read-only access to ext3 unless journalling is disabled. It strikes me that these are things that ought to be fixible, without overly endless pain.


• X - X.org doesn't fully support the NVIDIA GeForce 7300 GT card in the mac pro - you can't make any use of a second monitor currently. I've no idea if this is likely to get fixed any time soon


• Hardware autodetect - Linux isn't quite a smooth as OSX for this - I had to work a bit at getting the trackball correctly configured, and I need to spend some time getting my other mouses' buttons working (they've been re-mapped as well as the track-balls). I had to hand-hold the X.org install rather more than I'd like, too. Nothing too taxing, though.
  

When creating users on linux, I made sure to match the uid and gids from OSX, meaning that users can access (albeit read-only) their Leopard homespace on Debian. I'm generally pretty impressed with the linux install, the fully 64-bit toolchain is a real boon, and it's all DFSG-free! :)

Work are going to a Malaysian restaurant in a nearby town for our Christmas dinner. This strikes me as a slightly odd idea, but there you go. My suspicion is that said restaurant will do dishes from its usual cuisine better than traditional [sic] Christmas food. OTOH, the pudding options were a tropical fruit salad, Christmas pudding, or cheese and biscuits. This means that my Christmas dinner selection is really rather strange:

Starter: A ramekin of slow cooked lamb served with roti chanai segments and Malaysian coleslaw
Main: Medallions of beef flavoured with aromatic lemon grass, mild chilli, and coconut milk
Dessert: Christmas pudding, served with double cream

Chris will hopefully pick my bike up today, if we can co-ordinate this properly. I'm not overly hopeful...

Last night I had a series of anxiety dreams about procrastinating so much that my th*s*s never got finished :(

Finally, another word to the wise: If you don't want to listen to the voluntary at the end of a service, that's fine. What is not fine is having a very loud conversation with the (slightly deaf, I presume) person next to you during the entire thing so that those around you can't listen to said voluntary in peace.