Thu, 04 Feb 2010

Another Look at Version Control Systems

I’ve been using version control systems for ever—well, back to the days of SCCS anyway. Every few years, I survey the scene to see if there’s something that better fits my current needs. That way I came to use RCS instead of SCCS. Then I found CVS and, after some hesitation, migrated all my RCS repos to CVS. And then I found I hated some of the weaknesses of CVS and migrated back to RCS.

There things stayed until Subversion was ready for real world use. I chose not to migrate old work, but just started using svn for new projects and then for new work on old RCS-managed projects. That went pretty well and served me for some years.

But, as Subversion was hitting its stride, other people were working on distributed revision control systems and I started watching those projects. From time to time, I would spend a few days having a good look at the obvious contenders. A couple of years ago I felt there were a few that were ready to be considered: Git, Mercurial, Darcs, Bazaar all seemed interesting. After some consideration, I chose Mercurial and I have been happy with it.

But Bazaar, or bzr as it’s called on the command line, had been a close second in my assessment. Bzr was let down by some performance issues and also appeared to have a few other minor concerns.

Recently, I’ve had another look at the various DVCSes as part of another project and I think there’s very little to choose between Git, Mercurial and Bazaar. It comes down to comfort with the command structure and support for the workflows that you might want to adopt. For me, Git is still too clunky to use—it takes more typing to get the same result. But I think Bazaar has just moved ahead of Mercurial in terms of workflow options and it seems to have caught up in the performance area.

So I’m going to use Bazaar for a couple of new projects and I’m also going to convert a couple of active Mercurial projects over to Bazaar. And, in a few months, I’ll have an opinion about the wisdom of that choice and I’ll write about that in due course. I know I haven’t exactly explained my choice, but that’s deliberate because it really is a fine distinction and I’m pretty certain that Git, Mercurial and Bazaar are all fine systems.

Posted at: 18:10

Path: /software/discuss   |  permalink

OS X Fails to Please

I’ve been using Apple laptops for a number of years in order to have access to some specific capabilities, but I have always found it hard to come to terms with the limited functionality of OS X as a work environment. Nevertheless, when I acquired my MacBook Pro recently, I decided to just go with the flow and learn to use Snow Leopard as it was meant to be used. And that has worked out quite well for the purposes that I normally use the MacBook for—email, IRC and web browsing while on the road.

But I recently had a reason to use it for my normal work stuff. I had needed to visit a Mac retailer for some minor item and stopped to look at the 27-inch iMac, where I became entranced by the display and, to a lesser extent, by the neat overall package.

This led to thoughts of possibly buying one of these things, which in turn led to thoughts of discomfort with OS X.

So I decided to try out OS X on a decent-sized display instead of the teensy thing on the 13-inch MacBook. I hooked the MacBook up to a 24-inch display to see how things might work. This brought me into contact with Apple Fail Number 1—the ability to get stuff onto the display you want it on is a black art and in some cases it’s only possible to start an application, see where it lands and then drag it to the desired display. That was hugely unimpressive, but wasn’t the point of the exercise, so I tried to ignore it while doing my testing.

I believe I succeeded in applying my attention to the factors that would be relevant with a single large display running OS X. To give it a fair go, I used this setup for three days as my desktop environment. But that was as much as I could stomach. Gnome—whether under FreeBSD, or OpenSolaris, or Linux—is just so much better to work with than OS X that it’s really not even a contest.

The upside of this is that I’ve saved $3k that I had put aside for the iMac which I could now partly apply to the bicycle that I’ve been thinking about buying as part of my fitness program. Another upside is that I won’t be constantly chafing against all the annoying little restrictions that Apple impose on their customers. So, although I will slightly regret the decision not to add something shiny to my desk, I think I’m probably more pleased than sad.

Posted at: 17:41

Path: /software/discuss   |  permalink

Fri, 29 Jan 2010

To Do Lists and Life

In my life as a stellar-class procrastinator, I have evolved a variety of techniques aimed at convincing myself that I’m doing something about my desire to get stuff done. Probably the most well-used of these—apart from straight-out avoidance—has been via the creation of numerous lists of things to do. At its best, this results in lists of lists and lists of lists of lists. And, since I am a software person, that then results in an occasional burst of time-wasting in search of the ideal software tool for making lists.

Mostly, I find a few tools that I haven’t seen before and a few that I have tried but which I hope might have improved just that little bit to make them useful. Always, I spend a day or two playing with the tools I find and sometimes I choose one—only to discard it a week or so later.

Usually, I keep these little excursions into procrastination secret. But today’s find—todoist—has already impressed me as being much better than anything I’ve tried previously, so I’m going to give it a mention here in the hope that it will force me to just get on with ticking off stuff from my new lists (and also to let people who like lists know about a new toy).

And, to be honest, the other reason for posting about it is so I can tick off the item about blogging every Friday.

Posted at: 18:11

Path: /software/discuss   |  permalink

Fri, 11 Dec 2009

Issues With OpenSolaris --- The GNU Tools

After my recent post about giving up on OpenSolaris I received a few requests for more information from some people who were prepared to jump through the hoops of contacting me despite the lack of comments on this blog. This is one such followup. I plan more.

For reasons which are probably understood somewhere inside Sun, but which I believe to be at least in part a requirement to support legacy software, OpenSolaris is still delivered with antique, if genuinely Unix, software tools. If an innocent newbie whines about the fact that the supplied awk or tar—to pick just two examples out of many—is unable to handle just about any task that someone might expect in 2009, she will be told that the GNU utilities are available. Not only are they available, but they are available in multiple ways.

To take the case of awk, old awk is /usr/bin/awk, GNU awk is /usr/gnu/bin/awk and that one turns out to be a symlink to /usr/bin/gawk. So you can get GNU awk either by calling it gawk or /usr/gnu/bin/awk, which might tempt you to put /usr/gnu/bin in your $PATH before /usr/bin. If you do that, you might manage for hours or days until, for example, you needed to read a man page. At that point, man will be mysteriously broken, because it depends on the old Solaris versions of some of the formatting tools rather than the GNU versions, but the idiots who built man for current versions of OpenSolaris have apparently forgotten something I thought all Unix people had known for at least the last 25 years—in system tools, you exec full pathnames rather than relying on the user’s $PATH to find the right ones.

One last note for today: despite the fact that “everybody” knows that shell scripts start with #!/bin/sh, in OpenSolaris they start with #!/usr/bin/sh despite the fact that the historical formulation would work. Why? Because at some point, they did away with /bin and moved everything into /usr/bin. While it’s true that they do provide a symlink from /usr/bin to /bin, gratuitous changes like that really don’t help anybody.

Sane readers will quite possibly feel that this little essay is hardly sufficient reason to abandon OpenSolaris—and I would agree with that. But there is much more and I’ll try to cover some other issues in the near future.

Posted at: 14:57

Path: /software/discuss   |  permalink

Tue, 01 Dec 2009

Second Thoughts on OpenSolaris

After my recent post about migrating to OpenSolaris, I’ve had cause to re-think. For me, there was one really significant argument in favour of the move and one rather significant other argument. The biggie was ZFS, the other was dtrace. They are both compelling, but the more I push against all the things that make OpenSolaris painful the more I think that it’s not worth the pain.

I had been thinking of writing at length about the reasons for turning away from OpenSolaris, but I think I might defer that (at least unless I see significant interest in my thoughts).

That leaves the question of which way to jump. I’m a long-term FreeBSD user and FreeBSD does have ZFS and dtrace—so there’s some incentive to go back there. But the truth is that many of the things that make OpenSolaris a pain also apply to the BSD camp. Again, I can expand on that if people care.

When I first went to FreeBSD, it was the early days of Release 2 and Linux was far from ready for prime time. Linux is still not ideal, but it has enough people working on it to ensure that big nasty things like Gnome and Firefox and OpenOffice are as up-to-date as one might reasonably hope for; and it has lots of people writing software aimed at Linux that becomes painful to port to other systems. So, for what it’s worth, I think Linux is the path of least pain. On top of that, all my VPSes in the USA run on Debian and so I need to have Linuxisms burned into my fingertips anyway.

Which Linux? I’ve had just enough experience with Ubuntu that I think that will be my choice for boxes that have a desktop function and I’ll stick to Debian for my servers for now.

One benefit from this decision is that I expect to be able to power down most of the 7 computers that pump heat and noise into my office at home while consuming many kW of power. There will inevitably be things to regret in this plan, but I think I can live with that. I will keep at least one powerful box with 4 disks in it for temporary installations of alternate operating systems for those occasions when I want to check some software on various platforms, but I’ll only power it up when I’m actually using it.

Posted at: 14:50

Path: /meta   |  permalink

Fri, 20 Nov 2009

Migration to OpenSolaris

This entry is really just to verify that the migration of the development site for this blog to an OpenSolaris host has been completed successfully. The deployment site is still running Debian and that’s not likely to change any time soon.

Posted at: 20:43

Path: /meta   |  permalink

Premature Upgrade

You are a technically-competent geek who has been in the sysadmin world for decades. You have many machines under your care. One of your machines is a fax server that sends hundreds of faxes a day. Your operating system is going through the pre-release stages of getting a new major release out which has many new features and many changed features, as you might expect in a change from release 7.2 to 8.0. A release candidate for 8.0 is announced, so you grab it.

So far, all is good. But then you blindly upgrade your one fax server to the release candidate and discover that the completely new (and not at all secret) serial I/O system doesn’t work quite right with your hylafax setup. You already know, from at least 10 years of experience with it, that hylafax is demanding and that issues with the serial hardware or software result in bad things happening.

This is where you are supposed to say, “Oops, silly me. I should have learned not to do that by now. Quick, let’s unwind that to a known working setup real fast before this turns into a disaster.”

But no, this person decides to conduct pointless experiments instead of unwinding his mistake. And he also finds spare time to complain to the providers of the free operating system he has relied on for so long.

This just doesn’t make any sense to me. I’d love to think that people could learn from their own mistakes and even from other people’s mistakes—but sometimes that seems like a foolish dream.

And yes, I deliberately avoided mentioning names or providing URLs. I’m not interested in having a go at any individual, just using a real current case as a cautionary tale.

Posted at: 14:36

Path: /software/discuss   |  permalink

Sun, 15 Nov 2009

Apology to Apple: I Was Wrong

Earlier today, I whined about Apple’s deletion of the line-in port on my MacBook Pro. Today, while fiddling with sound settings, I discovered by accident that there is a line-in port.

Careful inspection of the case showed only one possible candidate, clearly labelled for audio output. Just for giggles, I plugged in an audio input and told QuickTime to record it and presto, that worked.

It still seems silly to make one receptacle do dual duty, but I can live with that. It seems worse than silly to mislabel it, but at least I now know that it serves two functions. Hopefully, anybody who took any notice of my post yesterday will now know the truth.

Posted at: 15:33

Path: /technology   |  permalink

Apple Gives With One Hand

A few months back, I bought a MacBook Pro for a bunch of reasons of which the most important was my expectation that I would be able to just do things when I wanted to. That expectation has been largely met and — apart from the usual annoyances arising from the irritating OS-X user interface and its inability to be configured to my taste — I’ve been quite pleased with it.

A couple of days ago, I wanted to do something and immediately thought of the MacBook as the enabling tool only to be thwarted by Apple’s decision to remove the audio line-in jack from later models of the MacBook Pro. Yes, they added a couple of other trinkets to compensate, but still this deletion is incomprehensible to me. If they had actually run out of space on the edges of the beautiful case, I’d have understood; but there’s plenty of room left.

Yes, I can probably buy a USB sound thingy and expect it to work, but my visitor wanted a copy of an old audio cassette with an interview that we’d done in the past and I had thought it would be easy to manage on the spot, having been sure that I’d seen somebody with an audio cable plugged into a MacBook Pro in the past — it hadn’t occurred to me to check that my more recent machine had the same capabilities.

Posted at: 07:27

Path: /technology   |  permalink

Thu, 05 Nov 2009

Firefox Keeps Finding New Ways to Fail

I have been using—and whining about—Firefox since it first appeared. It has improved in many ways since the early days, and I am pleased about that. But it still finds new and astonishing ways of driving me crazy.

I have been using a Ubuntu-badged variant with the ridiculous name Shiretoko, and it appears to be based on Firefox-3.5.3 (which I know is not the latest, but it’s pointless going through upgrade pain when I am on the verge of changing a few other elements of my desktop—new motherboard, new memory, and a non-Linux operating system).

The new misfeature in this Firefox is that it constantly appears to freeze, for between 8 and 25 seconds. This is sometimes accompanied by greying out the Firefox windows, which seems to say that Firefox knows that it’s dragging its feet. The only good thing is that, whatever it happens to be doing while it’s doing nothing useful, it doesn’t also elect to bring the rest of the machine to its knees—all other windows and processes are able to operate quite normally while Firefox is thinking. (Which is why I’m able to write this as I wait.)

The machine is a quad-core 64-bit Intel thing with 8 GB of memory, so it should be more than enough to handle simple web browsing. By simple web browsing, I include accessing static web pages on my LAN, which is also afflicted by this bizarre behaviour.

A partial list of the activities that provoke this behaviour includes: pressing a key to scroll the page down; clicking on anything; attempting to grab a scroll-bar to do the obvious; typing in an input field; and so on. This makes net banking a fraught and perilous exercise, as it’s necessary to wait for up to 30 seconds to see if the click you made was actually registered or not—you don’t want to be clicking bank buttons more than once, but it’s not a lot of fun if the bank website times you out near the end of some complex transaction while you waited to see if your click was being processed.

It’s almost enough to make me go back to bricks and mortar banks. It’s certainly enough to make me hope I can get some other software installed pretty soon. And it’s certainly sufficiently annoying that I’d be hard-pressed to maintain my normal exemplary politeness if I met a Firefox developer any time soon.

Oh, that bit about my normal exemplary politeness was a joke. Just so you know.

Posted at: 18:13

Path: /software/discuss   |  permalink

Wed, 28 Oct 2009

Two Weeks of Dspam

It’s now two weeks since I setup dspam-3.9.0-BETA1 to handle my home network’s incoming email and it’s time for a review. I began by training dspam with a recent corpus of about 70k spam messages and 10k ham. Then I passed everything through dspam and checked its accuracy.

In my home situation, we can live with some missed spam turning up in our inboxes, but we can’t live with false positives. Dspam made one false positive out of 11,873 messages processed and that was in the first few hours. I’m ready to stop checking for false positives now and have started just dropping the spam on the floor.

Over the two weeks, I’ve only seen 17 spams per day out of the 435 that get delivered; and my wife has only seen 4 per day out of the 320 that are delivered for her. I’m calling this a great success and have decided that it’s sufficiently good that I don’t need to implement any other anti-spam measures at all.

The minor downside with the methodology I’m using is that any false positives will never be reported to anybody now that the testing phase is over. If anybody sends me a genuine email that dspam thinks is spam, I won’t see it and the sender won’t get a bounce. I can live with that.

Posted at: 15:16

Path: /software/discuss   |  permalink

Wed, 14 Oct 2009

Clawing Back Time

I have a project to reduce or eliminate some of the things that take up a fair bit of time but which don’t seem to provide commensurate benefits. This project advances in fits and starts, but today sees a couple of steps forward.

The second thing I did was to deactivate my Facebook account. That was quickly done, although I did need five attempts before I got a captcha that I could decode to complete the deactivation process.

The other thing, which took most of the day, was to setup a new dspam installation to help in the fight against the incoming deluge. I’ve been a keen dspam user for ages, ever since I setup a test installation to see if it had promise. Finally, I’ve updated it to the latest version, put it into place properly, trained it on a corpus of 10k ham and 70k spam that I’ve carefully assembled over the past few weeks, and am now watching it do an almost perfect job.

So this is all good. Now I need to move on and do some of the things I want to do with the free time—but first we are having a little holiday for a couple of weeks.

Posted at: 22:09

Path: /society   |  permalink

Sat, 10 Oct 2009

Mail Client Software Keeps Getting Clunkier

There was a time, before the WWW, when email client software was clumsy beyond belief—those who remember the original mail command and UUCP bang-path email addresses will know that things improved over a decade or two.

Then, with the growth of the Internet, graphical mail user agents (MUAs) appeared. Some of them were better than others, but they all suffered from some irritations. At the same time, the text-based MUAs continued to be developed.

Then, just when you might have expected that we were on the threshold of some really good software, things just stopped. I like to blame Microsoft for developments that I don’t like, but I don’t know if that’s fair in this instance and it’s not really important.

One of the early graphical MUAs was Exmh and, despite some clunkiness, it was a pretty useful utility. So much so that I persuaded my wife to use it when she decided to enter the email age. And she has been happy with it for about twelve years. I also used it for a few years, but eventually changed to a text-based MUA as I found myself dealing with ever-increasing quantities of email and discovered that I preferred the speed of the keyboard over the purported convenience of the mouse.

And there things stayed for several years. Recently it became necessary to update my wife’s computer—it was a seven-year-old box running an almost equally old operating system and the hardware was almost on its last legs and some of the software (e.g., Mozilla-1.x, OpenOffice-1.0) was simply inadequate to handle modern websites and data. And there were also more than a few security vulnerabilities in the operating system.

The search for a replacement, which she wanted to be silent, first led to selection of a Sunray thin client workstation. A number of factors resulted in the abandonment of that plan, but one thing that happened while I was exploring it was the discovery that Exmh, which has not been further developed since version 2.7.2 was released in January 2004, was probably not going to be an option on the intended Solaris platform.

That was no surprise, since it’s what happens to older software that doesn’t match the dominant design. So it became necessary to research alternatives that she could live with. There’s no shortage of choice and I won’t list any of them here. Where there is no choice is in the user interface—yes, there are differences, but they are insignificant against the overall architecture. And all of them, although faster in things like actual message display than Exmh, are much slower and more painful to use. I tested several and reviewed all those I could discover and they were all the same.

Eventually, I set up the one I thought best (for various other technical reasons not relevant to this discussion) and tried to teach my wife how to work with it. This was a disaster. She was already upset about the other changes I was going to force on her for the “upgrade”, but she uses email frequently now for her work and the modern software simply didn’t cut it for her.

Fortunately, the Sunray project died for other reasons and I had to find an alternative. And that machine, an Eee PC that was originally intended for me, runs Ubuntu and still provides Exmh as an optional package. Crisis averted. For now.

Sadly, I see no signs of any of the MUA authors making any effort to make their software more functional—adding bling is popular, but you’d think these people would use their software and would get frustrated with its clunky behaviour and would therefore want to improve it.

I still hope that something better than anything we have now will arrive in the next three to four years so that, the next time I have to upgrade my wife’s computer, I’ll be able to introduce her to a new MUA that she will be able to learn to like.

Posted at: 10:03

Path: /software/discuss   |  permalink

Tue, 06 Oct 2009

An Error of Thumb

Late last night, as I positioned our largest sharp kitchen knife to make a cut, I thought to myself, “If I observed somebody else holding a knife like this, I would warn them about the risk of injury that was attached to such incorrect knife usage.”

Moments later, as I was trying to stop the blood spurting all over the kitchen, I realised that I could now complete my warning with a remark about how effectively I had demonstrated the said risk. Fortunately, since I was holding the knife in my more dominant hand, the thumb I attempted to sever was on the less dominant hand. But it still keeps getting in the way and every bump sends urgent don’t do that messages to what passes for my brain.

That makes two “accidents” with that knife in two months. It might be time to learn a lesson while I still have the usual number of thumbs.

Posted at: 09:56

Path: /random   |  permalink

Wed, 30 Sep 2009

Another Go At ZFS?

A few days ago, I wrote: “I’m going to install Ubuntu and fuse-zfs on one of my machines …” To my surprise, especially in the absence of comments on this blog, I got quite a bit of feedback about that idea—all of it indicating that this idea would fall well short of my expectations for ZFS.

What to do? One idea that has occurred to me is to tentatively blame the motherboard/memory in the system that was giving me grief under OpenSolaris. That then allows me to justify buying another motherboard, new memory and video card and having another crack at running OpenSolaris with native ZFS on my workstation.

I’ve bought those bits and pieces and plan to install them and experiment in the very near future. In the meantime, I will continue my planned server setup on a different box that will also run OpenSolaris and ZFS, but that machine won’t be bothered by pesky irritants such as a screen or keyboard. I expect it to behave nicely. As for my desktop box, we’ll have to wait and see.

That will also force me to learn to love OS-X since my MacBook Pro will be pressed into service on the desktop for a while. Perhaps I’m not too old to learn new tricks …

Posted at: 18:37

Path: /software/discuss   |  permalink

Fri, 25 Sep 2009

Using Linux and Wanting ZFS

I’ve been using Linux in a limited manner for about four years, meaning that it has been installed on at least one machine that I use fairly regularly over that period. In common with all the other operating systems that I have used, it has its good points and its shortcomings. But, in recent years, the strengths have got stronger while also becoming more important to me and many of the weaknesses have been addressed.

However, it has been what I now regard as the failure of my attempts to make friends with Solaris Express and OpenSolaris during some quite intense attempts over the last year that has forced me to look hard at Linux as my main operating system for the near future.

There is just one serious fly in the ointment—the unfortunate fact that none of Linux’s multiplicity of file systems is a match for Sun’s ZFS. At first, I thought ZFS was something that was at least theoretically a good thing, but its unfamiliarity made it seem like something that you could live without. However, in a remarkably short time, ZFS becomes ridiculously easy to use and that’s when I started to see just how big a step forward it is. I really don’t want to go back to old-style Unix file systems.

Unfortunately, due to the old wrangles over which open source licences are good and which are not, the Linux people don’t feel able to adopt ZFS. I see that btrfs is being developed and that it is hoped that it will bring the features that I love in ZFS to Linux. But btrfs is years away, and I need a file system today.

I’m going to install Ubuntu and fuse-zfs on one of my machines at the start of next week to see how well that combination works. It’s far from ideal—fuse-zfs has been pretty well abandoned, as far as I can tell; and it is well behind the zpool/zfs versions that are now in Solaris. But if it works well enough I’ll give it a go and then I’ll cross my fingers hoping that Sun might fix the ZFS licence problem as they have finally managed to do with Java.

My other option would be to setup a server running FreeBSD with their implementation of ZFS and to use it as a file store for my Linux desktop machines. I’d rather just run Linux, but we’ll have to wait and see.

Posted at: 13:41

Path: /software/discuss   |  permalink

Wed, 23 Sep 2009

Perils of Perfectionism

I began this blog in May 2004, largely as an experiment to see if this new-fangled blogging thing was something I wanted to do. I kept at it, more or less, until the end of 2007—by which time I’d decided that I did want to continue blogging.

And that’s when things went wrong. I had already more or less decided that I really needed two blogs—one for more technical material and one for all the rest. And I knew that I wanted some features that were not provided by the simple software that I had been using for my experiment. So it was then just a simple matter of choosing names for the new blogs and selecting one of the full-featured blogging platforms and I could get on with things.

Almost 20 months later, and I’m still wrestling with these weighty questions. And I’m completely out of what habit I had developed of writing. I have chosen and then rejected about a gazillion names for the new blogs; and I have chosen and then rejected and then re-chosen and then re-rejected just about every blogging platform in existence. Nothing seems to be just right for my needs.

And so, even more belatedly than I often manage to achieve it, I have come to realize that my perfectionism has become the obstacle to getting anything done.

The way forward from here now seems clear—I will resume writing posts in this blog (in a new location, but retaining its original URL) and when I make those difficult decisions about names and blogging platforms, I’ll announce them here and allow this blog to rest in peace.

Posted at: 17:24

Path: /meta   |  permalink

Fri, 21 Dec 2007

Xmas Parking Perfection

At this time of year, pressure on parking spaces at Indooroopilly (and no doubt other shopping centres) gets pretty intense. But this morning there were a few spaces available in the reserved parking outside the post office for people to use when collecting their mail from the PO boxes there.

Even so, the hero of this story felt that the effort of parking her tiny car in a marked space was too much, so she just stopped in the roadway, locked her car and dashed across to get her mail. By the time she had the box open, both owners of the cars she had blocked had arrived at their cars and were looking a bit irritated to see they had no way out. However, everybody relaxed as the pest dashed back to her car with her mail.

This was when she discovered that she had managed to lock her keys inside the car. She had also locked her phone in there with the keys. So she then borrowed a phone from one of her victims, eventually worked out what number to call for information, got the number for RACQ, called them, waited for a bit and finally reported that they would be there—probably within an hour to an hour and a half. The trapped owners were as ecstatic as you might expect. All the cars that had to squeeze past were looking unhappy. And I had emptied my PO box by then, so I went home.

Posted at: 10:21

Path: /cars   |  permalink

Wed, 08 Aug 2007

Code Craft falls down hard

I know it’s not possible to write a big book without having any errors fall through the cracks, and I don’t make a habit of public excoriation of people for things that can be forgiven — but there are unforgiveable things.

Take Code Craft by Pete Goodliffe, published by No Starch Press as an illustration. Here we have a 580-page tome dedicated to the practice of writing excellent code and on page 13 it has an egregious example of unforgiveable content.

Before getting to the details, I would mention that neither the book nor the website give me any information that I could find in a reasonable amount of time about how to report errata. Had there been such an avenue, I’d have taken it. As it is, this seems the easiest approach.

This is in Chapter 1, On the Defensive, subtitled Defensive Programming Techniques for Robust Code. Under the heading Use Safe Data Structures, he gives the following example of some C++ code:

    char *unsafe_copy(const char *source)
    {
        char *buffer = new char[10];
        strcpy(buffer, source);
        return buffer;
    }

He then gives the correct explanation of the problem with this code when the length of the string in source exceeds 9 characters. After some discussion, he then says it’s easy to avoid this trap by using a so-called “safe operation” and offers this idiotic solution:

    char *safer_copy(const char *source)
    {
        char *buffer = new char[10];
        strncpy(buffer, source, 10);
        return buffer;
    }

In case the reader doesn’t know how the C string library (which is what is being used here, despite the otherwise C++ content) works, let me point out that strncpy is guaranteed not to solve the problem under discussion. The strncpy function will only copy at most the specified number of characters, but — in the critical case where the source string is too long — it will not add the very important NUL-terminator character. And so users of the returned buffer will still fall off the end of it and cause breakage.

Every C or C++ programmer who has been paying attention knows what is wrong with the C string library and knows how to use it correctly. So an error of substance like this should simply never have happened. It’s not a typo. It’s not a trivial error. It’s just plain wrong. And there’s no excuse for it.

I’m sure the author has many good things to say in this book and many of the sentences I have skimmed certainly do make sense. But stuff like this makes it impossible for me to suggest that it has any place on the budding programmer’s bookshelf. That’s a shame, because we need books that do what this book purports to do.

What irritates me most about this is that none of the book’s reviewers spotted this glaring error and none of the online reviews that I found noticed it either. This means that nobody with even a tiny clue has been looking at it.

Posted at: 10:52

Path: /software/discuss   |  permalink

Wed, 04 Jul 2007

Python 3000

About three years ago, I announced my plan to move away from Python for future development work. I returned to that theme twelve months ago in a couple of posts about recent experiences with Python.

It seems time to update things now. I have just been reading Guido van Rossum’s Python 3000 Status Update in an attempt to understand what the future holds for Python.

Clearly, the Python people have decided to make major changes to Python, such that software written for Python-2.x will need work if it’s to be expected to run on Python-3. Equally clearly, a great deal of work has gone into creating mechanisms to assist programmers with the necessary translations when the time comes and that’s something I applaud.

However, I have long been unhappy with Python’s continual introduction of what I see as gratuitous changes and have been looking at alternatives. Now seems like the time to jump ship. My plan now is to do some serious testing with alternative languages so that—when the time comes for me to write some new thing—I will be ready to do it in some non-Python language.

This post is just to mark the point where that decision was finally made and to link to the Python 3000 paper that marked the tipping point.

Posted at: 17:02

Path: /software/discuss   |  permalink

Wed, 30 May 2007

A new approach to spam filtering

About three years ago, I first considered DSPAM as a potential solution to the incoming tide of spam that was drowning me and that was increasingly overwhelming SpamAssassin, my then tool of choice. I wrote a couple of blog entries that discussed my research and included references to papers by Jonathan A. Zdziarski (the author of DSPAM) and Gordon Cormack (who, with Thomas Lynam, wrote an evaluation of anti-spam tools). I also mentioned some of my discussions with both Zdziarski and Cormack and said I would report more when I had more information.

Much time has passed and the spam problem has, as we all know, continued to get worse. Last December, having become completely fed up with the worsening performance of SpamAssassin, I decided to install DSPAM for testing. I elected not to bother training it, but allowed it to do its thing and contented myself with informing it of its errors. The downside was that I had to look at every incoming message, whether spam or not, to be sure of the classification. I have examined 82,931 messages in the last five months and I’m amazed at how well DSPAM works.

Overall, it has caught 98.92% of all spam and its false positive rate has been 0.02%. Most of the errors were in the first and second months while it was learning. Now, it is catching over 99.2% of spam with a false positive rate below 0.01% and there have been no false positives at all for a couple of months. For my wife, the learning was a little slower because she receives much less total email than me and her legitimate email volume is so small that it’s a bit of a challenge to get enough for training. However, even in her case, the detection rate is up to 98.90% and false positives have also disappeared.

I was going to modify qmail to reject messages that were deemed to be spam, but I’ve decided that it’s too much work, given the ickiness of the qmail code and the excellent performance of DSPAM. I also toyed with the idea of changing MTA, but I have not found an MTA that I would be willing to use that also has the ability to do what I want. I may one day decide to write my own MTA for in-house use, but for now I’m going to stick with qmail and the other modifications I had made to it in the past and—starting right now—I’m going to stop my practice of reviewing incoming spam in case any legitimate email is lurking there.

In other words, from now on, if anybody emails us and DSPAM thinks it’s spam, nobody will ever see the message. There will be no bounce, there will be no error message, there will be no sign that the message was lost. But it will be irretrievably lost. I have decided that the time spent on reviewing the spam is not worth the rewards, when the chances of finding a real message seem to be less than one in a million now. This is especially true when it’s also true that anybody who might need to contact us and who we would care to hear from has other methods of doing so.

I am really delighted to have got to the point where my spam load consists of hitting ‘S’ once a day to tell DSPAM about something it has missed.

Posted at: 14:46

Path: /software/discuss   |  permalink

Fri, 20 Oct 2006

Software quality

It’s hard to find examples where the two words in my title belong together. People of all kinds–users of software, software developers, and those who teach the next generation of developers–have been pontificating about both the problems with software and various approaches that might help to solve the problems for decades. But, as a general rule with almost no exceptions, software still sucks. And it’s getting worse, not better.

Anybody who happens to read this already knows that software is a problem since they have to be using quite a bit of software just to be reading a blog–and it’s my contention that just using software is enough to drive you to drink.

I’m a software developer, so I am fully aware of the difficulty of creating high quality software. It is indeed difficult to produce software with no bugs and, for most software, it’s probably impractical–or at least not worth the cost. But that’s not to say that the quantity of bugs in the stuff we all have to deal with every day is justifiable.

Here are a couple of examples from some of my appliances. I have a DVR. It has a 60G hard disk and a DVD writer. And it doesn’t have to do much. So why does it take 30 seconds to boot up? Why does it have to boot up after making a recording? Why can’t I set it to record something that starts less than five minutes after the previous item? Why can’t it sort titles alphabetically using the same rules as anybody else?

To elaborate on the last point, as it’s a classic example, consider the following list of titles:

• Apple
• Apple Tree
• Azimuth

That’s sorted in the way that any sane person would expect. Getting software to sort it that way is child’s play. The Unix sort program will sort it that way by default. So what does my DVR do? Behold:

• Apple
• Azimuth
• Apple Tree

I’ve had enough time to study its behaviour now, so I can choose titles for things that it can sort the way I want–but it’s completely crazy that I should ever have been driven to think about this. I don’t want to belabour the point about this one appliance too much, so I’ll limit myself to one other bizarre fault. It has, as I mentioned earlier, a 60G disk. So it can store quite a number of off-air programs for viewing at more convenient times. Well, it could do that if it didn’t have a limit of 7 recording slots. That’s right–seven. The first VCR I ever owned, more than 20 years ago, could be programmed for more than seven recordings.

I’m sorry, I lied. I’m going to mention one more thing about this device–because it’s faintly possible that this is a deficiency in the hardware rather than the software (not that I believe that for a minute). The advertising material and the manual for my DVR claim that it can copy between media at accelerated speed. That seems to be a reasonable capability, given what we know about other such equipment, so I expected it to work. But it doesn’t. Copy an hour of video from the hard disk to a DVD and it takes exactly one hour. Copy an hour of video from a DVD to the hard disk and that also takes exactly one hour.

And, for another instance that might be hardware but probably isn’t, consider the fact that it makes DVDs that quite likely can’t be read by at least a few of the 8 other DVD readers in the house. Sometimes, to show just how clever it is, it can make a DVD that it can’t read itself. And when that happens, the only way to get control of it again is to remove the power and physically remove the offending disk.

That device has a flotilla of other hideous bugs that make it a nightmare. My wife just leaves it to me to drive it. She is pretty smart.

Now, let’s turn to my phone. No, let’s not. At least, not beyond mentioning that it’s slow and as buggy as hell too. Having once worked as a consultant for one of the mobile phone manufacturers–where my task was to teach their programmers C and to help them with some of the interesting bits of their software–I’m not surprised to see that this phone has software that I wouldn’t spit on.

The trouble is that software is ubiquitous in our world. Even if you never touch a thing called a computer, you can’t escape it. So you’d imagine that we–the software creators of the world–would have figured out some of the basics of making software by now. But we simply haven’t come close. And nothing I see in our tertiary institutions makes me think that’s about to change all of a sudden.

One of the good things about the world of software is Free Software. (For anybody who doesn’t recognise why those two words were capitalised, have a look at this definition for some insight.) Sadly, the Free Software people are at least as bad as the rest of the software community when it comes to quality. The Free Software crowd have a bunch of silly slogans written by would-be philosophers without much insight such as the famous “Given enough eyeballs, all bugs are shallow”, usually attributed to one of the worst poseurs in the community.

The problem is that bad software is much easier to get done than good software. Of course, if you consider the subsequent investment of time by the software authors while they try to address the worst bugs, then the apparent speed of the favoured method seems less of a sure thing. And, heaven forbid, if we considered the time lost by the unfortunate users of this software, then the equation becomes ridiculous. Time spent on whatever process we can find that results in fewer bugs going into the product will be amply rewarded. And, as many people are now showing, it is almost certain that taking the time to get it right in the first place will be quicker than rushing bug-infested rubbish out the door–certainly once the developers have had time to become established in this new pattern of work.

Just as I avoided listing brand names of my appliances above, I’m not going to single out individual pieces of software for criticism here. But it’s pretty safe to say that any high-profile piece of software is almost certainly riddled with thousands of maddening bugs. And the bigger the software, the worse it will be, for reasons that will be obvious.

As a final comment on the sad state of things, I’m going to look at the state of programming languages–again without naming names. I’m not talking about the suitability of our languages for developing great software, although that is indeed an important matter. I’m just talking about the woeful state of the software in the interpreters and compilers themselves. I recently acquired a 64-bit computer, not so much because I needed the extra capabilities it had, but to use as a platform for me to use to weed out any little buglets in my own code that might be exposed by a 64-bit machine. As it happens, I have not found any. But I have been amazed at the number of languages that I wanted to use in my testing that are simply not able to run on a 64-bit platform, despite the fact that 64-bit systems have been around for years. And not to mention all the other applications that are not yet available for my 64-bit platform. This is really sad.

And it’s so bad that, in the next few weeks when my operating system comes out with its next release, I’m going to install the 32-bit version on my workstation so that I’ll be able to use all the stuff I want to use.

I’ve been working all my life at continuing to improve the way I do things. I will keep doing that. I’m happy to talk with people about ways of improving software. And I really think it’s way past time for the software development community to get off its collective butt and to start looking hard at injecting quality into software.

Posted at: 17:35

Path: /software/discuss   |  permalink

Thu, 31 Aug 2006

Another Apple recall

Shortly after I got my Powerbook, just over two years ago, Apple recalled its battery because of some fault that I no longer recall. This week, I discovered that the replacement battery is now subject to a recall. So I have to order my replacement, wait for six weeks for it to become available, respond in person within 48 hours of being informed that my new battery is ready and take care in the meantime not to leave the machine on with its battery installed unless it is under supervision. That’s a pain. It’s a bigger pain that I’m looking at a recall for the same component that has been recalled once already. I just wanted to whine on the record.

Posted at: 16:20

Path: /technology   |  permalink

Tue, 29 Aug 2006

Lying to customers is so easy

A couple of years ago, I wrote about a customer of mine who had problems with their ADSL provisioning. For much of this month, the same customer has had further problems with the same so-called service.

The trouble started around 11 August when their ISP performed some unspecified maintenance on the ADSL services in the region where my customer has their offices. In the middle of the night, their connection went down. They complained to the ISP, who promptly blamed Telstra. Neither the ISP nor Telstra wanted to do anything about the problem.

After some days, and several followup calls, the ISP stated that the problem was definitely in the customer’s ADSL modem. The customer shipped the modem to me. I plugged it in as a replacement for a different breed of ADSL modem attached to a computer running the same OS and ancillary software to connect to the same ISP and it just worked. Clearly, the problem was not the modem. To be on the safe side, I then performed a hardware reset on the modem, reconfigured it as required, and returned it to the customer. It did not solve the problem.

The customer then tried to insist on some service from the ISP, but found things difficult when the ISP made it clear that they do not do house calls under any circumstances. Eventually, the ISP told the customer that they would check the modem if the customer attached it to a Windows computer and followed instructions. The customer sourced a Windows computer, plugged things in as required, followed instructions (including another hardware reset of the modem), and then the ISP said, “There, that’s all it needed; we just had to fix the modem and now it’s fine.”

It’s clear enough to me that they did nothing to the modem (beyond getting the customer to break its configuration for our purposes) and instead finally got around to fixing whatever they had fucked up at their end. Of course, this meant that the modem still didn’t work when returned to its normal position and it was returned to me to be reconfigured a second time. When it finally arrived back at the customer premises, it was plugged in, powered up and just worked.

By then, it was the 24th. So they were off the net for two weeks. There was no apology from the ISP. There was no offer of any reduction in the exorbitant monthly service fees they charged. The ISP lied to their customer and stuck to their lies. I’m not going to name either the ISP or the customer, as the argument is between them and it’s none of my business—other than as an astonished bystander. But I will certainly recommend against that ISP if people ever ask me for my opinions about possible service providers.

Posted at: 17:26

Path: /technology   |  permalink

Sat, 15 Jul 2006

Further thoughts on Python

I posted an article recently that took a swipe at the direction of Python development. Had I realized that it would be seen by people on the Python developers list, I’d have phrased things differently—I treat this blog as a private repository of my thoughts about various things and assume it will be mostly read only by people who know me. This post is intended to explain my position a bit more clearly and to take into account some of the responses from the Python developers.

I’m going to start by outlining my position and my expectations so that those people who seemed baffled by my stance can have a better opportunity to understand this stuff. Then I’m going to discuss a small fragment of the responses on the mailing list. And I’ll finish up with my thoughts about the future.

At the outset, it would be useful to understand that there’s nothing personal in anything I say here—I’m simply stating my take on things. I know I’m far from a typical Python user, and I’m certainly not trying to suggest that everybody should do things my way or even agree with me. Although I would hope that people would agree that I’m entitled to hold my own opinions.

I’ve been developing software for commercial clients for about 25 years and some of the code I wrote twenty years ago is still in daily use in business environments. I take a lot of care to make my software into a stable and useful tool that allows its users to conduct their normal processes in the way they want—I do not believe that customers should twist themselves in knots to adapt their way of doing things to the software that somebody tosses on their lap.

Sometimes, this whole process is straightforward. The customer has a stable hardware platform and I provide stable software and their process undergoes minimal change—and their entire platform is isolated from the big bad world. In these cases, we might see the same old hardware running for 15 years or more with unchanged operating system and application software. Nothing will go wrong there.

In other circumstances, customers run their business processes on systems that are exposed to the Internet and need to keep their operating system and basic utilities up to date in order to avoid exploits. This can result in unexpected updates of things that my software might depend on—such as a new version of Python or, to take another real example, an updated Unix C compiler that introduced a gratuitous change in the format of floating point values that resulted in a database where all values were suddenly multiplied by 4.

Since I use a large number of software packages on my systems (over 500 at present), it’s completely impossible for me to keep fully informed about all the evolution that goes on in all of them. I am a contributor to a small number of free software projects and I do take seriously my responsibility to test them. But I just can’t do that for everything I use if I am also going to do my day job. So I have an expectation that my tools won’t introduce gratuitous change into my world.

What puzzled me about some of the responses on the Python developers list was that people felt entitled to take a swipe at me for expecting bug free software, despite the fact that I had clearly explained that I was not complaining about a bug—all software has bugs and I understand that they must be fixed when found. My complaint was about a change in behaviour from a function that had no bug in it.

Fortunately, Guido van Rossum (the Python benevolent dictator) is a lot smarter than the chief Perl weenie and knows how to read for the real content. He recognised that the issue I was complaining about was something that had bitten him in the past and he requested that it now be fixed. I understand that a fix is scheduled for Python-2.5 when it comes out.

I understand the desire of the Python community to continue to develop their language. (I think they’re wrong, but I’m in a tiny minority and I have no intention of trying to convert the majority to my opinion.) What I find problematical, however, is their willingness to break working code as part of this process. I complained the other day about the change in behaviour of time.strftime(). I was previously bitten by the bizarre change to the fcntl interface. Where once you had to import FCNTL, fcntl and then used a constant called FCNTL.LOCK_EX (as one example), things changed so that the FCNTL module disappeared and the constant changed to fcntl.LOCK_EX. I never bothered to discover the official reason for this change, but I stick to my view that it was completely unnecessary.

It’s one thing to extend the language and its support libraries. And I have no argument with that at all. And it’s fine to fix actual bugs in the existing code. But making changes that are guaranteed to break existing correct code is just insane, as far as I’m concerned.

As another example of inexplicable change, I would mention the change in meaning of the division operator. It doesn’t matter if, in hindsight, you see that it would have been nicer to do something differently—once people are using your language, you have to leave it alone. Or else they will do what I’m going to do. I’m going to lock my customers into Python-2.3 for now and then I’m going to migrate all my Python code to a language that doesn’t go in for this kind of breakage.

Ironically, had I used awk for the software in question, I’d have had no problems at all. But Python was new at the time and arguably nicer to write and had two minor but useful features that were missing from awk, so I decided to develop a collection of software using Python. I don’t regret doing that, but it’s definitely time for me to move on now. That’s not just because of the small number of issues that I’ve discussed here, but because of the looming arrival of Python 3000 which sounds like far too dramatic a change for me to want to keep up with it. If I have to deal with that level of change, I’m going to be far better served by choosing a more stable environment for the future work.

Posted at: 12:09

Path: /software/discuss   |  permalink

Sun, 09 Jul 2006

Python loses the plot

In Python’s early days, I saw it as a fine addition to the programmer’s toolkit—it seemed to offer the good things that Perl offered, but without the gruesome syntax and other Perl perversions, and the Python benevolent dictator and community seemed to have a good plan for the future.

As a result, I began developing most new large applications in Python, with the occasional bit of heavy lifting in C as needed. This approach worked well for some years. But then the wheels slowly started falling off—and yesterday’s experience has pushed me to the point where I’ve decided not to use Python for any new development. This leaves me with a dilemma, of course, as I don’t have any suitable candidate for a replacement.

So what’s my beef? In a nutshell, it’s gratuitous changes that break code that was once correct when it’s exposed to a newer Python release. This disease has afflicted Python for some time, although I have been lucky enough to have only been bitten once before. Yesterday was my second experience with this kind of breakage and I’m going to make it my last.

For those who care, the behaviour of time.strftime() changed in Python-2.4 in a really silly manner. I have a module that asks the user for a date and then parses the elements of the provided date to ensure that we in fact have a valid day, month and year. I then used time.strftime() to format it in a specific manner. Because I only had 3 of the possible 9 elements of the argument passed to this function, I had been using what used to be the documented values as place holders. As of Python-2.4, that is suddenly no good.

Clearly, I can work around this. But then they’ll break some other standard function that I’ve been using and I’ll have to work around something else. And so on. There is no legitimate excuse for this kind of arbitrary change. It’s impossible to code in such a way that you won’t be bitten, and there’s too much new software coming out every day for developers to have the time to waste reading all the fine print just in case some idiot has broken some standard API.

My interim solution is to change the first line of all my scripts from #!/usr/bin/env python to #!/usr/bin/env python2.3 and, in the longer term, I’ll find a suitable alternative language to work with. I’m certainly finished with Python.

Posted at: 16:50

Path: /software/discuss   |  permalink

Wed, 05 Jul 2006

Consistent errors with prescription medicines

I wonder what is the cause of the consistent errors I have seen with pharmacies dispensing the wrong medication or the wrong doses of the right medication in the past nine months? I’ve never seen either kind of error until recently, but the last few months I’ve been given something wrong four times out of five—not just at the one pharmacy and not just the one person when the error has been repeated at the same pharmacy.

It’s not a result of the infamous doctor’s bad handwriting, as these prescriptions and their repeat authorities have all been nicely computer generated and printed. Whatever the cause, it’s a worrying trend.

Anyway, for what it’s worth, I strongly urge everybody to be vigilant in checking that what you receive is what you expected to receive.

Posted at: 13:58

Path: /society   |  permalink

Tue, 30 May 2006

Native driver for nVidia NIC saves the day

As distributed, FreeBSD for the AMD64 platform comes with a rather dodgy driver for the on-board nVidia nForce MCP NIC that appears on many motherboards for this CPU. In my case, the symptoms were trillions of device timeouts and weird unresponsiveness under Gnome and bizarre keyboard malfunctions—lost keystrokes and occasional cases of keys repeating hundreds or thousands of times.

Some research quickly established that these issues were well-known and that there was a revised version of if_nve.c that was supposed to address these concerns. Unfortunately, simply replacing that file with the updated version resulted in a kernel build failure, as other stuff was required. Since that other stuff was supposed to live in a directory that doesn’t even exist on my machine, I decided to try plan B.

Shigeaki Tagahira has developed a FreeBSD native driver, based on the OpenBSD driver. Today, I built that and patched my kernel with his ciphy patch for the Cicada PHY and am pleased to say that the odd behaviour I was seeing now seems to have been cured. This is great news.

And yes, this is a bit boring, but I wanted to record the essential data in case I blow away my installation and forget how to rescue it. Aren’t blogs wonderful?

Posted at: 18:28

Path: /software/discuss   |  permalink

Fri, 26 May 2006

Rewrite it or fix it?

I’ve been reading Adrian’s series of articles on XP with considerable interest. I’ve found it interesting to see how somebody I know has got involved with this approach to software development and I’ve felt that there were lots of good lessons there.

But I was a bit taken aback by something in a recent entry, Framing The XP Principles:

Netscape has all but gone out of business because of one bad technical decision to rewrite their entire browser instead of taking small steps and fixing the existing one.

Now, before I launch into my speculations here, I should point out that I’ve never worked at Netscape and I’ve never worked on any of the Mozilla products—although I have occasionally skimmed parts of their source code. So what follows is purely my guesses, based on what I can see from outside.

On the other hand, I have worked on a number of big projects where a decision was made to throw out some existing implementation in favour of a complete rewrite—and I’ve seen such projects succeed.

I am satisfied that the old Netscape code base was rubbish. I am also convinced that it would have been insane to attempt to fix it. Where I think Netscape went wrong was in failing to learn anything from the first time through. From where I stand, they seem to have embarked on another gigantic piece of junk without getting hold of the right people or developing a sensible plan. It’s clear to anybody who uses or who has the misfortune to need to build something like the current version of Firefox that this new code is pretty nearly as bad as the old code. Of course, it is better—but not significantly better. It’s much more like the old rubbish than like something that we’d all be proud to be a part of.

I have no way of proving my point, of course. And I don’t care that much about the specific case. And I certainly agree that it’s better to refine a code base as a general principle rather than to automatically throw it all away. But I think it’s important to recognise that there are real cases where it is better to discard even a huge code base than to get lost in a vain attempt to “fix” it.

Naturally, if the decision to rewrite is taken, it should only be done if there is a clear commitment to first learn the lessons from the failed implementation and to create a design and a methodology that have a reasonable likelihood of success.

Having said that, I now await Adrian’s next instalment with interest.

Posted at: 17:37

Path: /software/discuss   |  permalink

C is harder than it looks

I recently saw a nice example on a mailing list of the kind of problem dilettantes run into when they play with C. The coder naturally failed to show what he’d done, but described his problem in terms of “what’s wrong with the implementation of sockets in this operating system?” and went on to describe an impossible scenario. This led to a variety of responses from people who like to be seen to be able to help and don’t strongly feel the need to be right.

It was pretty obvious that the original coder had made a standard beginner’s mistake with C syntax and had compounded his error by failing to turn on warnings in his compiler. In essence, he claimed that the socket(2) call would return a descriptor that was already in use because, after opening his socket, data written to the descriptor would appear instead on the standard output.

Fortunately this was seen by somebody who actually knows C in time to stop too much silly speculation. This guy suggested that the coder must have done something like:

    if (sd = socket(AF_INET, SOCK_STREAM, 0) != -1) {
        /* do stuff */
    }

That code will always assign the value 1 to sd, except for the rare case where it’s not possible to open a socket (in which case the reader, having been alerted to the error, will now know what value it will get). Had our coder turned on compiler warnings in gcc, he would have been told, “warning: suggest parentheses around assignment used as truth value” which might not have been enough, but would have suggested that he needed to get help.

Real C programmers have that extra set of parentheses burned into their fingertips and don’t need to think about them—and, on the rare occasions when they do forget them, know instantly what that warning means. And real C programmers always run their compilers with all warnings turned on.

Unfortunately, too many people take a quick look at C, see something quite simple, and decide that they can safely work with it. It is indeed a simple language, but it’s also a demanding language that provides no training wheels for learners. It takes time to really understand it and it takes regular practice to make good use of it. It’s my opinion that the time required is well spent because you then have a very powerful tool at your disposal—but, like all powerful tools, it can hurt the unskilled operator.

Posted at: 17:00

Path: /software/discuss   |  permalink

Thu, 18 May 2006

The joy of supermarket queues

There’s something about queues in supermarkets that seems to bring out gloriously aberrant behaviour in what otherwise appear to be normal people.

Read the entire post ...

Posted at: 11:44

Path: /society   |  permalink

Wed, 17 May 2006

AMD experiment

I thought I should mark this blog’s arrival at the ripe old age of two years by writing something. The last couple of weeks have been filled with computer hardware dramas—ranging from the ongoing flakiness of my Powerbook (now revealed as largely the result of a dead disk) to the sudden catatonia of my main workstation.

I’ve been thinking about moving to a 64-bit platform for a while, not so much because I need the performance but because it seems like a good idea to expose my own software to any possible bugs that might be revealed by the change. And since FreeBSD, my preferred operating system, now treats the AMD 64-bit platform as a tier 1 (i.e., fully supported) platform, it seems like a good chance to try out some new gear in the form of an AMD Athlon 64 X2 Dual Core 3800+ CPU.

Somewhat to my surprise, after a simple and very fast system install, I ran into trouble with ported applications—normally one of the strengths of FreeBSD. For a large number of things I wanted to install, my attempts were met by messages chiding me for trying to build something that was i386-only on an AMD platform. This list includes big things like OpenOffice (apparently because it depends on Java, which is also i386-only) and small things like the Darcs revision control system. That was all pretty irritating.

There are claims that one can run i386 binaries on the FreeBSD AMD64 platform, but my early attempts to do that with pretty trivial programs have not met with any success so far. So I don’t hold out much hope for monsters like OpenOffice.

Since the software issues looked like being slow to resolve, I thought I should at least get as much as possible of what I had already installed going. And that led to an attempt to start X11. What a mess that turned out to be.

I stupidly thought I could use the Xorg server’s -configure option to create an initial xorg.conf file. It created the file OK. But any attempt to run it with that config file resulted in a machine that was so badly locked up that it even ignored the reset button and required a power cycle before it returned to service. And this all happened so fast that it didn’t write anything in any log files, so there was no clue about a solution.

Having proved that this behaviour was completely repeatable, I then tried the old text-mode xorgconfig program. I gave the obvious answers to all the questions, created the xorg.conf file, started X and all was fine. Why this was the only way to get there is beyond me.

In the next few days, I expect to get most of the software I use all the time running on the Athlon box and to start using it for my work. I’d be surprised if that all turns out to be plain sailing, and expect to revisit this topic over the next few weeks.

Posted at: 14:07

Path: /technology   |  permalink

Thu, 27 Apr 2006

Customers can drive you to distraction

Everybody who deals with customers knows that my title is a truism, but sometimes it can be interesting to examine a case.

Recently, I told the story of a customer who was in a state because the power went out suddenly and they had been seriously inconvenienced as a result of lying to me about having finally got all their equipment protected by UPSes. Yesterday, they arranged for the electricians to come back to do properly what had been arranged so long ago. As instructed, they shut down everything while the electricians were on the premises.

Late this afternoon, they finally rang me to ask what I was doing about getting everything going again. I was waiting to be told the electrical work had been done. They said they had emailed me yesterday. I asked why they had not followed up, or at least checked that the email had left their systems. This upset them, so I let it go, beyond telling them that they knew how to do these things and that they also knew how to check that their ADSL modem was functioning—which it wasn’t.

To cut a very long story short, they said they were desperate to have all their machines running now that the UPS stuff was in hand. (I had told them that I’d only sanction one machine running until the work was done, because that one machine was indeed on its UPS.)

So I said that we now needed to get a lamp or something else that didn’t draw too much current and go around to check that the new outlets were really connected to the UPS. At this point the customer went ballistic, saying that they’d already spent three days with most of their computers unavailable and they just couldn’t spare the time to do this silly checking. Of course, the sole reason they had a problem was their earlier refusal to follow the agreed plans and get all the machines protected by the various UPSes that sit there in their building for that purpose.

I then said, “OK, if you really want to power up the machines without us first checking the electrical work, all you need to do is to sit down for a minute and write me a quick email stating that you are happy with the electrical work and that you take full responsibility for anything that may happen in future if it turns out that the work was not done right.”

“But that’s not fair,” protested the customer. So I explained that what wasn’t fair was the fact that they expected me to drop everything and jump through all kinds of hoops because they refused to follow my advice. I said that they could get the machines running in a couple of minutes if they sent me the email.

And then, surprise! They decided that I’d better step one of their staff through the process of testing the wiring after all. This time the job had been done right, so now all their machines are humming away and I can be comfortable that the next power outage won’t result in me having to spend hours solving problems that should never happen.

Of course, the owners of the business have gone home in a snit and they will be even more cranky tomorrow when they tell their staff to chase me up about other things that were put on hold while the crisis was fixed—as I told the staff who stayed behind to sort out the UPS testing, tomorrow is my wedding anniversary and I just won’t be willing to take their calls.

Posted at: 17:18

Path: /software/discuss   |  permalink

Fri, 21 Apr 2006

That went well

Got a call in the car this afternoon, with a customer in a panic and Friday peak hour traffic buzzing about me. Their building managers had announced they’d be “working on the power” over the weekend and gave them twenty minutes to prepare. According to the customer, they then immediately cut the power. (Based on what happened later, I think they probably got the twenty minutes and failed to act promptly.)

But not to worry, since they had finally got around to doing the necessary wiring and now all their equipment was protected by their UPS devices. So I commented on their good fortune. And then discovered that they’d lied. Perhaps the wiring was done but they hadn’t moved the machines over, or perhaps I’m going to find out next week that the wiring wasn’t done at all. In any case, the machines were not protected by the UPS boxes that are sitting there humming away in their offices.

Since it was Friday and since the building’s power will be on and off over the weekend, I told them to run around the offices immediately and yank the power cords from every bit of equipment and then call me back. I stressed the “immediate” bit several times.

When they called back, about fifteen minutes later, they asked if they should keep pulling the cords now that the power was back on. Clearly, “immediate” had a different meaning for them than it has for me. Eventually, as the power went out again, and the machines all went down again in the middle of starting up, they got around to pulling the power cords.

I told them we’d sort things out on Monday morning. Fortunately, they’re in the same time zone as me. But they have a shock coming. We’re going to get one machine, their main server, running and we’re going to prove that it’s connected to its UPS. And that’s all we’re going to do.

I’m going to explain that none of the others will go back into service until they are connected to a UPS. And I’ll make it clear that I will be able to verify this and that the deal is absolutely non-negotiable. We have stuffed about for years over this issue and I’m just not going to be the idiot who runs around in a panic because they are too lazy or too pig-headed or too stubborn about what they imagine are their own priorities to manage something so simple and so essential to their own well-being.

They are going to be angry with me on Monday. That’s OK with me. But this time I’ve been handed a lever to use to make them do the only sane thing and I’d be remiss if I failed to get something done.

Posted at: 21:08

Path: /software/discuss   |  permalink

Face Time and Free Stuff

I am frequently asked questions by other software developers about the issues one faces in the process of moving away from a job into the scary world of running one’s own business.

Today I saw a nice post by Christopher Hawkins of Cogeian Systems entitled Face Time and Free Stuff. You’ll have to scroll down a bit to get to it, as he seems to have combined two posts in one permalink for some reason. I think he has a lot of good ideas there and I recommend it to all the people who have been asking me questions.

Posted at: 11:27

Path: /software/discuss   |  permalink

Bunnies and glitter

Was it the pink Playboy bunny or the glittering earrings that first got my attention?

Read the entire post ...

Posted at: 09:59

Path: /cars   |  permalink

Fri, 31 Mar 2006

An unsent letter

As he did so often in life, my father thwarted me in death. Of course, that was not his objective and I suspect he would be surprised if he could hear me make that claim. Our 47 shared years involved, on my side at least, a great deal of pain followed by a significant period of estrangement and ended in a rather drawn out truce.

Read the entire post ...

Posted at: 16:24

Path: /family   |  permalink

Tue, 28 Mar 2006

Lakeside revisited

I had finally got used to the idea that I’d never get another chance to drive on the Lakeside circuit, but yesterday brought a wonderful opportunity to go out and play—for the first time since 1999.

Read the entire post ...

Posted at: 17:06

Path: /cars   |  permalink

Fri, 24 Mar 2006

Full feed without the seemore plugin

Somewhat to my surprise, some people don’t want to be saved from having to see the full text of my posts in their RSS feed by the graces of the seemore plugin.

Read the entire post ...

Posted at: 16:40

Path: /meta   |  permalink

Respect must be earned

I offended a customer today by failing to show respect for some really appalling software.

Read the entire post ...

Posted at: 16:26

Path: /software/discuss   |  permalink