MCWALTER.ORG and : The homepage of Finlay McWalter.

Navigation: blog | contents | photos | about

Website news and weblog

Blog: Why you want a driverless car: not to drive you around [Thursday 17th April 2014]

Driverless cars are coming, sometime and maybe. Some of us, at least some of the time, still enjoy driving. But even if you never let the car drive itself when you're in it, even if you always drive to pick people up and drop them off, there are plenty of reasons why you might let the car drive itself when you're not in it. The additional capabilities this gives the car may change the way we use cars at least as much as when we're in them.

A lot of the driving you do in your car is ancillary to owning a car, rather than being to service the things you want. If the car can drive itself around, some of that goes away. And there's some routine stuff it can do too. Consider these possibilities:

This last part is maybe the best part. Why does your office, or your apartment building, even have parking next to it? With self-driving cars, it doesn't need to - it can contract parking from some parking lot blocks, even miles away. And valet parking (which is what happens when all the cars in the lot are self-driving, and are controlled by the lot's valet manage system) can manage where every car is kept. With cars parked millimetres apart (no need to open the doors) bumper to bumper, it can manage double or triple the density of a normal lot. You tell it when when you'll need it, and the system can make sure the car is shuffled around when it's time. If you have a genuine emergency (which means you can't wait five minutes for an emergency shuffle to occur) the lot will send a taxi.

With self-driving cars, particularly electric ones, the future may spell bad news for parking attendants, taxi drivers, and filling station cashiers.

Adapted from my reddit post of yesterday.

Blog: The pointless Pono [Monday 17th March 2014]

Neil Young (yes, him) is backing a Kickstarter for a new high-definition portable media player, Pono. It's daft.

Pono promises high quality, high definition digital portable music. CD-DA isn't a perfect format, and munged through mp3 codecs it's a bit worse, with data compression, loudness, range compression, and simply there (usually) being only two channels. In an ideal listening environment, with decent speakers and a quiet room, this might possibly matter. But in a portable environment it just doesn't.

The track record of better-than-CD-quality digital audio isn't a good one anyway. HDCD, SACD, and DVD-A never made much of a dent. In part people just don't care enough (perhaps they're ignorant of the wonders they're missing, perhaps not), and in part copyright holders are reluctant to put such a high-quality stream in their customers' hands (knowing how readily media DRM schemes have been cracked). Perhaps it's time for another crack at getting a high quality digital music standard off the ground. Perhaps iTunes and SoundCloud and Facebook have altered the music marketplace enough that there's room to market better product right to the consumer. A coalition of musicians, technologists, and business people maybe can establish a new format, one that can be adopted across a range of digital devices and can displace mp3 (which is, I'll happily admit, rather long in the tooth).

But portable media is a dumb space in which to do it. And building your own media player is dumberer. People listen to portable players when they're in entirely sub-optimal listening environments. They're on the train, in the back of the car, they're in the gym or they're walking or their running down the road. There's traffic noise, wind and rain, other people's noises, and the hundred squeaks and groans of the city. And they're listening on earbuds or running headphones or flimsy Beats headphones. The human auditory system is great at picking out one sound source from the miasma, but it can only do so for comprehension not for quality too. High quality audio in all these enviroments is wasted - it's lost in the noise.

When I started running, I had a hand-me-down Diamond Rio PMP300. It came with only 32MB of internal storage - that's barely enough for a single album encoded at a modest compression level. So I broke out Sound eXchange and reduced my music to the poorest quality I could manage, and eventually reduced it to mono too. With that done, I could get a half-dozen or so albums on the player, enough that I could get enough variety that each run didn't just follow the same soundtrack. With skinny running headphones, the wind and the rain, the traffic noise, and the sound of my own puffing and panting, it just didn't matter that the technical qualities of the sound were poor. And now, a decade later, when I have a decent phone that plays high quality mp3s, it doesn't really sound any different in practice.

So even if people buy Ponos, even if media executives decide to sell them high-definition digitial audio, if they pay (again) for all the music, in the environments most people will be using their Pono, the difference will be, in practice, inaudible.

Blog: The zombie invasion of Glasgow [Friday 25th October 2013]

The introductory zombie scene in the film World War Z, while set in Philadelphia, was filmed in central Glasgow, around the City Chambers and George Square. I know that part of Glasgow pretty well, but they really did an excellent job of making it look American and disguising its weegieness. I've pored over the entire scene, and here (mostly shot by shot) is a breakdown of where the shot was taken, with Google Maps links.

For each entry I show the time (into the UK DVD edition of the film, in minutes:seconds), the line of dialog roughly about that time, a description of the streets shown, and a Google Maps link (you might need to rotate the camera in a few of them):

  1. 04:56     20 questions - Junction of Cochrane St. and Montrose St., looking west up Cochrane St. (map)
  2. 05:35     "what is going on?" - Junction of Cochrane St. and John St., looking west up Cochrane St. Emporio Armani visible on the left. (map)
  3. 06:26     "you all right?" - Cochrane St., west of Montrose St., looking east down Cochrane St. The Bridal Studio visible in the distance. (map)
  4. 07:14     "I want my blanket" - Junction of Cochrane St and South Frederick Street. Statue of scientist Thomas Graham with The Piper behind it. (map)
  5. 08:17     "out of the way" - George Street, between North Frederick Street and John Street, looking east down George Street. A sign for US30 over the Ben Franklin Bridge in Philadelphia is present. In reality we're about 100m north of the garbage truck crash. (map)
  6. 08:34     "ahh!" - Helicopter shot over Glasgow City Chambers' central tower looking west over George Square. The camera pans clockwise until we're looking roughly at #5 (map)
  7. 08:41     "aargh" George Square at North Hannover Street looking east down George Street. The white base of the statue of Gladstone is visible right of frame. (map)
  8. 08:44     faces of running people - As #5, but looking west back into George Square. The Tron Church is replaced by a glass skyscraper. (map)
  9. 09:22     "seven" - George Square (West George Street) at North Hannover Street, looking westward down George Street. Now the Tron Church is present. (map)
  10. 09:49     starting the RV - High shot from #5, showing the north facade of the City Chambers
  11. 10:05     more running - I'm confused about this one - it may be a computer collage
  12. 10:06     racing toward bridge - Again as #5, looking east down George Street. But the blue metalwork of the Ben Franklin Bridge is visible
  13. 10:08     roadblock - On the bridge: woosh, we're on the bridge on the Camden NJ shore, looking west into the Philly.
  14. 10:13     zombies teeming through George Square - Another helicoper shot, this time over Queen Street looking eastward at the front of the City Chambers. The crashed garbage truck is in the right place. (map)
  15. 10:17     helicopter - view from the back of a helicopter, of Philly's Liberty Place

Blog: Changing the Gnome/Unity background in Python [Friday 4th October 2013]

It's easy to change the desktop background from Python, without using an external program.
Here's a basic example for Gnome (including Unity) on Linux:
#!/usr/bin/env python3                                                                                          
from gi.repository import Gio

bg_settings ="org.gnome.desktop.background")
bg_settings.set_string("picture-uri", "file:///tmp/n2.jpg") # you need the full path

# you can also change how the image displays
bg_settings.set_string("picture-options", "centered") # one of: none, spanned, stretched, wallpaper, centered, scaled

You'd think that it would be just as straightforward to do this on KDE4; it was possible with pydcop on KDE3, but I can't find a way of doing on KDE4 with dbus. I've seen some postings which suggest that they're almost at the point of adding support for this.

Blog: File magic for the constituent parts of Linux RAIDs [Saturday 15th June 2013]

Curiously, the magic(5) for file(1) on my machine doesn't recognise the format of superblocks which make up a Linux RAID, instead simply reporting them as "data".

This Python2 program dissects the header of a given block and shows some information about it and the RAID volume of which it is a constituent.


Linux RAID superblock format detailed at:

import binascii, struct, sys, datetime, os

def check_raid_superblock(f, offset=0): # start of superblock
    data = # read superblock

     bitmap_offset # note: signed little-endian integer "i" not "I"
     ) = struct.unpack_from("<4I16s32sQ2IQ2Ii",

    print "\n\n-----------------------------"
    print "at offset %d magic 0x%08x" % (offset, magic)
    if magic != 0xa92b4efc:
        print "  <unknown>"

    print "  major_version: ", hex(major_version)
    print "  feature_map:   ", hex(feature_map)
    print "  UUID:          ", binascii.hexlify(set_uuid)
    print "  set_name:      ", set_name

    ctime_secs = ctime & 0xFFFFFFFFFF # we only care about the seconds, so mask off the microseconds

    print "  ctime:         ", datetime.datetime.fromtimestamp(ctime_secs)

    level_names = {
         -4: "Multi-Path",
         -1: "Linear",
         0: "RAID-0 (Striped)",
         1: "RAID-1 (Mirrored)",
         4: "RAID-4 (Striped with Dedicated Block-Level Parity)",
         5: "RAID-5 (Striped with Distributed Parity)",
         6: "RAID-6 (Striped with Dual Parity)",
         0xa: "RAID-10 (Mirror of stripes)"

    if level in level_names:
        print "  level:         ", level_names[level]
        print "  level:         ", level, "(unknown)"

    layout_names = {
        0: "left asymmetric",
        1: "right asymmetric",
        2: "left symmetric (default)",
        3: "right symmetric",
        0x01020100: "raid-10 offset2"
    if layout in layout_names:
        print "  layout:        ", layout_names[layout]
        print "  layout:        ", layout, "(unknown)"

    print "  used size:     ", size/2, "kbytes"
    print "  chunksize:     ", chunksize/2, "kbytes"
    print "  raid_disks:    ", raid_disks
    print "  bitmap_offset: ", bitmap_offset

if __name__ == "__main__":
    if os.geteuid()!=0:
        print "warning: you might want to run this as root"

    if len(sys.argv) != 2:
        print "usage: %s path_to_device" % sys.argv[0]

    filehandle = open(sys.argv[1], 'r')
    check_raid_superblock(filehandle, 0x0)     # at the beginning
    check_raid_superblock(filehandle, 0x1000)  # 4kbytes from the beginning

and here is additional magic(5) data to recognise RAID volumes. It's incomplete - I've only been able to test it with RAID volumes I've been able to create myself.
# Linux raid superblocks detailed at:

0x0 lelong 0xa92b4efc RAID superblock (1.0)
>0x48 lelong 0x0 RAID-0 (Striped)
>0x48 lelong 0x1 RAID-1 (Mirrored)
>0x48 lelong 0x4 RAID-4 (Striped with Dedicated Block-Level Parity)
>0x48 lelong 0x5 RAID-5 (Striped with Distributed Parity)
>0x48 lelong 0x6 RAID-6 (Striped with Dual Parity)
>0x48 lelong 0xffffffff Linear
>0x48 lelong 0xfcffffff Multi-path
>0x48 lelong 0xa RAID-10 (Mirror of stripes)

0x1000 lelong 0xa92b4efc RAID superblock (1.1)
>0x1048 lelong 0x0 RAID-0 (Striped)
>0x1048 lelong 0x1 RAID-1 (Mirrored)
>0x1048 lelong 0x4 RAID-4 (Striped with Dedicated Block-Level Parity)
>0x1048 lelong 0x5 RAID-5 (Striped with Distributed Parity)
>0x1048 lelong 0x6 RAID-6 (Striped with Dual Parity)
>0x1048 lelong 0xffffffff Linear
>0x1048 lelong 0xfcffffff Multi-path
>0x1048 lelong 0xa RAID-10 (Mirror of stripes)

Blog: On tracing X11 traffic [Friday 3rd May 2013]

These are some notes giving options for tracing X11 calls and Xprotocol traffic on Linux, using ltrace, xscope, and others.


ltrace lets you follow library calls (calls to shared objects) by hooking the dlopen mechanism. As almost all X programs interact with the server using the standard libraries installed for this purpose (as opposed to performing Xlib calls themselves [footnote 1]), hooking these libraries allows us to trace the calls
ltrace -A 50 -f --library /usr/lib/x86_64-linux-gnu/ /usr/bin/xterm 2>&1 | tee log
The only client I know, off the top of my head, that does its own xlib without using the system libraries is the python-xlib library.


xscope is a little proxy that relays X protocol transactions, and displays the traffic as it does so. The X protocol is, as you'd expect, pretty low level, but there's a reasonable concordance between it and Xlib calls (manual page).

Getting and compiling xscope

sudo apt-get install xutils-dev
tar xf xscope-xscope-1.4.tar.gz
cd xscope-xscope-1.4


gzip man/xscope.1

sudo -s -- <<EOF
  cp xscope /usr/bin
  chown root:root /usr/bin/xscope
  chmod 755 /usr/bin/xscope

  cp man/xscope.1.gz /usr/share/man/man1
  chown root:root /usr/share/man/man1/xscope.1.gz
  chmod 644 /usr/share/man/man1/xscope.1.gz


sudo rm /usr/share/man/man1/xscope.1.gz
sudo rm /usr/bin/xscope


./xscope | tee log

# in another window:
DISPLAY=localhost:1.0 xterm 

Other options

I've not explored these very much, but other options to try include xmsgtrace and reportedly there is an Xprotocol dissector for Wireshark.

Older news and blog entries

Full text of older blog entries and website news are stored on the blog index page.





Navigation: blog | contents | photos | about


The photo archive contains a number of photos of landscapes, buildings, nature, and animals with silly expressions on their faces. There's also some high-resolution digital pictures of various natural and artificial textures, which may be of use for texture mapping applications.

New: I've added some of my favourite closeup photographs, prepared in nice large sizes, to the new backgrounds section.


The source for a tiny  java web server (HTTPd), together with some commentary, is available under the GNU General Public Licence (GPL). With some help from various people I've gotten this down to just over 15 lines of (horribly unreadable) java code. Can you make it any smaller?

Are you tired (or embarrassed) of that uncomfortable delay between launching a large java application and it actually appearing? Help overcome your feelings of inadequacy by wrapping your application in this handy java application splashscreen application, which can show a logo or other graphic while the main application loads.

This page also contains a few weird tricks you can do in the java programming language (but shouldn't).

A discussion of optimisation, in the context of a simple java text processing program is presented in the the java hexdump page. Surprisingly, this shows we can write text processing programs (which are generally IO bound) as fast as decent C language programs.

I've made some notes on webdesign, including:

As almost any user of UNIX and its workalike environments knows, there's really no point in writing your own utilities - as soon as you're finished you'll find someone already wrote a better, simpler, faster solution to the same problem, probably in about 1970. Here are some UNIX shell programming gems that I discovered, shortly after writing my own versions.

Games - RtCWGames - RtCW

Like its ID Software predecessors, Activision's game Return to Castle Wolfenstein contains a number of secret areas, cunningly positioned throughout the game to divert the player's attention from how interminably dull and criminally derivative this rather average game is.

Games - DoTTGames - DoTT

Tim Schaefer's Day of the Tentacle is one of the best computer games of the lost "second age". It worked (with an unpleasant amount of that nasty config.sys wrangling) under DOS and older versions of Windows but it really doesn't work properly under Windows XP. One might think Lucasarts might have released a DirectX version for windows, but perhaps moths have eaten the tape their only copy of the sourcecode is on (or something like that).

This site contains some mystical instructions for playing DoTT on Windows XP and (I think) on Windows 2000. Kindly multi-lingual readers have produced translations of this page into norsk, and nederlands. If you'd like to contribute a translation, even into something mad like Klingon, then I'd be happy to host it.

Although it's not very hard, and it's impossible to get it "wrong", some folks have asked me for a walkthrough of DoTT. As it rather spoils the game, I'd strongly recommend you read it only if you're really really stuck.

For your convenience, there are also the answers to some DoTT frequently asked questions.

Navigation: blog | contents | photos | about
Copyright © 2001-2014 W.Finlay McWalter. ALL RIGHTS RESERVED. No part of this website may be redistributed in any form without the express written consent of the copyright owner. NO WARRANTY of any type is given for this website, or for the information or software programs presented herein. Users proceed entirely at their own risk. Continued viewing of this website consistitutes acceptance of these terms. Trademarks of other entities are the properties of their respective owners, and do not imply their sponsorship or endorsement of this website or its content.