Even better, their first release is a Christmas single : 'Countdown to Christmas / Baby Jesus was the first Glam Rocker' . Better still, they've made it available as a free download 'as an antidote to the credit crunch'. It sounds pretty much like you'd expect, and the first listen brought a seasonal smile to my face.
I've only just noticed, but the Matador Records sampler disc 'Intended Play: Fall 2008', which they have made available as a free download , has a sample track from A.C. Newman's forthcoming 'Get Guilty'. Unsurprisingly, I like it. There's some good stuff on the rest of the album too, well worth the download cost.
As I mentioned earlier , just as I was preparing to head out for Release the Bats, an email came in advertising a once-in-a-lifetime, never-to-be-repeated, world-exclusive, miss-it-at-your-peril set of performances by a reformed Sleep , at one of next May's ATP weekenders.
Now I'm old and cynical enough to realise that very few things are truly never-to-be-repeated one-off exclusive shows in the world of Rock n' Roll, but I am keen on Sleep, and ATP surely know how to run a memorable event. I've always been intrigued by the idea of one of their Minehead weekends, it seems eminently possible that it's a great deal more civilised than the more traditional tents, rain, and cider circuit. It didn't take me that long to make the plunge and book a chalet for two. Team Strickland are going to Butlins !
Aside from Sleep on the bill, we have long-time house favourites Spiritualized , crazy art-rockers Devo , experimental hip-hoppists AntiPop consortium , post-punk legends Young Marble Giants , and several others I don't yet know adjectives for. The more interesting thing about the lineup is the fact that 50% of the lineup will be chosen by popular vote by the ticket purchasers. That means me!
There's a cunning twist. No doubt intended to mix things up, and keep it fresh. You're not permitted to vote for acts that have played an ATP UK festival before, at least not initially. This makes life decidedly more tricky. Lots of my no-brainer instant first choices are on the exclusion list. I shall have to work a little harder.
Yet another fancy-dress party. This time to honour Claire's birthday. One thing of note about pirate dressing-up, Goths have an unfair advantage over normal people. Still, not often that happens, I suppose, so fair play to them. My outfit ended up a bit Roger the Cabin Boy. And my monkey had insufficient anchorage, and so listed about a bit, drunkenly. Not my best look, on balance.
I blame Johnny Depp. I'm sure pirates used to be far less accessorised.
After falling head over heels for the ATP stage roster, and having my mind blown by Shellac at Primavera this year, It took me about five minutes to sign up for this Halloween show, in London with Shellac headlining. Literally five minutes, the serial numbers on my tickets were #00002 and #00003.
Held at the Kentish Town Forum , which I think used to be the Town and Country club, a venue I was last in to watch the final incarnation of Green On Red in something like '91. Nothing much changed about the place, and I was quite happy to note that there was plenty of milling around room at an event which I think was sold out, indicating a sane crowd capacity limit, a novelty for a London venue.
A varied lineup of bands, the evening kicked off with Lightning Bolt , an outfit I know very little about. Apparently they played from the stage floor, surrounded by the first 500 punters in the queue. Followed by Pissed Jeans a band I narrowly missed seeing at Primavera , but am moderately curious about them, chiefly due to their revolting name. Sadly I didn't show up until just after they'd finished their set this time, as well. Perhaps I am fated never to see them play.
There was a nice atmosphere for the themed night. The crowd was mostly dressed up in halloween garb, plenty of monster makeup and fake blood and wounds. Some of them seemed scarily over-refreshed to me, at least for such an early point in the evening. There were monster mannequins propped up about the place, and model ghouls with flashing eyes suspended over the stage. Most of the bands had gone to great lengths with their fancy dress. Mrs. S. was wearing bats in her hair, but I'm afraid that I let the side down somewhat, opting merely for some magnificently spangly silver glitter shoes.
First act up after we arrived were Wooden Shjips , who played agreeably spacy drony krautrock, which managed to keep my interest through to the end of their set, always a good sign for that style.
They were followed by Om , who I find marvellously impressive. They didn't seem to feel the need to dress up at all, but this was perhaps mitigated by the fact that their doomy Sabbath sludge metal stylings rather suit the spooky halloween monster vibe without them having to try any harder than usual. The most fascinating thing to me about Om is just how much of a great metal-ish sound they manage to summon up as a duo - just a Rickenbacker bass, vocals, and a tricksy drummer. My attention did wander on occassion, but when I found myself locked into their ponderous form of groove, it was quite captivating. And unlike in Spain, they were all finished by 10 p.m. so I managed to enjoy the full set this time. Exciting Om-related news that reached my inbox just before I set out for the show. Sleep are to reform for a show at ATP:Fans strike back next May!
Les Savy Fav next, a band I find okay on record, but who have a 'must see' reputation about their live show. They kicked off with a tableaux involving a plague of zombies on stage, battling the band dressed as cops. It was a tad confusing, with plenty of dry ice, but I suspect the cops were overcome, and they then kicked off straight into their set as zombie cops. I can see why they have their live reputation; Tim Harrington is a very unusual looking frontman, and his stage antics are high-energy and engaging, plenty of clambering around the rigging, clothes shredding, fake blood and protracted sojourns into the audience for mass singalongs. Overall, I found them a bit murky-sounding and unconvincing for me.
Shellac of course played a fantastic set. The vocals were a bit muffled, mostly down to Steve's comprehensive home-made mummy outfit, his entire head was wreathed in bandaging. Backing vocals were also indistinct, yet marvellous, Bob was styled as a Frankenstein's monster-type character, and performed the entire set firmly in character, all his vocal parts were strangulated-larynx monster grunting and zombie moans. Very amusing. I think he even performed an onstage Q & A much like they did in Spain, but kept to this completely unintelligible delivery. And Todd was a superbly convincing vampire, with plenty of finely judged cape theatrics and hissing. Shellac are superb, and are still my favourite live band. Go and see them as soon as you can.
I can't provide any photos, sadly. In the only negative note of the whole evening, my camera was pinched by some idiot. I think it most likely was pilfered while I was on the night bus back to the hotel, as I wasn't really paying close attention to my belongings by that point. In consolation though, the camera-lifting idiot didn't get the essential proprietary cabling and charging cradle necessary to make their new toy useable, and I got to pick up a new camera the next day from one of the gadget megashops on TCR. I quite fancied an upgrade anyway. Plenty of photos from the show from others , on Flickr.
2026 is the year of Linux (in Linux (in Windows)) on the desktop
I'm not a very Windows-focused computer user. In fact I think the last era I used it really extensively, with any expertise, was in the 16-bit era of Windows 3.1 - 3.11. I quite liked those versions, which operated somewhat more like an integrated interface SDK for MS-DOS than an independent operating system. As the commercial internet boom took hold, and work became focused almost entirely on building web applications targetting UNIX-like deployment environments, (typically linux), I shifted over to working natively in that environment, and never looked back. So, I don't really know how to use modern Windows at all comfortably, and I don't have any personal ease when working with it's native interface.
How I typically organise my development environments
Normal development tooling for me is a simple GUI windowing environment, running on Debian linux. I (still) use GNU emacs or increasingly zed for almost everything that isn't in a web browser, alongside a handful of running terminals, an email client, and some kind of file browser, and music player and that's about it. My development projects I tend to isolate into containers, using lxc/lxd and more lately, incus, to give me "lightweight" virtual hosts nested on my computer, connected with a virtual ethernet LAN. It effectively is a local 'cloud', offering dependency and process isolation for your work, and powerful features like snapshot/checkpointing, image templating. What I particularly like about the incus approach, compared say to other container systems, like docker, is the abstraction is well suited to longer-lived, stateful development systems - you partition one linux system into a few dozen smaller more specialised linux systems with the state hidden from each other. The unit of containment is 'operating system'. Whereas with docker-like containment, I think the unit of abstraction is something more like 'one process, with all of it's dependencies bundled', which makes more sense to me for one-shot tasks, or often as a deployment target.
Previously
Back in the 90s(!), when computers were a lot less powerful than they are today, I commonly used to use emacs 'tramp' or Ange-FTP modes, to develop remotely on a development or staging server, from a thinner client. Now I use the same approach, and the same tools, to develop on my container environments, effectively treating them like a 'remote' host, even though they're only conceptually remote. Tramp, just like most of emacs, is a kludgey wonder - it encodes the information about remote endpoints using pseudo-paths, like /ssh:user@host:/path/to/something , and emacs just works out how to edit your files. Under the hood, it strings together a glue of subprocesses and temporary file copies and the like, to take your editing and reflect it on the remote environment. And not just files. This is emacs! Almost everything in emacs works tramp-aware, so you can browse the remote filesystem using dired - launch processes for compilation or linting, use git workspaces with magit-mode, run interactive shells and debuggers, build and run your projects, it has extremely high levels of DWIM. The main price you pay is occasional latency, as things shuttle back and forth, or buffer in and out of pipes, but Iām very used to this. And compared with the days when I used to use tramp to work over dialup(!) links to servers, this modern container approach is practically turbo-charged. Eat my dust!
Zed simililarly offers remote editing using ssh connections, with a slightly different architecture. The zed remote feature is a little more modern, like VSCode - it downloads a headless install of the editor on the remote after you ssh to it, and then proxies to that backend using it's own protocols over ssh. The net effect is the same though, you work on your local keyboard screen and mouse, but your working environment is in the remote hosts. An advantage zed offers over tramp's elegant hackaround is that the latency is considerably reduced, it's not copying files backward and forwards and slowly lauching tasks in shells. A disadvantage zed offers, is that it's not emacs and it's tooling for lots of things (like git, or file browsing) are not as advanced or comprehensively scriptable. It's not uncommon for me to have both zed and emacs buffers attached to the same remote development context.
So, that's what development tends to look like to me. One or two graphical editors, on my main desktop. Many persistant projects mapped to running containers (and maybe remote hosts), with various different projects open in them for work. I get a persisting, consistent user interface over diverse projects, all of them in a full linux environment, each completely isolated from the others, but networked.
Windows re-enters the conversation
In my current job, we're using Windows, and the whole Microsoft business stack, and we have a IT managed network. It's a bit of a change from what I'm used to. But, unlike a lot of software developers, I've found that I like change! (Often, you learn stuff. So what have I learned?)
I've been issued with a pretty nice Microsoft Surface branded laptop. The hardware, at least, is nice (and higher spec than any of my own current computers). The software is, of course, Windows, which I remain suspicious of using. The surface runs it like a champ, of course.
Interestingly enough, modern Windows understands that the majority of software deployment is now to linux, or linux-like environments, and the developer tools include an integrated linux-based toolchain. It's called 'Windows subsystem for Linux' and it's on it's second major version - WSL-2. WSL-2 basically integrates a virtualized linux kernel running inside the windows enviroment, which can be used much as I've described my container approach above - you have a virtual linux host, with it's own filesystem and processes, and a convenient interface between this and the host system.
You can run your graphical applications, and even your IDE (Visual Studio Code, presumably :-)) , and browser (Edge, your AI-powered browser!) in your graphical desktop, and have a local 'server' for developoment. WSL integrates with Docker Desktop for Windows, allowing your docker containers to run natively in the linux environment, and you can even install and run multiple instances of WSL containers to have different isolated linux 'back-ends'. It's a compelling work narrative, but it is founded on the idea that your goal state is using Windows for all your user-facing software and interface. Howerver -- What if you don't want to?
It's a UNIX system, I know this!
Because the WSL environment is an optimised full linux VM, it seemed to me that I might even be able to treat the WSL environment like a remote linux system, and move my existing workflow over - use a linux desktop to remotely access a local linux "server", that just happens to be Windows, and run development inside there using my typical approach of multiple contexts isolated into separate system containers. That's more like my idea of best of both worlds - my work computer can be a locked down managed enterprise client, I can get good use from the fancy hardware, but still maintain the toolchains and client interfaces I'm most comfortable using. Assuming, of course, that I could get it all to work...
Well, it took a bit of fiddling, but I'm here to say it works, well! my Windows Laptop runs on my desk, my software projects run on it inside incus containers, and I access them from emacs or zed or terminal windows, on my ancient creaking linux desktop system. I can easily run as many of these containers as I can fit into my 24GB of WSL (actually quite a lot of headless containers, in my experience) - voila! My Windows laptop is now a cloud host provider!
Here's a detailed walkthrough of how I set it all up. Please note that you will need a local Windows admin account to make some of the necessary configuration changes to the Windows side of things, but aside from a couple of privileged config changes, all of this can be then run as a non-administrator user account, which is another great benefit.
(Because I set this up originally a year ago, my instructions are written from before Debian 13 was promoted to stable, which is why you'll see me using 'Bookworm' in a few places.)
The setup
First: Setup WSL
Firstly, you need to install a WSL2 environment. I picked Debian (which is supported), and I initialised this. I then system upgraded the Debian installation from bookworm (12/old-stable) to trixie (13/testing) using apt, because incus is packaged as part of trixie. I was then able to install incus using apt, and follow the incus initialisation and setup instructions from the project configuration page. I quickly launched a couple of bare bones containers to check that things were working as expected.
Inside your WSL shell, assuming your user account is in the incus and incus-admin groups (check this with the id command), you should just be able to run incus launch images:debian/12 - this should download a base debian image, and launch it with a generated container name.
You can see it running with incus list , and launch a shell within it with incus shell <container-name> - Please read the lovely docs for more such hints, this post is not intended to be an incus user guide ;-)
The next thing I did was add some additional WSL configuration by creating a .wslconfig file in my User home directory on Windows - this is a plain text ini file. I was pleased to find that Notepad.exe still exists in 2024, and can be used to create this file :-)
this is relatively self-explanatory - I'm giving most of my 32GB of RAM to the linux VM (because i'm not really using the windows side), I'm enabling nestedVirtualization, although I don't think this is a prequisite for running incus containers, it sounds like something I'll probably use at some point. Finally, and most importantly for this case, I'm setting the networkingMode up to use 'mirrored' networking mode - this replicates the windows networking devices and configuration inside the linux VM, meaning we can connect directly to the linux system from the network, without having to set up port forwarding or anything like this.
Once you've created the file you need to restart WSL in order for it to take effect. The easiest way to check if it's working is to look at your available system RAM in linux using free - it have changed to be 24GB. The next stage is to setup windows to allow client connections from the LAN.
Windows Networking
We also want to be able to connect to our virtual linux box conveniently from the LAN. This requires a few things. Firstly, we need a stable network address or name. Secondly, we need to allow incoming network connections. This part requires enough Admin privileges on the Windows host to change networking settings.
I redefined the network adapter settings in Windows to use a static IP for this LAN, and added a DNS name for it in my local resolver. I set this network configuration up as a 'Private' network profile. The next step is then to configure the Hyper-V firewall on windows to allow incoming connections to pass to the VM. Running a powershell window as admin, I added firewall rules to allow this for the private network profile. In this way, I can ensure that the host is only accesible like this on trusted networks.
The WSL vm has a fixed identity string (the VMCreatorId) , a GUID, which is 40E0AC32-46A5-438A-A0B2-2B479E8F2E90, so the command you need is something like
Now incoming connections on the windows IP interface will be receivable in the WSL VM. Enable sshd on the WSL environment, and then check that you can ssh to the network address. You should get a login inside the WSL environment. If you run incus list here, you should see any running incus instances.
Bonus networking: Setup ssh proxying, and multiplexing
You can now access incus containers on the WSL instance from a remote emacs, if you use the incus-tramp method, and tramp pipelining. Access a path like /ssh:[email protected]|incus:me@container-name:/path/to/project in emacs and everything should be there. Relying on additional tramp stages for proxy chaining, although it's a very neat trick, can bring problems with performance, and reliability, and it is more simple to push the extra hops into the ssh layer.
This involves a bit of glue code, which looks hideous, but works very well.
The ssh glue
Setup 'Control Master' for ssh, which allows repeated ssh connections to the same host to re-use an established ssh session. This will speed up the time taken to open new sessions, and noticeably improve the responsiveness of tramp for ssh remotes. Secondarily, use a ProxyCommand directive to connect a single ssh connection to a proxy session. Finally, you can use wildcard rules with a host suffix matching a certain host pattern straight through into an incus container on a specific host. Here's the relevant entries from my ~/.ssh/config
In ssh configuration files, the first applicable setting is the one that will be used, so we should order the file from most specific towards most general.
Here, we're using a fake 'domain' of .wsl, and then converting the command to an ssh to the windows host, that immediately launches incus, getting the container name by chopping off the '.wsl' from the provided hostname and running 'netcat' in the container to proxy our ssh session to the ssh server inside the container. With this little piece of ugly glue, we can run ssh container-name.wsl and immediately get an ssh session directly into the running container called container-name
The control master block ensures that we re-use an established ssh control session for all connections to the same host, and persist it for 10minutes after the last connection exits, to improve reconnection times.
With this piece in place, we can access files, shells, and processes from emacs buffers, using a tramp path of /ssh:my-container.wsl:/path/to/project - or laucnch a zed session in a remote project directory, using their ssh 'remote project' feature.
Surviving restarts
The main, and perhaps the only real downside of this approach is that Windows likes to restart, often. Usually in batches once or twice a week. This is a combination of updates from remote IT and Microsoft I suppose. Rather than get too aggravated about it, I prefer to think of it as a free chaos monkey.
I can alleviate most of the pain points by making everything as restart-able as possible. WSL can be set to start as soon as you login by tweaking a few settings in the cmd.exe application
set the default shell to be Debian to match my WSL container session
set cmd to start on login
This means that after a boot all I have to do is login to resume the WSL state
The incus container can be set to automatically start at boot with incus config
I have assigned both the incus container and the windows machine static IPs on my LAN, so they reboot with a stable address.
In WSL I have caddy set to reverse proxy from Debian to the incus address, and this is configured in /etc/caddy and run from a systemd unit, to restart on boot
The local "staging" version of any webservices I am working with I typically run in Docker , inside the inucs container (as my user account) - i usually write a shell script to launch docker with the right port forwarding and data persistence flags for whatever I want to be running (for more complex setups this could be a docker compose configuration) - I simply put this shell script into my user crontab, using the magic @reboot trigger directive to launch this script after multi-user init, as me, with just a one-liner.
with these configurations in place, all I need do is login to Windows (with my face š) to resume running services where I left them.
What could turn out to be only the third known photograph of Robert Johnson , recently surfaced on ebay according to this engaging Vanity Fair feature.
David Cross was in the New Pornographers promo video for 'Use It.' When I went to see David Cross curate his cabaret show last year in London, one of the acts presented was Kristen Schall , who showed a film from her ongoing 'Penelope Princess of Pets' series. Now TNP have a video for Mutiny, I Promise you, featuring Penelope Princess of Pets.
It's all linked. I henceforth predict the Flight of the Conchords will support the forthcoming A.C. Newman tour.
Kate was right, that's clearly a cardboard theremin. Not often you get to say that.
For the past year and a bit, I've been relying on a one-user GoTosocial server for my fediverse participation. Fediverse is the 'well, actually' technically correct name for the social network protocols that power an overlapping set of free, distributed social networks that a lot of people just call 'Mastodon'. Mastodon is the largest and most popular server software used in this network, and got a significant bump in popularity when that crazy space junkie guy started hacking on twitter.
Monoliths vs Microliths
Mastodon is a large Ruby on Rails project, with the typical kind of architecture you might expect from a classic LAMP-adjacent dynamic web thing that's used in production to run instances with thousands and thousands of active posting user accounts, and a hefty server footprint.
Gotosocial is a fediverse server that specifically targets a lower footprint installation. It's written in Go, which while not being the kewlest platform to build a modern web server application in, is to my eyes, a pleasingly pragmatic choice. (Something I often like to say is 'Go is actually kind of a DSL for building small network servers in'). It also targets full mastodon compatibility, so it's a drop in replacement for a mastondon account, and much simpler to run if you were interested in having your own fediverse service.
WASM-azing!
Whilst Gotosocial has a modest footprint, and a few moving parts, it's not without some interesting technical architectural decisions. In one of its simpler installable forms, rather than use an external relational database like PostgreSQL, it just uses good old SQLite3 š - and rather than pay the CGO / boundary penalties for linking directly into SQLite as a shared library, it can actually run SQLite as a contained WASM process inside the go application, using the Wazero runtime
I adore everything about this approach, it's exactly the kind of mad science I'd try to get a simpler working service. End result is you have a single static binary that you can run and install, and it manages its own fully compatible SQlite3 database store in-process, without any install-or-link-time dependencies.
So it's super simple to install for me on linux, I simply need to unpack a binary linux release tarball and then launch the newer binary with the old database file. Gotosocial applies database migrations on startup.
Official upgrade procedure
Here's their offical upgrade instructions taken from codeberg for the binary release
Stop GoToSocial
Back up your database! If you're running on SQLite, this is as simple as copying your sqlite.db file, eg., cp sqlite.db sqlite.db.backup
Download and untar the new release, including the web assets and templates, not just the binary
Edit your config.yaml file as necessary (see the release notes)
Start GoToSocial
Wait for migrations to run.
It's about as simple as a manual upgrade can be.
My Tweaked upgrade procedure.
Well, aside from scripting it, I think there's one small improvement that can be made. So far as I know, GoToSocial doesn't (yet?) run auto vacuum on its SQlite database. VACUUM on SQLite is a necessary maintenance procedure that's used to refresh, compact and optimize the database backing store after it's been amended in use for some time. You can think of it a bit like a 'defrag' or a 'garbage collecter' for your database.
Without auto-vacuum, vacuum is necessarily a blocking operation, you will block all other database changes until the vacuum is done. As such it's ideal for downtime. So vacuuming your GoToSocial database when you upgrade is a good idea, although it does extend your service downtime by a couple of minutes.
So, as well as copy your database to a backup, I suggest you also connect to it, with the sqlite3 command and run a complete VACUUM. But wait, we can be even cleverer.
VACUUM INTO
Vacuum already makes a complete copy of the database. Go back and read the VACUUM documentation I linked above. You might also notice that SQLite VACUUM supports a 'VACUUM INTO' form, which materializes this vacuum copy information into a fresh database file.
so my amended system upgrade is like this, pretending for the sake of example that it's a manual process.
chdir to my gotosocial directory /gotosocial
download the new tarball release
stop gotosocial with systemctl stop gotosocial
rename the old gotosocial binary to a versioned backup
untar the new release and assets into the directory
renamegotosocial.sqlite to a versioned backup name e.g. gotosocial.backup.sqlite
connect to the newly renamed sqlite database with the sqlite3 ./gotosocial.backup.sqlite command
run VACUUM INTO 'gotosocial.sqlite' (i.e. re-creating an optimised gotosocial database)
start gotosocial again systemctl start gotosocial
watch the migrations and startup with journalctl -f -u gotosocial
I'm organizing my photos to make use of some free prints on offer from photobox. Hence I've uploaded a selection of older shots that I'm mulling through. There may be some repeats from earlier posts.
If you have a Django 1.0 deployment configured to use sqlite3, and are struggling to understand sporadic eruptions of what are clearly exceptions thrown by closing a database cursor with uncommitted work; either manage.py commands on the shell, or page requests to the application generate stack traces centered around messages like ' Unable to close due to unfinalised statements ' then it might be a file permissions problem.
In my case, neither my developer shell account, nor the user id of the running apache httpd processes had write permissions to the directory with the sqlite3 database file. Not immediately apparent from the wording used in the error messages.
I have some Objective C classes that I've built for use in a project. They are model and utility classes, and have no direct UI responsibility. To aid in automated testing and debugging, I've built them as a project that creates a static library. The project has a test target that runs suites of automated unit tests, and a library target that builds a C-style static library archive binary. The install configuration of this target copies the library to $HOME/lib/ , and the class headers to $HOME/include/$LIBNAME.
This way when I use these classes in another project, I can just #import the headers in the sources, add the static library to the project frameworks list, add the include and lib directories to the compiler and linker search paths in the XCode target inspector, and build as normal. Build times are reduced, base classes are frozen in a stable, well tested implementation, code re-use is easier, everybody wins.
Recently I broke this happy pattern, a little perplexingly, with what I thought was a fairly innocuous piece of refactoring. I noticed that one of my classes was rather a simple set container, and its implementation really little more than a thin wrapper around NSMutableArray , with only a trivial specialisation of behaviour. As it was only used within a parent class structure, with no interface outside the library innards, it seemed a bit of overkill to have it implemented as a sizeable class. The special behaviour really boiled down to maybe two additional methods on top of the normal array interface.
I first refactored it to be a subclass of NSMutableArray, but that actually introduced more complexity. NSMutableArray is implemented as a class cluster , with an abstract API around a private hidden shadow class. In order to subclass it, you are expected to provide your own implementations of a subset of its interface. In my case, this would have made for more code than the class I was trying to replace.
Of course, Objective-C allows you to define categories on any existing classes. Categories allow you to formally define and implement additional methods onto an existing class definition at compile time. I could re-implement my class as a tiny category on NSMutableArray, removing lots of my code, and reducing the size of my library footprint and perhaps add some value by introducing NSMutableArray's extensive interface.
Surprisingly, it wasn't plain sailing. Coding up the category, and tweaking the library to use NSMutableArray in place of the now-redundant class was straightforward. Once the updated code passed the original test suite, it was deployed as a library. The first time I built a project using it, it crashed on startup, with an unhandled exception. I cleaned all targets and rebuilt. Same problem. I checked the library headers to confirm that the new data structures were properly defined on include. No problems there, but still a hard crash on initialisation.
The system logs had an entry for the crash; selector not recognized attached to symbols that were recognisably the new array methods from my category. Running 'nm' against the library file showed the symbols present, and correctly defined as a category on NSMutableArray. I was stumped. After a bit of googling, I came up with the correct solution.
It turns out that in order to link against a static library that contains Objective C categories, you need to pass the linker a special flag, '-ObjC'. Adjusting the build settings of my project to include this flag in the 'Other linker flags' entry of the target inspector fixed it so that the symbols are correctly resolved at runtime. Here is the official word, Technical Q&A QA1490.
