Mon 27 Aug 2007
Finished Janette Turner Hospital's latest novel, Orpheus Lost, on
Saturday, and am still thinking about it two days later. It's a great read -
an imaginative reworking of the Orpheus myth against a backdrop of current-day
terrorism. It has lovely quirky characters, beautiful but highly readable prose,
and a story that is told from multiple points of view, but manages to stay
coherent and whole.
And like her earlier Due Preparations for the Plague, rather than
slowing down towards the end, Orpheus Lost seems to actually accelerate,
finishing with an emotional punch that left me satisfied but also slightly
shell-shocked. So it's a compelling read, but it's not light material, with
happiness and tragedy portrayed as flipsides of the same love, particularly in a
complicated and neurotic world. Orpheus was a tragedy, after all.
Highly recommended.
Sun 19 Aug 2007
I've been trying out a few of my
blosxom wishlist
ideas over the last few days, and have now got an experimental version of
blosxom I'm calling
blosphemy (Gr. to speak against, to speak evil of).
It supports the following features over current blosxom:
loads the main blosxom config from an external config file
(e.g. blosxom.conf) rather than from inline in blosxom.cgi.
This is similar to what is currently done in the debian blosxom
package.
supports loading the list of plugins to use from an external config
file (e.g. plugins.conf) rather than deriving it by walking the
plugin directory (but falls back to current behaviour for backwards
compatibility).
uses standard perl @INC to load blosxom plugins, instead of hardcoding
the blosxom plugin directory. This allows blosxom to support CPAN
blosxom plugins as well as stock $plugin_dir ones.
uses a multi-value $plugin_path instead of a single value $plugin_dir
to search for plugins. The intention with this is to allow, for
instance, standard plugins to reside in /var/www/blosxom/plugins,
but to allow the user to add their own or modify existing ones by
copying them to (say) $HOME/blosxom/plugins.
These changes isolate blosxom configuration from the cgi and plugin
directories (configs can live in e.g. $HOME/blosxom/config for tarball/home
directory installs, or /etc/blosxom for package installs), allowing nice
clean upgrades. I've been upgrading using RPMs while developing, and the
RPM upgrades are now working really smoothly.
If anyone would like to try it out, releases are at:
I've tried to keep the changes fairly minimalist and clean, so that
some or all of them can be migrated upstream easily if desired. They
should also be pretty much fully backward compatible with the current
blosxom.
Comments and feedback welcome.
Thu 16 Aug 2007
I'm currently working on packaging blosxom as
an RPM for deployment on a few different RedHat/CentOS servers I administer.
With most small-medium software packages this is pretty straightforward - write
a simple spec file, double-check the INSTALL instructions, and replicate those
in the spec file. It's rather more challenging with blosxom.
blosxom's roots are in supporting extremely minimalist environments. It's
reasonably straightforward
to setup blosxom on a 1990s shared web hosting account
with only the most basic CGI support, and only FTP access to the server for your
files.
Blosxom itself is a single perl CGI script, which you configure by setting a few
variables at the top of the script. Blosxom plugins, which are used to implement
lots of the functionality in blosxom, are likewise little perl modules configured
(if necessary) at the beginning of each plugin. In a shared web hosting
environment you'd configure blosxom itself and your plugins the way you'd like,
and then upload them to your server home directory via FTP.
Fast forward to 2007, where virtual linux servers with full root access are
available for US$15/month, with prices continually dropping. In this kind of
environment the whole mixing-configuration-and-code thing becomes much more of a
liability than a feature.
There's a debian package
available, so the debian guys have made a start of wrestling with some of
these issues - they patch blosxom to allow it to use an external config, for
example. I've done something similar, and am realising I'm going to want to
support the same kind of thing with plugins.
So here's my current wishlist for a blosxom RPM:
the ability to install one of more blosxom packages and get blosxom itself,
a good set of blosxom plugins, and a good set of blosxom flavours and
themes all ready to go
a proper separation between config and code, so that I can upgrade any of
my blosxom packages without having to worry about losing config settings
an easy way of configuring exactly what plugins and themes are used for my
blog
most standard modern blog features available more-or-less out-of-the-box
(e.g. comments and spam protection, support for sending
trackback pings, support for receiving trackbacks and
pingbacks, OpenID support,
support for microformats, etc.)
multi-user and multi-blog support, so that an installed blosxom can be
used for multiple blogs
mod_perl support, for scalability
That's my current wishlist anyway. I'm still trying to figure out whether
others in the blosxom development community are interested in any of this
stuff too, or whether they all just still use FTP. ;-)
Thu 09 Aug 2007
We've been having a bit of trouble with these motherboards under linux
recently. The two S4/S5 variants are basically identical
except that the S5 has two Gbit ethernet ports where the S4 has only one,
and the S5 has a couple of extra SATA connections - we've been using both
variants. We chose these boards primarily because we wanted AM2 boards
with multiple PCIe 16x slots to use with multiple displays.
We're running on the latest BIOS, and have tested various kernels from 2.6.9
up to about 2.6.19 so far - all evidence the same the same problems. Note
that these are much more likely to be BIOS bugs, we think, than kernel
problems.
The problems we're seeing are:
kernel panics on boot due to apic problems - we can workaround by specifying
a 'noapic' kernel parameter at boot time
problems with IRQ 7 - we get the following message in the messages log
soon after boot:
kernel: irq 7: nobody cared (try booting with the "irqpoll" option)
kernel: [<c044aacb>] __report_bad_irq+0x2b/0x69
kernel: [<c044acb8>] note_interrupt+0x1af/0x1e7
kernel: [<c05700ba>] usb_hcd_irq+0x23/0x50
kernel: [<c044a2ff>] handle_IRQ_event+0x23/0x49
kernel: [<c044a3d8>] __do_IRQ+0xb3/0xe8
kernel: [<c04063f4>] do_IRQ+0x93/0xae
kernel: [<c040492e>] common_interrupt+0x1a/0x20
kernel: [<c0402b98>] default_idle+0x0/0x59
kernel: [<c0402bc9>] default_idle+0x31/0x59
kernel: [<c0402c90>] cpu_idle+0x9f/0xb9
kernel: =======================
kernel: handlers:
kernel: [<c0570097>] (usb_hcd_irq+0x0/0x50)
kernel: Disabling IRQ #7
after which IRQ 7 is disabled and whatever device is using IRQ 7 seems to
fail intermittently or just behave strangely (and "irqpoll" would just
cause hangs early in the boot process).
This second problem has been pretty annoying, and hard to diagnose because it
would affect different devices on different machines depending on what bios
settings were on and what slots devices were in. I spent a lot of time chasing
weird nvidia video card hangs which we were blaming on the binary nvidia
kernel module, which turned out to be this interrupt problem.
Similarly, if it was the sound device that happened to get that interrupt,
you'd just get choppy or garbled sound out of your sound device, when other
machines would be working flawlessly.
So after much pain, we've even managed to come up with a workaround: it turns
out that IRQ 7 is the traditional LPT port interrupt - if you ensure the
parallel port is turned on in the bios (we were religiously turning it off as
unused!) it will grab IRQ 7 for itself and all your IRQ problems just go away.
Hope that saves someone else some pain ...
Wed 08 Aug 2007
I'm using blosxom for this blog. I'd played with
it a while ago and really liked its simplicity and ethos, but never got it
working quite the way I wanted. When returning to the blogging world recently
I went and looked a few of the popular alternatives -
Typo, Wordpress,
Movable Type - and didn't find anything that
really grabbed me.
Yes, all three are slicker, more modern, and have a lot more functionality
out-of-the-box than blosxom, as far as I can tell. So why am I back with
blosxom?
For me, blosxom has two killer features:
you can write your blog entries offline, using a real editor, and using
nice sane rich-text formats like
Markdown
it is simple and pluggable, by design, which makes it immensely hackable
In fact, blosxom isn't really full-blown blogging software at all, especially
as it's presently packaged and distributed. Instead it's a lightweight pluggable
toolkit with which to build a blog. If you're after something that Just Works,
it's probably a bad choice; if you're after something you can play with and
bend to your will, it's really nice.
Blosxom's also suffered a bit from not having had much development love over
the last few years. Be nice to see blosxom get a bit more support for the
modern blogging world - have to see if I can help stir things up a bit ...
