BristolCon 2012

A few days have passed since this year’s BristolCon and I thought I’d best get something down. I’m on the con committee, albeit in a fairly minor role, so I spent much of the day dashing about helping keep things ticking over. I like this; I think it’s a good way to see a small, friendly con like ours. So here’s my very personal and unofficial write-up – just some things that have stuck in my befuddled mind.

The Art Room was a fantastic improvement over previous years – the display stands provided by Roundstone Framing made the place feel really open and were far more aesthetically pleasing than the slightly cobbled-together gazebo of previous years.

Anne Sudworth and Gareth L. Powell‘s guest of honour interviews were interesting. Their interviewers, Ian Whates and Kim Lakin-Smith respectively, were very good and both had an excellent rapport with their interviewee. Colin Harvey‘s Ghost of Honour session was poignant, and I tried my best not to screw up the projections.

As for panels, I kept finding myself focussed on practicalities like watching the time, ensuring there was water and clean glasses for the panellists or helping out with the sound (the PA in programme room 1 was generously supplied by Del Lakin-Smith who was very patient with my fumbling attempts to help him set-up first thing) but I particularly remember the Colonising the Solar System and Women in Sensible Armour discussions.

Later on Gareth’s monkey was a high point, Talis Kimberley and her band performed to their usual excellent standard (although I didn’t listen to as much of this as I should have) and the quiz was, well, too hard!

I met plenty of new people, all of whom had complimentary things to say about the con. I got Philip Reeve, due to be a Guest of Honour at BristolCon 2013, to sign a copy of his latest book for my daughters.  I’d hoped to have a quick chat with Marc Gascoigne (even brought my old copy of Titan for him to sign) but missed him after the Colin Harvey memorial – perhaps at a future event. The Colinthology was an excellent buy and contains some really top-class stories, so I can recommend this as not only a good cause but a good read as well.

The rest of the committee and everyone else who helped out did a fantastic job – most of them worked far harder than I did and often in the face of sickness and pain on the day, so well done to all.

On top of it all I didn’t end up with a bad hangover the next day and I even missed the fire and pestilence. A good day all round and I’m already looking forward to next year!


Flickrtweeter: automatically tweet your flickr pics

A few weeks ago I decided to roll my own script to automatically twitter an update if I posted a photo onto my flickr pages with a certain tag.  I know that there are third party services out there that can do this for you (e.g. Snaptweet, Twittergram) but I thought it’d be an interesting project to do it myself.  As well as (obviously) requiring flickr and twitter accounts, it also requires a account and API key as it uses this service to produce a shortened URL for the photo to include in the tweet.

The script is written in Perl and is fairly straitforward.  It pulls the Atom feed of my flickr account and checks any photos tagged “twitme” against a list of photos it has already seen and tweeted.  It then passes the photo’s URL through to get a shortened version and builds a tweet using a standard prefix, the photo’s title from flickr, and the’ified URL.  It then attempts to post the tweet.

The script uses LWP::Simple for HTTP GETs to flickr and, XML::Simple to parse the responses, Storable to maintain a cache file of seen photos, Net::Twitter to talk to twitter itself and URI::Escape to escape the photo’s URL before passing it to  It also uses the sysopen call from Fcntl to manage a lockfile – I run it as a cron job so this seemed a sensible precaution.

It can be configured by setting variables at the start of the script.  All are commented (I hope) reasonably clearly.  It can be downloaded and used under the terms of the GNU Public License.  I originally called it flickr2twitter but as this appears to be the name of a Firefox Addon I have renamed it flickrtweeter.

Blosxom and application/xhtml+xml

Since this website is written to the XHTML 1.0 Strict Doctype, I thought it would be nice to serve it with the correct MIME type to conforming user-agents. I remembered hearing about a plugin called xhtml that would do this, but after a cursory search came up with nothing I decided that I’d just write my own.

So here’s xhtmlmime. It uses to sniff the Accept: HTTP header from the user-agent and then serves blosxom with the preferred MIME type. There are two variables that need to be set:

  • $flavours needs to be set to a list of flavours upon which to act. This defaults to empty, and the plugin will exit quietly until you set it.
  • $charset should be set to the character encoding used on your weblog. This defaults to utf-8.

You can force the plugin to send the application/xhtml+xml MIME type by specifying a URL parameter of mime=xhtml. Setting mime to anything else will result in the user getting text/html.

Update 2005-07-21

The plugin now exports a variable – $xhtmlmime::meta_http_equiv – for use in your head templates. If you use the http-equiv element, set it as follows:

<meta http-equiv="content-type" content="$xhtmlmime::meta_http_equiv">

And the plugin will ensure that it is set correctly.


As noted by Bill Lovett, serving as application/xhtml+xml raises a couple of issues. The most important one is that this will lead to very strict interpretation of your pages by the web browser, so unless your pages are well-formed – contain no mistakes in the markup – your visitors will just get error messages! Bad plugin!

So, before using this plugin you need to be confident that this is the case, and that you have some method for ensuring that only well-formed, valid markup ends up on your pages.


If you have any feedback, either contact me directly or post a message to the blosxom mailing list.

blosxom plugin: altlinks

This is a trivial plugin I wrote to scratch a bit of an itch. It had always slightly annoyed me that while blosxom itself was designed to use the filesystem hierarchy as its structure and allowed you to view pages based on their position in the hierarchy, there was no simple method to include alternate <link>s to syndication feeds or alternative flavours that mirrored a visitor’s position. Hence altlinks.

Currently, the plugin works for path-based views right the way down to individual story pages, but date-based paths are ignored completely – the href attribute will be formed from whatever path information is available in the requesed URL. That is, if you request, the alternate will have an href attribute pointing to I originally thought this wouldn’t matter, but I suppose for the sake of completeness I should I add this at some time. When I get around to it, I will post an updated version here.

I wasn’t going to post this code at all, particularly since it’s not quite finished, but then I thought it might be useful to someone somewhere sometime, so here it is. The plugin provides three variables for use in templates, allows the user to specify which flavours these variables point to, and contains full documentation.


I thought it might be useful to post a few notes on the process of getting connected to the CafeNET WLAN here in Wellington. It will help me in absorbing everything that I have read about and might prove useful to someone else one day. Be warned, this is a fairly technical post!

Hardware and OS:

Software Requirements:

The package references in parentheses above are Slackware specific. I can’t imagine that there is a major distribution that does not supply any of these packages, but the links will take you to the source if you need it. There are alternatives to dhcpcd you might use, and there is an alternative solution (in part) to the one I am going to describe using a different driver and toolkit.

The ZoomAir 4100 uses the PRISM II architecture with a MANFID of 0x0156, 0x0002. This architecture is listed in the know cards database (/etc/pcmcia/config) and bound to the orinoco_cs device driver, so upon card insertion the cardmgr daemon loads the relevant drivers and logs this in /var/log/messages.

Once cardmgr has identified a card and loaded the device driver(s), it performs some further configuration using the scripts in /etc/pcmcia. The scripts called depend on the device class of the card (see the PCMCIA-HOWTO for more information). In this case cardmgr calls the network script which in turn calls the wireless script. Specific configuration options can be added to the scripts by editing corresponding *.opts files in the same directory.

I had not altered any of these scripts when I began experimenting with the ZoomAir card, and it turned out that the scripts as distributed with Slackware don’t do anything untoward – but neither do they do anything particularly useful, so the final steps needed to be performed manually.

The CafeNET website gives their SSID as ‘cafenet’ and tells us that they do not use WEP (encryption). Armed with this information, we can manually configure the interface using iwconfig. It turns out that the default setup has encryption turned off and sets reasonable values for everything else, so all we need to do is set the SSID:

# iwconfig eth0 essid cafenet

Then you can fire up the dhcp client daemon and hopefully get connected:

# dhcpcd eth0

(I’m going to use eth0 as the interface throughout these examples, but this might not always be the correct option for everyone. If your interface is eth0, you don’t actually need to specify it to dhcpcd as it will use that by default. I’m specifying it for clarity.)

This was enough to get connected to the network. To ‘hang-up’, firstly cleanly kill dhcpcd:

# dhcpcd -k

Then you can eject the card:

# cardctl eject

So – very little needs doing to get connected. But there are some tweaks I’ve made to automate the whole process – even geeks get bored of typing in the same old commands all the time, and what are computers good for if not automation, anyway?

As implied above, Card Services comes with a ready-made system to help automate managing cards. By adding some code to the scripts in /etc/pcmcia we can automate the entire process of connecting to and disconnecting from CafeNET.

I created a scheme for connecting to CafeNET by customising network.opts and wireless.opts. There is no card-specific configuration that I’ve found necessary, so this scheme may be of use to you whatever your card type. Before customising these scripts it is worth reading through the comments as there will probably be sections you will want to remove or comment out.

Here is the case to add to wireless.opts:

    INFO="Scheme for connecting to Wellingon's CafeNET"
    # Turn off encryption as suggested:

And here is the one for network.opts:

     # Leave it all up to dhcpcd:

You can now connect to CafeNET by inserting your card and changing the scheme to cafenet:

# cardctl scheme cafenet

Schemes are described in the Card Services documentation. They’re are a handy way of packaging configuration options for different circumstances which can then be called with a single command on the fly.

It is worth noting that Schemes persist across boots. This is useful for me at the moment as I can leave the scheme set to ‘cafenet’ and get connected simply by inserting the card which will automatically try to connect – I don’t have to type anything at all. But this might not be the behaviour you want. You should be able to set a variable ($SCHEME, funnily enough) in your init scripts to set the scheme at boot time, under Slackware you can set this in /etc/rc.d/rc.pcmcia. There are various ways of controlling this, check out the docs.

To disconnect you should just be able to eject the card using cardctl. Unfortunately there is a slight problem with the network script supplied with Slackware 9 – it sends dhcpcd a SIGTERM when it needs a SIGHUP to exit cleanly (see the man page for more). This is easily fixed. In the network script in the section of the ‘stop’ case dealing with killing dhcpcd replace the line:

kill -TERM $PID


kill -s HUP $PID

This is line 182 in my original network script.

This small change will make sure that everything is left nice and tidy. You could, of course, kill dhcpcd by hand and then eject the card, but why type two commands when one will do?!?

So, there we are – it all works quite well and working it out has taught me quite a bit about the Card Services tools and about both wireless networks and networking in general, all areas I didn’t know a great deal about before. Perhaps this stuff will be useful to someone else.

One final point: while researching all this stuff, it became apparent that there is at least one other option for this particular card in terms of drivers. The orinoco_cs driver is a generic solution – it supports several types of card, and is distributed with the Card Services package as a standard module. According to the orinoco page at Jean Tourrilhe’s site (a great resource for Wireless and Linux stuff generally), the support for Prism II cards is ‘not yet fully functional’, and for Prism 2.5/3 cards the alternative linux-wlan-ng system should definitely be used.

The linux-wlan drivers and subsystem provide an alternative to the orinoco/wireless extensions system described above – not only is the driver different, but the wireless extension tools (e.g. iwconfig) are not used either. Right now, I’m still using orinoco_cs (it works), but I might take a look at the linux-wlan package if I’ve got the time as it is specifically designed for the Prism-type cards of which the ZoomAir 4100 is an example.

Sony Vaio PCG-C1F

So, I got this Sony Vaio PCG-C1F, right. My mate Gavin loaned it to me. The particularly good thing about it is it’s size – small enough to carry round without any hassle.

[Sony Vaio PCG-C1F]

Thing is, I’ve put a nice new Slackware 9 install on it. Sounds good – but I’ve got to do all the configuration myself. If I didn’t know any better I’d assume that Gavin thought I needed a project to keep my mind busy. Still, I suppose it gives me something else to post about, too.

Linux can be a little bit of a pain to install on laptops sometimes – there’s a lot of scope for non-standard hardware and the like for which no-one has got around to hacking out device drivers for yet. Still, at first glance, installing a recent distro on the little Vaio seems like a fairly straigtforward task. Touch wood.

The basic install goes well. The machine boots, and the kernel recognises the cards that came with the machine – the ethernet card Just Works. The modem and wireless cards are recognised, and just need some configuration – I can easily whip up a chatscript for the modem, but I’m a bit less certain about what to do with the wireless card, having never used this technology before. Still, one thing at a time, and the first thing I want to do is to get XFree86 running satisfactorily.

The standard XF86Config file installed alongside with Slackware is actually enough to start X despite the fact that it thinks the screen is 1024×768 whereas it is actually 1024×480. A bit of manpage reading and a quick surf later, and I have a nice little example of an XF86Config file as hacked together by Jochen Topf for his Sony Vaio. (This page has a lot of other stuff on it, too. I plan to read it a bit more thoroughly, and it might be useful to you if you’ve arrived at this page because you’re researching getting linux running on a Vaio.) This doesn’t quite work – he uses the svga driver which I don’t seem to have, and one or two other little minor errors crop up – but a quick glance in /usr/X11R6/lib/modules/drivers turns up a rather promising little file called neomagic_drv.o. The Vaio uses the NeoMagic MagicMedia 256AV, so this looks good.

And sure enough, between this, Topf’s mode line for 1024×480 and a bit of a ripoff from the stock config file, I’ve pulled together an XF86Config file that allows me to startx quite happily and launch the XFce Desktop Environment, which for some reason Gavin and I selected as the default window manager when we were doing the original install without knowing much about at the time.

Despite prioritising getting the X server running, I find that I’m spending very little time using it anyway. Oh well. Next thing I did was to get my digital camera working, a Nikon Coolpix 3100, which proved very simple. This simple: plug in the USB cable, and type

# mkdir /mnt/flash
# mount -t vfat /dev/sda1 /mnt/flash

And off we go. Straight out of the box, as they say.

Next up: the modem and wireless cards. Not to mention a bit of trimming in /etc/rc.d/ to cut down on a raft of unnecessary services.