There’s a store section called “Apps Starter Kit” which lists a dozen or so applications that Apple are promoting as “must have” installs for new iOS users. I installed a handful of these to my iPhone 3GS, but the one that has most impressed me so far is the iOS edition of DragonDictate.

It’s a “split brain” app, by which I mean it uses “the cloud” to perform the text-to-speech conversion. So far I have been quite impressed with the accuracy of the process, in fact I have created this blog post by dictating while walking the dog, with just a little editing afterwards for tidy up and to add hyperlinks. I suppose it is a little like a poor man’s edition of Siri, minus the pretend A.I. and the search and reminders integration.

You can get text by dictating into a text box within the application and there is a quick menu of options that allow you to create an SMS or an e-mail or copy the text to the system clipboard easily for use in other applications. This collaboration isn’t too clunky and although dictating text into your phone is a little stilted it doesn’t seem to be significantly less effective than my relatively crappy typing on the iPhone on-screen keyboard.

The app was free, presumably it’s intended as a promotional device to introduce users to the Dragon family of software applications. Obviously there are some privacy concerns raised by having the voice processing performed on a remote server, but the terms and conditions include a privacy policy which guarantees to preserve your anonymity and keep your data private. The application did even prompted me to ask if I wanted all of my contact names uploaded to the remote service for greater the use of name recognition, and took pains to explain that this would only include name fields from my contacts database and no other personally identifying information or contact details.

I am not sure I would make a habit of using it for writing long articles or even blog posts like this but I think it could prove to be quite useful for such purposes as short e-mail replies or even sending SMS messages in situations where it’s inconvenient to type.

Of course, I bought and read the Jobsography, Kindle edition, naturally. While I’m not sure I identify with all the howling fanboys’ anguished reviews, given my role as super-NEXTSTEP-fanboy I was a bit disappointed, although not particularly surprised, at the relative lack of NeXT content. So I was overjoyed when this 1986 PBS documentary, featuring NeXT in it’s pre-launch startup guise, popped up in it’s wake. The linked blog post also contains the NeXT stevenote, from the eventual product launch.

Thanks to ebay. I like the fact that the sticker arrived with a little template indicating the correct 28° of jaunt. I ignored it of course, and just lined it up by eye.

I don’t disagree fundamentally with the tone of the piece. I do share his unease over the now seemingly mandatory broadcast grief marathons that accompany any death in the public eye, and I find an unpleasant hint of infantile narcissim in the fetish relationship between the user and product celebrated with the mass parades of public Apple evangelists and their iDevices, which might be a cousin to the sentiments he expresses about toys and proportional responses.

This attempt to sum up Mr. Jobs as a super-skilled marketer I think underestimates the scale, and perhaps also the nature of Mr. Jobs’ contributions, some of which are subtle, many of which may look obvious, but usually only by hindsight. Even if his role was solely as a provoker, and curator of works; and I doubt it was, the truth is rarely that neat – he seems to have his fingerprints near the genesis of a string of transformational products, which do seem to fulfill the cliche of yes, changing the world.

Start at the beginning: His role in realising the portable microcomputer as a packaged appliance, something like a food processor, that people could be taught to directly integrate into their homes and offices. The Apple II barnstormed this market. I am not so sure as most other commentators that this idea was an obvious, archetypal product simply waiting to happen. Putting computers in your house, I think, is a fundamentally odd idea, albeit one that we have now fully naturalised. In 1976 it must have been almost schizophrenic.

Refining this idea into the Macintosh and Lisa, a specifically pioneering further insight was that a then unusual square pixel bitmapped display would better lend itself to curve plotting. This gave us the WYSIWYG relationship between the graphical computer and the laser printer, computer typography and thereby re-shaped the primary means of production for print and graphics.

The post-Apple “wilderness years” are particularly interesting. At NeXT they pioneered software controlled automated computer assembly and production, I’ve heard it said maybe a decade ahead of everyone else. I think they made a lot of mistakes, but I also think these lessons learned were invaluable later on. More significantly, the NeXT system software placed an elegant emphasis on “object-oriented programming”, carefully enveloping the tedious nuts and bolts of interfacing with electrical computer hardware with well chosen software ‘components’; tidy abstractions that lead to a system that was significantly easier to port to new hardware configurations, and simultaneously could be more-easily programmed at a higher level, without resorting to so much specialist understanding of specific hardware.

The significance of the work at NeXT will not be fully realised until later in his career, but as an intriguing footnote, it is on a NeXT workstation that a British scientist called Tim Berners-Lee develops some applications and protocols he calls the “World Wide Web”. Mr Berners-Lee is on the record noting that the unique NeXT development tools allowed him to easily connect abstract layers to form useful application prototypes in the space of a couple of months.

Steve’s other business during those years was Pixar. You don’t have to study the history of cinema over the last two decades too hard to detect just how fundamentally Pixar shaped mainstream family movie making.

Then he returns to Apple and begins that now over-documented turnaround from prodigal son and failing company, to pin-up CEO and spectacular media and financial success. It’s worth pointing out that the portablility of the NeXT system software allows them to insinuate it into Macintosh entirely. Next the iPod, and then we get iTunes, and the ‘iTunes Store’.  And then the same elegant software evolves to pocket phones, where the relative ease of programming buoys up the freshly invented ‘App market’. And a finely edged production control builds an on-demand production, supply and retail operation that is the envy of the rest of the industry.

I’m not a professional writer as Mr. Hepworth is. I hope I don’t read like I’m elegising him mawkishly like some Princess Di or Jade Goody for the “Facebook generation”, or lionising him in super-human terms as though he’s some over-egged digital Da Vinci, or Newton. I never met him. I’m not laying flowers anywhere. I’m sure that a huge part of his success was through fortunate timing, and developing good taste and keeping good company, but this is surely true of many whom history accounts amongst the Great, perhaps even of most. What a C.V. though!

These things are not a competition you can score, and yet I don’t think most Word Magazine readers would rush to disagree with the suggestion that Steve’s musical idols like Dylan or the Beatles “changed the world”. I’m comfortable suggesting that to a subsequent generation, with it’s own new media of choice, Steven P. Jobs influenced and changed the world to an arguably similar degree.

I picked up the D-link cheaply, in a clearance bin in John Lewis. In most respects it has been a splendid replacement for the O2. WiFi is fast, routing is consistent, ADSL sync is better. However, it does have one stupid bug. It can’t do DHCP reliably. After a certain period, it starts sending out broken leases to clients; either issuing them with IP addresses that are already in use, or more commonly issuing a working address, but nullifying the nameserver settings. A reboot will restore sanity, but involves an irksome couple of minutes of network outage. Afterwards it is only a matter of time before the problem re-emerges, noticeably quicker if there’s an increased rate of new leases issued, such as a group of visitors armed with smartphones popping in.

I’m consistently amazed at how flawed home router appliances are. How anyone ‘normal’ is supposed to cope with these things, I have no idea. I’ve updated the firmware to the last available revision, fiddled with the limited options in the admin interface, to little avail. Web searches turn up a few people commenting on the same problem, but no solutions offered. This leaves me with three straightforward, yet unappealing options.

1. Buy another router. Either another toy one, which seems likely to smuggle in some fresh nugget of buried failure, or buy something more professional, and hence eye-wateringly expensive
2. Set up static configuration for every client. Seems a stupid solution in 2010 for a primarily wireless network
3. Disable DHCP on the router, and add another, more reliable DHCP server to the network

Option 3 initially seems least aggravating. In the past, my strategy for service infrastructure has always been using home servers, with some form of UNIX. These days though, I’m trying to minimise the number of computer-type devices I have to keep running 24/7. I no longer find any joy in being a home UNIX administrator, and it’s nice to correspondingly reduce power consumption, fan noise, and cabling. So the idea of setting up a computer just to act as a DHCP controller is slightly repellant.

The only machine tethered to the network is a modest, first-generation, G4 mac mini. It’s chief use in the past was as a basic freeview PVR, using Elgato eyeTV, but the London flat’s TV reception is too poor for this, so it mostly acts as an AFP-capable network interface to my firewire Drobo. It’s a very old, low power machine, but would certainly be capable of acting as a DHCP server.

It wasn’t immediately obvious how best to do this. Obviously I could install any of the common free UNIX DHCP software, using MacPorts, or homebrew, or fink, or even just hand rolling something from tarballs, but all of these come with overheads, adding dependencies, requiring build tools, and subsequent package management, and all the little bits of service glue needed to make it run neatly as a daemon. Experience has shown me that integrating third-party UNIX services into a vanilla Macintosh can get fiddly, fast.

There’s no obvious DHCP server component on desktop OS X, but there’s a latent capacity somewhere, demonstrated by ‘Internet sharing’, which lets you easily set up a Macintosh with a network connection as a basic router. After a little bit of poking around with this, and some internet searching, I discovered that this facility is part of the bootpd service. It’s documented, and after a little trial-and-error, I figured out a way to run a DHCP server facility only, using just the built-in Apple utilities.

Here’s an overview of my network configuration

• The D-link router provides NAT routed internet via O2 ( actually Be ) ADSL 2+ with a static IP.
• The private subnet is 192.168.1.0/24
• The router’s internal address is set as 192.168.1.1
• The mac mini is connected to the router via wired ethernet with an address of 192.168.1.4, and runs headlessly.
• Everything else connects to the D-Link router wirelessly, using a mix of 802.11n and 802.11g

Here’s how to set up bootpd to act as a DHCP server for this network.

First, configure the mac mini to have a static IP. Using screen-sharing from another Mac ( Cmd-K, vnc://192.168.1.4 ) to configure the network interface in system preferences.

Next, configure your computer to also have a static address on the same subnet. If you get something wrong, and need to troubleshoot settings, you’ll still need to be able to connect between the router, the mini and your workstation. I picked 192.168.1.111, as being well outside the range of anything I’d expect to be routinely allocated.

Now you need to produce your bootpd config file ( /etc/bootpd.plist ). Unfortunately this means an XML property list. Every time I feel smug about how the Macintosh is re-invigorating UNIX with the old, crufty bad bits removed, I ought to remind myself about the maniacally stupid idea that is XML plists. Instead I thank my stars that I have a capable text editor. It’s not that fearsome a property set, and is well explained in the man page, so you could build one by hand. An alternative approach, the one I used, would be to set up internet sharing temporarily on the mini for an interface you’re not using; I chose firewire. Take a copy of the /etc/bootpd.plist file this will create, e.g. /etc/bootpd.plist.template, and then disable internet sharing again, which will remove the /etc/bootpd.plist file if it still exists. Now rename your template back to /etc/bootpd.plist and edit it.

The options are all well documented, and it turns out that you need hardly any of them to get up and running.

The key options are

• dhcp_enabled: an array of network interface device names to answer dhcp requests on – I just have en0, which is the built-in ethernet
• Subnets: an array of property dictionaries, that represent networks we’re interested in serving. We only want a single dictionary for 192.168.1.0/24.
  • net_address:, is the network address – 192.168.1.0,
  • net_mask: the netmask for our subnet range – ’255.255.255.0′,
  • dhcp_router: default gateway address – 192.168.1.1
  • net_range: an array of strings representing the bounds of a pool of addresses to allocate from – 192.168.1.12 to 192.168.1.254
  • allocate: a boolean that is set to indicate that we’re interested in issuing addresses for this subnet

Most of the other defaults are sensible. I’ve kept all the other values that were generated for my template. Here’s what I have in my file.


<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>Subnets</key>
    <array>
      <dict>
        <key>_creator</key>
        <string>cms</string>
        <key>allocate</key>
        <true/>
        <key>dhcp_domain_name_server</key>
        <string>208.67.222.222,208.67.220.220</string>
        <key>dhcp_router</key>
        <string>192.168.1.1</string>
        <key>lease_max</key>
        <integer>3600</integer>
        <key>lease_min</key>
        <integer>3600</integer>
        <key>name</key>
        <string>192.168.1</string>
        <key>net_address</key>
        <string>192.168.1.0</string>
        <key>net_mask</key>
        <string>255.255.255.0</string>
        <key>net_range</key>
        <array>
          <string>192.168.1.12</string>
          <string>192.168.1.254</string>
        </array>
      </dict>
    </array>
    <key>bootp_enabled</key>
    <false/>
    <key>detect_other_dhcp_server</key>
    <integer>0</integer>
    <key>dhcp_enabled</key>
    <array>
      <string>en0</string>
    </array>
    <key>reply_threshold_seconds</key>
    <integer>4</integer>
  </dict>
</plist>


Next, create two empty files that bootpd expects to use. ‘/etc/bootptab‘, for any static address maps, and /var/db/dhcpd_leases, which will be a persistent database for issued leases. Now connect to the router, and disable it’s DHCP server.

The bootpd binary lives at /usr/libexec/bootpd. If you run it from a terminal with a -d flag, it will stay in the foreground and emit debugging info to stdout. You’ll need root privileges for it to run, I just used sudo /usr/libexec/bootpd. Now request a dhcp address from a different network client. I used an iPad. It’s a good idea to make a note of the network MAC address. If everything is working, you should see some output acknowledging the request, and then some more as a lease is issued. The client should then configure it’s network interface with all the settings from your Subnet definition above. If it doesn’t, and the output isn’t helpful enough, there’s also a further -v switch for more verbose logging.

Initially I had trouble getting any leases issued although all requests were logged fine. It turned out I’d misconfigured the netmask when I set up the static address for the mini. If the network details don’t match the defined subnet exactly, then bootpd will just fall back to default behaviour for the subnet, which is to just observe. Once I fixed that, things started working as they should. By default, a line is written to logs in /var/system.log for every request recieved, and one for every lease issued.

The remaining task is to configure the service to run as a daemon from launchd. Luckily, there is a launchd profile for bootpd present, /System/Library/LaunchDaemons/bootps.plist.

You can install this persistently into launchd like so

sudo launchctl load -w /System/Library/LaunchDaemons/bootps.plist

Running sudo launchctl list should then show a com.apple.bootpd service enabled. If for some reason you need to disable it once again, you can uninstall the service using

sudo launchctl unload -w /System/Library/LaunchDaemons/bootps.plist

Except Laurie didn’t. Despite my attempts to dissuade him, he registered the domain, and started knocking together some pages based on the earlier jokes. I chipped in a couple more suggestions, and suggested some error messages, and within twenty minutes or so he had an operational site. Then we shared it with a couple of like-minded people, and left it be. A few of the other people at work passed it around, and a couple of people submitted it to reddit.

Within an hour or so things had started to really snowball. One of the reddit submissions gathered hundreds of upvotes, and for a period of time we were the number one story on hacker news. Laurie added a twitter button and a comment form to the site, and retweets and emails started accumulating fast. By mid-afternoon the site was approaching 200 hits a second, which it handled with aplomb, because he had coded it efficiently, and
configured the server sensibly.

It felt great to watch so many people comment positively about some of my dumb jokes, pretty much in real time. It gave me a really direct experience of something I’d always innately understood about the internet, but had not yet witnessed close to home; the ability to quickly reach an appropriate audience for almost any content, regardless of how specialised. Our little shared joke quickly reached out to thousands of people, who found something within it they also related to. This really amazes me.

It also showed me something about my own character. While I was perfectly happy to joke about the idea, it needed somebody like Laurie, with the skill and enthusiasm to pick up on it and make it into something tangible and exciting. I’d instinctively shied away from broadcasting it further than my desk, and my initial reaction was that developing it any further would be a waste of time and money. I was very wrong about that, it turned out to be an interesting experience, and enormous fun. I think this means I should endeavour to be a little less cynical.

/Developer/SDKs/MacOSX10.4u.sdk/usr/include/stdarg.h:4:25: error: stdarg.h: No such file or directory


This error message both confused and perturbed me, because stdarg is a fairly fundamental component of a working C library, and I am pretty certain that my compiler isn’t that fundamentally broken.

Picking apart the build output from the generated Makefile, I see that it is setting the -isysroot gcc flag, to /Developer/SDKs/MacOSX10.4u.sdk/. I presume this is because the python installation is built to use the OS X 10.4 compatability SDK. This is why it’s pulling in /Developer/SDKs/MacOSX10.4u.sdk/usr/include/stdarg.h. That header is a stub, and included the following stanza


/* GCC uses its own copy of this header */
#if defined(__GNUC__)
#include_next


#include_next is a gcc extension to cpp, and instructs the preprocessor to start searching for the include file again starting with the next directory on the include path after this one. Standard libraries like stdarg and float can be quite compiler specific, and as the comment indicates, GCC is expected to have it’s own copy of this header file, which would be put away somewhere under /usr/lib/gcc.

At this point, a nagging memory of building cocoa apps with XCode resurfaced, suggesting that the 10.4 SDK isn’t compatible with gcc-4.2 ( the system default gcc under snow leopard ). GCC 4.0 is supplied though, for use with building against legacy SDKs. On this whim, I tried exporting CC=/usr/bin/gcc-4.0 and rebuilding, and everything worked as it should.

From inspection, it seems like the snow supplied leopard python is built to use 10.6 SDKs and gcc-4.2 and may well be a more sensible python to use. Further googling ducking, turned up this bug report.

Apple80211.framework/Resources/airport

It doesn’t come with a man page, but --help will print a usage guide.