— RFC1305

Whilst running the blog's Atom feed through a feed validator, I discovered that I may have been unwittingly causing people problems by … using sane XML for the feed.

Having dutifully associated the Atom namespace with the atom: prefix that all appropriate tags had been given, it turns out that this is more than many aggregators understand, despite being barely above entry-level XML syntax. So, I've moved to the alternative ‘switch default namespaces as necessary’ approach, which is a bit like moving to a friend's house just so that you can say ‘home’ rather than ‘your place’.

Fortunately other people also feel this is an unsatisfying state of affairs, and there's a project already in place that identifies the offenders (which sadly include Safari and Thunderbird) and the standards-compliant tools (such as Firefox and IE7).

If you've been having problems with the Atom feed for this blog in the past, hopefully all should now work. Why not drop a line to your aggregator's developers and see if you can't get it fixed for all the others too?

Quick post: how to set up local DNS caching under Ubuntu. I sometimes find that there's a long delay when launching applications. Often this is just the system working hard to start them, but sometimes there's no load being generated whilst everything sits there for a couple of seconds.

It occurred to me that this might be due to a network timeout or sluggish response of some kind, and a quick look at the output of tcpdump proved that there was indeed a DNS query going on every time I launched xterm.

Rather than sit and wait for the DNS server to get back to me, I decided to install a local DNS server to cache responses. These instructions are a bit basic, but they should show you what needs to be done. Good luck!

• Have a look at what DNS you're getting a the moment.

  root@box:~# dig google.com | grep -A 1 Query
  ;; Query time: 146 msec
  ;; SERVER: 10.0.0.254#53(10.0.0.254)          
  

• Install the package.

  root@box:~# aptitude install dnsmasq
  

• Edit the server config to enable local serving.

  root@box:~# vi /etc/dnsmasq.conf
    [look for a line starting '#listen-address=']
    [remove that initial '#' and add '127.0.0.1']
    [result should be 'listen-address=127.0.0.1']
    [save file and exit]
  

• Add 127.0.0.1 to your list of nameservers.

  root@box:~# vi /etc/resolv.conf
    [insert a new first line that reads 'nameserver 127.0.0.1']
    [save file and exit]
  

• Every time DHCP gets a new lease, resolv.conf will be re-written. Edit the DHCP configuration to always add the local DNS server entry that we added in the previous step. (You might want to check that the last step hasn't been re-written whilst you've been doing this one.)

  root@box:~# vi /etc/dhcp3/dhclient.conf
    [find the line starting '#prepend domain-name-severs']
    [remove the initial '#' character]
    [line should read 'prepend domain-name-servers 127.0.0.1;']
    [save file and exit]
  

• Launch the server.

  root@box:~# /etc/init.d/dnsmasq start
  

• Check the local server is being used, and see how much faster it is.

  root@box:~# dig google.com | grep -A 1 Query
  ;; Query time: 0 msec
  ;; SERVER: 127.0.0.1#53(127.0.0.1)
  

For some time I've been tripping over the need to generate unique identifiers for things. I've always managed to avoid actually having to do so one way or another, but (to make a cliched paraphrase) "with great blog engine comes great responsibility": in order to generate an Atom RSS feed, I need to generate identifiers for each posts.

So far I've been expecting this to involve generating 128-bit UUIDs (as described in RFC 4122) using one of several algorithms, none of which are simple, and all of which seem much too involved when I'm simply trying to stop a feed aggregator confusing my posts.

All of this might explain why I was so happy to find a page describing how to generate a tag URI. Especially so when I realised there was an RFC for the procedure. I won't try to cover all the details they give there, but in a nutshell the procedure is approximately this

• Start off with 'tag:' .
• Add your e-mail address, or domain name if you have one.
• Add a comma, and follow that by the date in 2007-01-01 format.
• Think of a name which hasn't already been used for that combination of address/domain and date, and separate it from what's gone before using a colon.
• The end result might look like this: tag:pdw.org.uk,2007-05-16:Example
• Profit!

Hopefully you might find it useful (or at least informative). I know I will!

For more details, see http://www.taguri.org.

Well, it's finally happened. I've been getting along reasonably well with Nanoblogger for some time now, but a couple of things started to put me off.

Firstly, it is very slow indeed. I've only got a few posts up here, and I was having to wait for well over a minute for it to generate the blog. It might have been about three, but it was some time ago so don't quote me on that. Delving into the code, it looked like there were just a couple of hot spots, but they were getting very hot indeed.

Secondly, support for images in posts was, for me, rather awkward. The only way to include images in a post was to point to them with an absolute URL. For most people I can imagine this isn't a problem, but as it happens I like to view my blog from two places: via my main blog URL (where you're probably reading this from now), and from a secondary URL which gives me the option of previewing things before I release them. Obviously having the same link at different URLs isn't going to be easy, and although I'd patched round it using symlinks it wasn't pretty.

So, I decided that I wanted to keep the other key features of Nanoblogger — static pages, categories, no software dependencies other than bash, and a simple interface — whilst improving on the speed and flexibility. Needless to say, I've written the new engine from scratch, in bash, and it's both fast and portable. In fact, all the internal links are relative, and there's facility for including user content alongside the posts.

Atom, or possibly RSS 2.0, support will be along shortly, once I've had chance to digest the specification documents. In the meantime, hopefully this will mean that posts are slightly less infrequent.

If you ever had the pleasure of using !Draw on the Archimedes A3000, put your pointer here, click the link, then close your eyes and wish for home …

If you made it back here only to find you now need a copy of that marvellous RISC OS app to take the pain away, I can only suggest you get yourself a copy of the excellent Inkscape instead. (Available for Linux, Mac OS X (universal) and Windows.)

OK, so maybe some of you are still thinking "Remote file access? Surely you don't still think that's worth blogging about, do you?." And I'll be the first to agree — what really got me going was this:

There are lots of other nice things (as you're about to see), but if it hadn't been for the ability to do that, you probably wouldn't be reading this.

So what's it like, then? Well, I'm no LaTeX heavyweight — I've never written a document that spreads across multiple files, unlike several of my friends — but I've done enough here and there to be able to see that this is a very well thought-out package.

First though, install AUCTeX. I use Ubuntu (as you might have gathered by now), so I just type:

aptitude install auctex

The README gives three lines which you should add to your .emacs file, but I'm feeling exuberant, so instead I let dpkg configure things so that everyone on my machine (that is, me) gets AUCTeX.

Then we install the preview-latex package, which we'll see more of later.

aptitude install preview-latex

And now the fun starts!

• First, there's a key binding (C-c C-e) to insert any kind of environment you might want (and you can tab-complete them if you're not sure). For example, starting a new report using the 11pt font is as simple as typing C-c C-e document RET ...
  
• ... report RET 11pt RET.
  
• Inserting section headings (C-c C-s) is just as simple: decide whether you want a section, subsection, chapter, or whatever, then give it a title. I find this interactive approach makes life much easier. You'll also find the cursor automatically positioned somewhere useful; starting a document leaves it just after the \begin{document} line.
  
• You're prompted to supply a label for the section (with a helpful prefix filled in automatically), and headings are (configurably) displayed in a suitable font.
  
• You also get font highlighting available for footnotes, math mode, etc., plus a couple of subtle things, like subscript characters being slightly smaller (look at the B, D, and E characters in the formula).
  
• The fun really begins when you fire up the preview-latex package. First we type C-c C-p C-f to turn on some caching, and then we type C-c C-p C-b to run the preview-buffer command. (There's a menu you can access all of this from, too, of course.) After a couple of seconds and some processor activity, bits of the document vanish, and are mysteriously replaced by tiny "men at work" signs:
  
• After another couple of seconds, the roadworks signs vanish too, and you see the fully-rendered TeX output, right there in the buffer! There are a few things to notice here. First, the section heading has the appropriate number attached; it's 0.1 here because we're in a report and there isn't a chapter yet. Second, the math-mode formula has been rendered, and properly shows the superscript and subscript characters. Finally, the footnote has been rendered down to a superscript '1'.
  
• All of the rendered sections are genuine parts of the buffer, not some kind of temporary overlay — they scroll off-screen with the rest of the text, and you can move the cursor around and over them. The only difference is that they will expand into the original source whenever you try to move 'into' them. You can then edit that source normally, and recompile the affected part using C-c C-p C-p to run the preview-at-point command.
  
• Even better, it's compatible with a 'greenscreen' mode I put together a while ago. You need to re-render things to pick up the new colours, but that's it. Green-tastic!
  

There are, of course, lots of things which I haven't covered here: toggling whether a preview section is rendered or not; marking sections of the document to be rendered as a single block; re-rendering only part of a buffer, or the whole document; do-the-right-thing LaTeX compiling and viewing commands; handling multi-file compilation; block-(un)commenting commands; LaTeX environment folding; and lots of customisable options through M-x customize-group RET AUCTeX RET.

One thing which I came across myself and might be of use if you notice the same problem was that some of the rendered text had green fringing. (If you weren't sharp-eyed enough earlier, have a look at the bottom of the '0.1' section header.) This is caused by preview-mode antialiasing to the wrong color. By default it uses the pale green used for mouse highlighting, and it does look exactly right when you move the mouse over it (for example, if you're asking preview-mode to render the section again via a pop-up). Normally I don't use the mouse, though, so I customised this by changing the value of "Preview Transparent Color" using M-x customize-group RET preview-appearance RET (or, for a slightly quicker way, via C-h v preview-transparent-color RET and the 'customize' link).

Something to be aware of if you do this: setting the transparency colour to exactly the same colour as the default text background makes the cursor shape used for rendered sections change from a box around the outside of them to a solid rectangle, which can make previews hard to see. There might be more informed ways to solve this problem, but I found that setting the transparency colour to almost exactly the same as the background looked fine.

After all these features, I can start to see where sites such as this one might be coming from …

I recently had something of an Emacs overload after discovering two separate, great, add-ons within a couple of days of each other. Either would have been bearable, but I'm afraid the two together compels me to post; and following earlier success with the what-I-see-is-what-you-get approach, you'd better get ready for more screenshots…

First was TRAMP mode. This has been around for years, but was still new to me, and might be to you too. (If not, hey — what can I do?)

The basic idea is that you can use SSH to let you edit files on any machines you have access to. TRAMP logs in via SSH, pulls a copy of the file back, and lets you work on it as if it were local. Some pictures will give you a better idea.

• First, since I'm running Ubuntu, I just install the package with:
  

  $ sudo aptitude install tramp
  

• Then we load Emacs, specify the file name in the form / <user> @ <host> : <path> and we're off.
  Let's have a look at my remote .emacs file:
  
• Wait for a few seconds for TRAMP to log in and figure out what the shell at the other end's capable of:
  
• That's it; the file's loaded. You can edit it, save it, or write to a different name if you like; the fact that the file's on another machine is entirely transparent.
  

TRAMP also handles other communications methods, such as scp, rsh, telnet, plink (distributed with Putty on Windoze), sudo (for editing as someone else), and rsync. You can also do tab completion on file and directory names, or use Dired mode (Emacs' file explorer) on the remote filesystem, should you feel the need.

I also discovered the joys of AUCTeX, but you'll have to wait until next time to see those.

Enjoy!

The other day I found myself needing to put some relatively minor code under revision control. Traditionally I've used rcs, as it's very simple, not hard to understand, and was available damn near everywhere (on Un*x machines, at least).

This time though, my laptop didn't have it installed, so I looked around for alternatives. cvs and its successor Subversion (svn) both require a central repository to be set up, which was neither simple enough to do on the spur of the moment, nor a convenient architecture for my circumstances, working as I do on a laptop, public server, and (frequently powered down) home machine.

What I found instead was darcs, which has a number of things going for it. Firstly, it has a good manual and plenty of support. Secondly, it has a well thought-out formal semantics underneath it, which (writing as a computer scientist) is always a good thing to see. This is bolstered by the fact that it's written in Haskell, by a physicist who appears to know what he's on about. Finally, it's a decentralised architecture, meaning the options available at one installation are much the same as those available anywhere else, whether they happen to be on the same machine or not.

Anyway, enough of that: here's what it looks like to use.

• Get things started.

  $ cd ~/SRC
  $ vi foo.lisp        # Create the masterpiece
  $ darcs initialize
  $ ls
  _darcs  foo.lisp     # All darcs' stuff is in _darcs
  

• Add something to the repository.

  $ darcs add foo.lisp
  $ darcs whatsnew
  {
  addfile ./foo.lisp
  hunk ./foo.lisp 1
  +(format t "Hello, world!")
  }
  

• Check things in.

  $ darcs record
  Darcs needs to know what name to use as the author so that [...]
  <snip>
  What is your e-mail address? foo@bar.baz
  addfile ./foo.lisp
  Shall I record this change? (1/?)  [ynWsfqadjkc], or ? for help: y
  hunk ./foo.lisp 1
  +(format t "Hello, world!")
  Shall I record this change? (2/?)  [ynWsfqadjkc], or ? for help: y
  What is the patch name? Initial revision
  Do you want to add a long comment? [yn]n
  Finished recording patch 'Initial revision'
  $ darcs whatsnew
  No changes!
  

• Make more changes

  $ vi foo.lisp
  $ darcs whatsnew
  {
  hunk ./foo.lisp 1
  +;; Print "Hello, world!" message
  }
  $ darcs record
  hunk ./foo.lisp 1
  +;; Print "Hello, world!" message
  Shall I record this change? (1/?)  [ynWsfqadjkc], or ? for help: y
  What is the patch name? Add "Hello, world!" comment
  Do you want to add a long comment? [yn]n
  Finished recording patch 'Add "Hello, world!" comment'
  

• See what we've got.

  $ darcs changes
  Mon Nov  6 22:15:12 GMT 2006  foo@bar.baz
  * Add "Hello, world!" comment
  
  Mon Nov  6 21:45:46 GMT 2006  foo@bar.baz
  * Initial revision
  

• Let's make a new copy to work on different branch — on another machine, if we want to.

  $ cd ~/BRANCHES
  $ ls
  $ darcs get ~/SRC
  Copying patch 2 of 2... done!
  Finished getting.
  $ ls
  SRC
  $ darcs get foo@machine.com:/home/foo/SRC --repo-name=SRC-SSH
  Enter passphrase for key '/home/foo/.ssh/id_dsa':
  Applying patch 2 of 2... done!
  Finished getting.
  $ ls
  SRC SRC-SSH
  $ cd SRC-SSH
  $ darcs changes
  Mon Nov  6 22:15:12 GMT 2006  foo@bar.baz
  * Add "Hello, world!" comment
  
  Mon Nov  6 21:45:46 GMT 2006  foo@bar.baz
  * Initial revision
  $ vi foo.lisp
  $ darcs whatsnew
  {
  hunk ./foo.lisp 3
  +(format t "The End.")
  }
  $ darcs record
  Darcs needs to know what name [...]
  <snip>
  
  What is your e-mail address? foo-ssh@bar.baz
  hunk ./foo.lisp 3
  +(format t "The End.")
  Shall I record this change? (1/?)  [ynWsfqadjkc], or ? for help: y
  What is the patch name? Add ending.   
  Do you want to add a long comment? [yn]n
  Finished recording patch 'Add ending.'
  

• Now bring the changes back into the original repository. This could just as easily be done over HTTP if the directory were visible on a web server.

  $ cd ~/SRC
  $ darcs pull ~/BRANCHES/SRC-SSH
  
  Mon Nov  6 22:26:32 GMT 2006  foo-ssh@bar.baz
    * Add ending.
  Shall I pull this patch? (1/1)  [ynWvpxqadjk], or ? for help: y
  Finished pulling and applying.
  $ cat foo.lisp
  ;; Print "Hello, world!" message
  (format t "Hello, world!")
  (format t "The End.")
  

• We're bored of this, so let's e-mail the changes off, create a tarball of the current state, and get rid of all the darcs stuff. Here the web-site has already got the first two patches, so darcs only sends the third.

  $ darcs send http://foo.bar.baz/projects/demo
  
  Mon Nov  6 22:26:32 GMT 2006  foo-ssh@bar.baz
    * Add ending.
  Shall I send this patch? (1/1)  [ynWvpxqadjk], or ? for help: y
  What is the target email address? foo-mail@bar.baz
  Successfully sent patch bundle to: foo-mail@bar.baz
  $ darcs dist
  Created dist as SRC.tar.gz
  $ ls
  _darcs foo.lisp SRC.tar.gz
  $ tar tzf SRC.tar.gz 
  SRC/
  SRC/foo.lisp
  $ rm -rf _darcs
  $ ls
  foo.lisp SRC.tar.gz
  $ darcs changes
  
  darcs failed:  Not a repository
  

The e-mail contains an attachment, which can be saved and applied using darcs apply. You can also sign the e-mail with your GPG key when you send, and have the other end automatically check the signature against its keyring. Oh, and there's a helpful setting that lets you specify a command which runs any tests you might have, for example HTML validators or unit tests; this lets you stop patches which would break things from getting committed to the repository. And of course, you can do lots of other stuff, like back changes out, tag versions with numbers and labels, etc.

It might not be so industrial-strength as a full Subversion installation, but it's just right for setting up in a couple of seconds where its needed and getting things done. And if you later find you need the big guns, don't worry — there's tool support for converting to (and from) most major alternatives.

Linux framebuffer support has been around for so long that some people probably don't realise that there was a world before framebuffers, in which the only way to look at graphics was to a) run X, or some such program, which would take over the console and speak SVGA straight to the graphics card, or b) get creative.

Whilst I don't much mind pretty graphics at boot time (the default Ubuntu splash screen is pleasant enough), it's a little-mentioned fact that on the text consoles, framebuffer support is significantly slower than the alternative (presumably because it sends rendered characters to the video card one pixel at a time, rather than sending them over as (byte-sized) character values for the hardware to render itself).

As an example, my current (work) machine is able to scroll through the man man page in about four and a half seconds using the framebuffer. That's about 28k of text, and 3700 lines. (In case you were wondering, running man takes about 0.2 seconds; dumping the output in a file and using cat instead makes no appreciable difference in speed.) Without framebuffer, my (old) work laptop is able to scroll through almost three megabytes of text — 350,000 lines — in less than five seconds. In case it hasn't hit you yet, that's a factor of about a hundred. As you might imagine, there was rarely any point in using tail, because displaying output and returning to the prompt rarely took more than a blink. Scrolling text in a pager used to be instantaneous; with framebuffer you can watch the characters scrolling up the screen.

Of course, as I rarely venture outside X these days, this isn't a problem. And the framebuffer isn't all bad: it can do things which weren't possible before — one of the nicest of which is being able to use high resolutions for displaying lots of text. At only 1024×768, you can get 48 rows of 128-column text, which makes for a nice mutt or emacs session. And of course, you can also get a picture of a penguin with your login prompt.

Anyway, I'd long assumed that the only way to change what, and whether, framebuffer was available was to get into kernel recompiles; and life is too short for that, especially now that packaged kernels regularly support everything I need them to. So I occasionally thought fondly of it, and left it at that. But no! Life is much simpler than I'd expected it could ever be! Hurrah, and much use of exclamation marks!

It turns out that you can just use the kernel boot-time options. See your local, friendly boot-loader documentation for information on passing these to the kernel; I press e a couple of times from the boot menu. There are generally a few kernel options already set, such as splash and root=/dev/..., which you can look for if you're not sure.

Then, if you want to use plain (fast) text for your text consoles just add

vga=normal

to your options. Unless you're using the framebuffer as your rendering device, this will make no difference at all to how X works — and if find you are, just reboot and you'll be right back to normal.

If you want to stay with framebuffer but go for something higher-res, pick a value from Ubuntu's helpful page and substitute a number (in decimal) in place of normal. The mode mentioned above would be

vga=791

for example.

And if you really like it, you can always set it for future use: see http://ubuntuforums.org/showthread.php?t=258484 for details.