Now precisely what use is this to anyone? I can't back up my files in a usable fashion because I want my home directory to be secure? I have to log out to achieve even the monolithic protection of being able to restore my entire home directory in one lump? I don't log out; I lock my system and hibernate it; it's a single user system and the hibernation works extremely well.

And to add insult to injury, this is the error message I get *after* spending hours decrypting and re-encrypting my home folder, discovering backups were silently failing, and turning TimeMachine off and on again. The first time I tried this after upgrading from Tiger I was told that "Your home folder cannot be backed up as it was encrypted with a previous version of OS X. You will need to turn FileVault off and on again to enable Time Machine backups" (this is not verbatim, I didn't expect to need to screen grab it). And I get a little help dialogue (or possibly a link to a video, I don't recall now) showing me how to do this, and how to chose 128- or 256- bit security. Except that when you try and to that, it gives you no such choice, takes hours to de- and re-encrypt, and still doesn't let you back up anyway!

It would appear that the FileVault and TimeMachine teams at Apple are not on speaking terms, and that neither are giving correct information to the documentation team. This is shoddy, and the differing dialogues suggest that this is an incomplete feature that was rushed to release.

For now, I'll be sticking with Retrospect backup. That backs up what it claims, including FileVault folders, encrypts the backups on request, and restores properly. The interface isn't what you'd call user-friendly, but still it's a bit more friendly than a system that turns around and says "Oh, I didn't back any of your personal files up - didn't you guess?"

NOTE: This will not work on Leopard / 10.5 - the httpd on there runs as an x86_64 binary, and the instructions below create an i386 php5 build, which can't run as a shared module. Fink libraries do not yet appear to play nice with x86_64 builds of php5.

My current workaround is to rebuild apache from source as i386, with ./configure --enable-rewrite --enable-so - note that this means there will be 2 apache binaries in the system unless you configure to install over the one apple provides.

PHP 5.3 appeared on snaps.php.net today, and one of the features therein is namespacing. Now I've been curious about namespacing for some time - my code's currently full of class prefix_classname{} declarations - so I thought I'd like to try it out.

Now, the first slightly trick issue here is that I use a MacBook Pro as my main dev system, and installing PHP on these systems from source is supposed to be a bit tricky - so I've been using Marc Liyanage's prebuilt packages for some time.

However, while installing from source is certainly non-trivial, it's not actually all that tricky.

I started off with Guillome Boudreau's installation guide, in combination with my own old install instructions and config statement. And a PHP 5.2 stable tarball, as I thought I'd try running a known-working codebase before diving into development code.

Note that I'm going to assume you have some basic experience unpacking tarballs and installing PHP on linux here, and am going to miss out some steps. If you don't, read my older post first.

First things to note - the package list I show in that old post simply doesn't work with fink's apt-get command line - most packages which would be something-dev on debian seem (corrections welcome) to be something-shlibs in fink. So, I started off with a reduced fink line of: sudo fink install libjpeg libtiff libpng3 libmcrypt ming flex, which all seemed happy, then tried the configure command I last used on my live server (ubuntu linux):

./configure --disable-cgi --disable-rpath --disable-debug --disable-magic-quotes --disable-posix --with-apxs2=/usr/bin/apxs2 --with-mysql=/usr --with-zlib --with-dbx --with-ctype --with-openssl --with-pcre-regex --with-gettext --with-mcrypt --with-mhash --with-iconv --with-gd --with-jpeg-dir --with-png-dir --with-zlib-dir --with-xpm-dir --with-ttf --with-xsl --with-tsrm-pthreads --with-tidy --with-freetype-dir --enable-gd-native-ttf --enable-calendar --enable-mbstring --enable-spl --enable-ftp --enable-bcmath --enable-sockets --enable-dom --enable-xml --enable-soap --enable-libxml --enable-session --enable-simplexml --enable-memory-limit --with-curl=/usr/ --with-curlwrappers --with-pspell --enable-pdo=shared --with-pdo-mysql=shared --with-pdo-sqlite=shared --with-sqlite=shared --enable-exif

Now, that didn't entirely work - not surprising as there's a few server-specific paths in there. Also, some of the packages needed weren't installed yet. Saving you the gory details of all the iterations I went through, I also executed sudo apt-get install freetype freetype-shlibs to try and solve a 'missing freetype.h' error (it didn't work, I've sacrificed freetype support for now), sudo apt-get install libmhash libmhash-shlibs to add the missing 'mhash', and sudo apt-get install mysql14-dev mysql14-shlibs for missing mysql client libs. I'd rather have installed mysql15-dev as those are mysql version 5.x, but the packages are missing in fink. It seems to work anyway.

I also admitted defeat on a few non-essential config options: --with-gettext (due to a complaint about a missing intl.h) and --with-pspell as I couldn't be bothered to install it (most browsers have spellchecking now anyway). Finally, the config script ran, but warned me:

Notice: Following unknown configure options were used:

--with-dbx
--with-ctype
--with-libjpeg=/sw
--with-libtiff=/sw
--with-libpng=/sw
--enable-memory-limit


so you could probably drop those too.

Then on compiling it, I got complaints about a syntax error in tidy.h, so I dropped the tidy extension too.

So, the config options I used in the end were:

./configure --disable-cgi --disable-rpath --disable-debug --disable-magic-quotes --disable-posix --with-apxs --with-mysql=/sw --with-zlib --with-dbx --with-ctype --with-openssl --with-pcre-regex --with-mcrypt=/sw --with-mhash=/sw --with-iconv --with-gd --enable-gd-native-ttf --with-libjpeg=/sw --with-libtiff=/sw --with-libpng=/sw --with-jpeg-dir=/sw --with-png-dir=/sw --with-zlib-dir --with-xpm-dir --with-ttf --with-xsl --with-tsrm-pthreads --enable-gd-native-ttf --enable-calendar --enable-mbstring --enable-spl --enable-ftp --enable-bcmath --enable-sockets --enable-dom --enable-xml --enable-soap --enable-libxml --enable-session --enable-simplexml --enable-memory-limit --with-curl=/usr/ --with-curlwrappers --with-pdo-mysql=/sw --with-pdo-sqlite --with-sqlite=shared --enable-exif

This works, and compiles; running make test does throw up a few fails, but the result seems to install OK, and running phpinfo(), my unit test suite, and the code itself, seems to work quite happily.

As mentioned, the first run through of this was with 5.2; repeating the exercise with php5.3-200710161230 Just Worked.

At some point soon I'll start playing with the namespaces; however in the meantime I hope the above instructions help someone.

Some time ago (just before Christmas, oddly enough) I was looking around to find a comparatively cheap way to investigate GPS systems. The main requirement was for a cheap but reliable GPS system that could transfer data to my powerbook in an open format, that could be used for photo-geographic correlation and shared with projects such as http://www.openstreetmap.org/ and http://www.geograph.org.uk/. Colour display and on-screen mapping weren't required.

It turned out that the low-end Garmin systems (eg the etrex range) almost all perform this task quite adequately, as they support RS232 (serial) interfaces with a range of protocols, including Garmin's own standard and the NMEA interface that many applications use. Powerbooks (and, as far as I know, all new Macs) don't actually come with a serial port but (and this seems to surprise many) you can easily add one via a USB connection. The hardware generally recommended is the Keyspan USA-19HS - and I can vouch that this works perfectly with the Garmin etrex (the yellow base model) on an Apple Powerbook 12" with OSX 10.4.3. Naturally, you'll also need the Garmin PC serial cable. (It's slighty ironic that the signal traverses the first 12000 miles through the ether with no problem, and then you need 2 cables and an adaptor to get the signal to cover the last 3 feet. But it works).

Once you've got the etrex wired up to the powerbook, the next trick is to get the data out of it into a usable file. There are numerous pieces of software for this, but it can be hard to tell which support this strange pseudo-serial interface. One that I've found to be very simple and effective is Link2GPS from HikeTech - a $12.95 piece of shareware that will download files from the etrex in the open GPX XML format. Once you've extracted your track (and you can just leave the etrex to record as you wander around), you can use it as input to any app you care to write.

It's worth noting that the etrex has a certain degree of trouble capturing locations in city centres ("concrete canyons") where you can only see a small sector of sky. In narrow streets with high buildings you simply won't get a location. But for suburbs, rooftops, and open farmland you can fairly easily acheive a 10-metre resolution or better, enough for most puposes. It also depends how you carry the device; the external pocket of a leather jacket gets zero signal, but the top pocket of a rucksack gets a good signal in most circumstances. You can also get a reasonable signal from within a car in open country, and it appears (though I've only partly tested it) that Route 66 can use the NMEA interface to track your location in this situation. And, when Google Earth gets a proper Mac release, it should be possible to have some fun with that.

See also: http://www.openstreetmap.org/wiki/index.php/GPS_Reviews