It is nice to see someone apologising for their planned failure to consider Linux users. It's ridiculous that they even have to. It seems to me that these people have spent way too much effort on making the logo and menus scroll in from the left and right of the screen, and not enought effort on the actual functionality of their website.

I fail to understand what benefit they have gained from using the Pizza UI for their logo & menus (yes, really) rather than using simple links - or CSS-based menus, if they needed fancy. The page layout doesn't actually need anything more than simple text links. The logo (thankfully) does nothing after it's page-load scroll. For extra 'fail' marks they substitute graphics when I initially arrive with Javascript disabled (and wearing my tinfoil hat) but the graphics give me the appearance of a menu without actually performing a useful function.

Since leaving Catalyst to follow my interests there seem to be a neverending number of organisations e-mailing to my old e-mail address, which I have to go through to update to a new e-mail address. This evening it was Air New Zealand's turn.

Going through their update form, I noticed a few other little details were wrong, and they had a couple of my pet hates down pat:

• My surname was spelled 'Mcmillan' rather than 'McMillan'
• My city was down as 'Wellington' rather than 'Porirua'

For no particularly good reason that I can see, they don't provide me with the ability to edit my surname. I have to ring some 0800 number, and I was kind of all 0800ed out having had to ring TelstraClear earlier. (To question their sense in wanting to deliver a password for an e-mail account to that same e-mail account... but that's another story...)

I can at least correct the city, though, right?

Writing free, open-source software is an incredibly public activity. Everything you do is in the public eye, and google will inevitably discover your site, and then other people will find your software, and download it, and this is a good thing. It's why you're doing it, after all, and it's so nice to receive those occasional 'Thank you for your software' e-mails. There are occasional exceptions, however.

Today's practical exercise is to demonstrate your skills responding to the annual student exercise question, like this one, following on to finish a real exchange while still retaining your sanity to the maximum extent possible. Humour will receive bonus points.

Here goes. First up, we have an e-mail arriving out of the blue which looks like this:

how to run the caldav server
in window
i have download it from the http://wiki.davical.org/

The IPv6 wave progresses apace. Well, perhaps not 'apace', but it is moving...

The latest kernel exploit has incidentally had some local fallout in causing more of our boxen here to be upgraded to kernels with IPv6 support, and as a consequence our mail server is now reachable on IPv6. Some have suggested that making it only reachable on IPv6 is a good solution to spam but I suspect that there are still a few mailservers out there that we do want to receive e-mail from which are not IPv6 capable yet!

Since I can now SMTP and IMAP happily over IPv6 I decided it was time to get more adventurous. IPv6 is now in Squid3 head, so I built Etch packages of that and it seems to be 'basically working' in a few places now. We've been using ircd-ircu for a long time for an IRC daemon and it similarly seems that now has IPv6 support, so I backported that to Etch as well.

Packages are available for i386 and amd64 from my repository:

deb http://debian.mcmillan.net.nz/debian etch ipv6
deb-src http://debian.mcmillan.net.nz/debian etch ipv6

If I think of more Etch things that I need for IPv6 I'll put them there too. I do have dircproxy for Etch with support for connecting to IPv6 ircd but I seem to have misplaced the packages somewhere. If you're keen on seeing that then I'm sure I can reconstruct them somehow...

Now that we are having increasing amounts of IPv6 around some things are starting to reduce down to a 'Small Matter of Firewalling', which is suggesting to me that we will need manage our firewall rulesets differently for IPv6 than we have for IPv4.

In a lot of cases we can turn on/off large chunks of access related to a particular person/organisation by disabling a VPN, with the firewalling being a somewhat static monolithic overriding control above that. With the control potentially moving away from the VPN, and more directly into the firewall rules, we will need clearer association mechanisms in place. Of course we will continue to have VPNs, but they might become somewhat simpler, reducing in many cases to encrypted tunnels between exact endpoints.

Quite a few people seem impressed with the new release of Leopard, and are now looking for a CalDAV server to use with their shiny new iCal app. Unfortunately it seems that Apple wrote this primarily to work with their own (free, open-source) calendar server, which has the side effect that it doesn't work with DAViCal.

Part of the "doesn't work" is due to DAViCal not implementing some areas of the CalDAV specification, which is fair enough. Part of it is due to DAViCal not implementing some draft extensions to the CalDAV specification, which I can also understand, since it allows them to provide some useful features that those extensions are designed to support. There also seem to be some parts of the "doesn't work" which are due to a dependence on extensions beyond either of these cases, which is a little more disappointing - and quite a bit harder to implement.

So far I have made some fixes to the first point, and some additions towards parts of the second, but as of today it still does not work. This is complicated by my not having access to a Mac. Things are looking up, however, because Tom Robinson has kindly agreed to loan me a Mac running Leopard from next week.

In order to "clear the slate" for that, I will be releasing a 0.9.2 over the weekend with the various minor enhancements and fixes that have been applied over the last week. So although this upcoming release will let you add your DAViCal account to iCal 3, it still won't actually work with it. I'm hoping that ready access to the application will enable me to correct that fairly quickly.

Also waiting in the wings (and which unfortunately won't be in 0.9.2 either) Maxime Delorme has been working on SyncML support, and is nearly ready with a patch, so we can look forward to that addition fairly soon also.

Last week I installed Ubuntu Gutsy onto Heather's laptop. While Gutsy seems to be an easy task for most situations, installing it onto a Pentium 366 laptop with 200M of RAM and (particularly) an 800x600 screen was harder than it perhaps should have been.

I'm sure that most installations these days aren't 800x600, but the graphical installer in Gutsy seems determined to make this painful. I had to move the toolbars to the sides of the screen, and then I could see the top half of the buttons on each page. It was like the page was sized for 600 vertical pixels, but the designer had forgotten about toolbars and title bars - not that I could see any screens in the process I followed that needed more than 5/6 of that screen anyway. Eventually I got it installed, and it even seemed to run OK once we booted into it. That's "OK for a 200M P366 with an 800x600 screen" though.

Looking around at the price of a new laptop made putting up with that sort of performance a whole lot less palatable. The Acer Aspire 5310 (with free RAM upgrade) was $898 at Dick Smith, with a $99 cashback offer. A quick google shows that it's using the Broadcom 43xx wireless which isn't even close to being the best, but can be made to work with Linux. Everything else seemed likely to work, so we bought it.

Installing Gutsy on it was nearly trivial, though I had to install bcm43xx-fwcutter on a different PC (my laptop, which is running Debian, in fact) to get the firmware for the WLAN before I could get the wireless working. I'm surprised that Broadcom still don't make that firmware publicly available somewhere, rather than forcing people to jump through the sort of hoops that would get them wanting an Intel chipset next time.

Anyway, everything installed very easily, and the laptop is working quite nicely. Strangely neither sound, nor suspend to ram are working out of the box. They're not so important in this case fortunately, but perhaps in due course I'll try and get them working and post some details about it.

Much harder has been getting the fabled 'cashback' from Acer. I think I now know what I'm being paid $99 for. Firstly the only way to get your cashback is by registering through a webpage. Heather's first attempt to do this resulted in an error from our proxy about a malformed request, so I got called in. I tried registering using on my laptop, but couldn't even get to the cashback page. I then tried using IE6, with similar results. So perhaps it's my PC? I tried using a different PC, with the same result again!

We tried ringing them up, but they were absolutely determined that (even after 20 minutes on the phone) they were not going to accept that information over the phone. So the only way to get the cashback from Acer was via their thoroughly broken website. Even their Contact Acer page is broken in firefox just showing a blank. Firefox users need not apply.

Eventually, while spending some time in front of Heather's main computer (which had made it all the way through to submitting their on-line form before failing) I realised that the error she was getting was a proxy error from some in-form javascript submitting an invalid request, so I disabled the proxy, the form finally worked, and I managed to apply for the cashback. Now we just have to send the printed form in, along with some blood from our firstborn, the ashes of my grandmother, various barcodes, receipts and toenail clippings and we're sweet. They say they'll send us some money within 30 days. I think we should maybe frame it or something. I just know I'm going to feel really inclined to take advantage of cashback offers in future.

In Other News: DVD Slideshow

Meanwhile I've been playing with DVD Slideshow which seems to be just what my parents have been after for a while, so they don't have to keep their favourite photos on the camera to be able to show them off on someone's TV. It's great! At least it is great now after I changed all the calls to ffmpeg to add a 'k' after the bitrate parameter. But that's Open Source Software, I guess. I'll send a patch to them... :-)

After much wading through possible names, none of which really excited me, I have finally chosen "DAViCal" as the new name for my CalDAV server that was previously called RSCDS, or the "Really Simple CalDAV Store".

In the end, I chose DAViCal because it:

• seems easy to pronounce.
• combines the 'Cal' and 'DAV'.
• returns < 1000 results on google.
• doesn't make me cringe.
• didn't have a domain name registered.

That was about the hardest part of preparing for the 0.8.1 release, and now that I've done that I should manage to make the changes to the packaging, though I have no doubt that the old name will appear in all sorts of places for a while yet.

Choosing names is an important business, and I should know that from the length of time we spent agonising over names for our children, discarding all sorts of things because they had silly abbreviation collisions (like the "Royal Scottish Country Dance Society" :-) Even then, I think we got the kids names wrong, and the big one should be called "Thumper" with the little one called "Sly", but perhaps that's just a temporary annoyance and in time the names that we registered for them will fit them better.

I also recall Grant once saying that you should never use the word "Simple" in the name of your project, and he should know. DAViCal is no longer particularly simple, although I have attempted to hide the complexity from the user as far as that is possible, and will continue to do so.

Once I get out version 0.8.1 of DAViCal I will finally upload it to Debian, proper. This version has some important enhancements to its DAV spec compliance which are going to be needed by some future versions of Mozilla, and probably other things too, so it's important to push it out as soon as possible now.

Visiting Andy Chilton's blog to see how well his zaapt CMS is looking now I found this old entry and followed where it went.

I doubt if it surprises anyone that my personality type is ENTP, though it came very much as a surprise to me the first time someone suggested I was an extrovert. I also wonder if the long success of the Myers-Briggs type indicator is because of the magnificently flattering descriptions of all of the types.

The availability of IPv6 worldwide is surprisingly extensive, nowadays, but over the past years as it has slowly filtered around, people have had bad experiences with it because of poor routing. It seems that, as always, a bad rep travels about 20 times further than a good one, so an automatic response to casual problems that people see when using IPv6 is to blacklist it, without actually investigating the problem.

Take today, for an example. Someone said to me "I disabled IPv6 in Firefox because it was slow for one of my favourite sites". OK, so show me this favourite site. Show me the traceroute. Give me some facts!

Further investigation showed that although there is an AAAA record for www.crooksandliars.com, there is nothing listening on the other end! Looking at the AAAA record returned, we see that it is an autoconfigured IPv6 address of the form xxxx:xxxx:xxxx:xxxx:xxxx:xxFF:FExx:xxxx and can conjecture that the likely problem is that someone has done a hardware upgrade on their server, so they now have a different MAC, and consequently the autoconfigured IPv6 address has changed. Other scenarios are entirely possible, of course, but this is a likely one.

This is the second case I have seen where someone was running publicly available services on IPv6 using a manual DNS record pointing at an automatic IPv6 address, but I doubt that it will be the last. Unless there is infrastructure in place to automatically update your DNS when your address is autoconfigured, you are going to get bitten by this problem at some point if people remotely connect to your system for some service.

Having taken time out to go to the other side of the world to attend DebConf 7 in Edinburgh, and then after spending some time with my family, I have been somewhat distracted from things CalDAV for a wee while now. There are signs that I will be able to put a few more evenings and weekends into it in coming months.

Current Status

With the release of 0.8.0 I believe it is quite a usable application for shared group calendars. We use it at Catalyst for about 80 staff and, while we're not heavy calendar users, it manages without any noticeable performance problems.

There have been an impressive number of downloads from Sourceforge, as well as substantial downloads from my Debian repository, and I believe that the program is in tens, if not hundreds, of installations.

Future Plans

In the immediate future I want to get the basic framework for querying properties about the owner of a calendar or a set of calendars. This will be used by Mozilla soon during their configuration of a new CalDAV source, and I think that Apple iCal probably uses them already. This is partly done, but it's implementation has been slowed by the necessity to refactor the handling of the REPORT method in general to make the code more modular and readable, and to support queries and properties in a more general manner.

The refactoring of the REPORT method handling is in place now, so moving on to the handling of DAV:principal objects should become fairly straightforward. I may end up with a fair bit of quiet, undistracted time over the coming weekend so if I can get in the 'zone', it may get done, and we can start rolling towards a release 0.9.

Release 0.9 will have a new name. One from the cast of thousands that have been submitted to me so far, or one that I will hastily think up in between, but the next released version will not be called RSCDS any longer.

The main goals for further into the future are:

• Maintain interoperability with clients
• Improve specification compliance
• Extend coverage to related specifications
• Documentation improvements
• Configuration improvements
• Installation improvements

Interoperability

I think that RSCDS does fairly well on the interoperability front. Unfortunately I have no access to the preview of OS 10.5, with it's native CalDAV client (though I have been told that it works with RSCDS). Likewise, other commercial CalDAV clients aren't available to me for testing either, so I have concentrated my efforts on supporting the featureset used by the various free CalDAV clients.

My initial work focused around supporting Evolution, in particular, but with the recent effort put in by the Mozilla Calendar team the primary interoperability challenge is to enhance RSCDS to support their areas of development. If I could see how the OS 10.5 client behaves, too, I believe that would help identify a few points to extend, as well as suggesting some future directions.

The best place to review interoperability would probably be at the CalConnect Roundtable 10 but I think that without some sponsorship for airfares I probably won't be able to make that. Maybe next time.

Specifications Compliance

As I read, and reread, the CalDAV (and DAV, and HTTP, and ...) RFCs the compliance with the various specifications improves. Recently I have put a lot of work into the calendar-query report, in particular, which means it now supports querying against arbitrary properties much more comprehensively. This is important because some of the client software is starting to do arbitrary queries also, and it is inevitable that queries for the classification of events, or the percentage completion of todo items will become more common.

And now I notice that there is a new version of DAV in RFC4918, though not too many changes as far as I can see. The intent of this release is mostly to clarify, and slightly to extend, primarily in order to improve client interoperability.

Coverage of Related Specifications

In terms of general calendaring activities, the biggest hole in the CalDAV specification at present is standardisation around the location of other people's schedules. The current draft of the Scheduling Extensions to CalDAV appears to address that, and a lot more besides. I expect to start working on parts of this at some point, but perhaps not sooner than I see a client which starts using it, or when it is ratified, whichever occurs soonest.

Documentation

The documentation is OK. The wiki, in particular, is a reasonable resource for resolving problems (I believe), but it would be good to have some documentation of other things.

One area that could do with enhancement is some documentation of how to check out a copy of the code, and how to provide patches back to me. Even better if other people can maintain their own trees which I could pull patches from, since we're using a distributed version control system (Git) to start with.

Configuration

The administration interface for RSCDS is OK, but could do with a few improvements to make it more usable. Really there are not a lot of reasons to be in the administrative interface, so these improvements should be relatively few, and relatively easy.

This would be a good area for someone interested in helping out to become involved, because it does not entail reading large reams of RFCs, or watching tcpdumps scroll past for the debugging.

Installation

One thing that I have done right, I believe, was to provide the software from the beginning in a packaged form to make the installation easier. Although the software is packaged for Debian, however, it has not yet been uploaded to the archive because I have been waiting for the webapps-common package to enter Debian so I can use that for configuration.

I think I have waited long enough though, so I will upload the next version to Debian for use by a wider audience.

Security

Security has always been a focus for me and I have had the code reviewed for any obvious security flaws. If any particular vulnerabilities are found they will be addressed with appropriate haste.

Retrospective

I've been working on this for a little over a year now, and I think I have largely met my goals for the project. It has certainly been an educational experience for me, and the effect of this work on other projects that I also participate in has also been valuable.

Any new open-source project is always at risk of the developer losing energy and interest, but I believe this one has made it to a state where the bulk of the infrastructure effort has been done, and there are enough interesting challenges in the future to continue to keep me (at least) working on it into the future.

The scope of this project is good, in that it is not at risk of expanding to take over the world. The intention behind this is simply to provide a back-end service for client software which should be very much Someone Else's Problem. In reality there have been times when I have had to get to grips with some of that client software in order to resolve problems, but those have by and large been good experiences.

This week the State Services Commission bribed^Wbrought Rick Jelliffe over to New Zealand to be involved with an XML governance workshop they were running, and we were lucky enough to be included in his schedule because of some work we are currently doing with them.

Rick is a thorough geek, doing what he loves and getting pulled all over the world to do it, and we were lucky to be able to get a presentation to the NZOSS this evening giving his points of view about the readiness of the FOSS world to tar and feather him when he casually mentioned that Microsoft might be interested in paying him to provide some sanity to OpenXML discussions on Wikipedia.

It's an interesting tale of headline writers successively deciding that something is a 'bit bland' and sexing it up a little. Each person taking the previous headline and making it more inflammatory - even when the article content itself hadn't changed, which was based on the worst kind of Slashdot rant. A sad but frequent result of the general mass media bias towards 'exciting' news.

Humorously enough, Rick had previously edited his own Wikipedia page - normally a complete no-no, but since he didn't say anything contentious at that time it still remains. I was looking at it before I met him on Wednesday and noticed the talk page asking for a photo, so I took one and uploaded it today before his presentation.

I must finally admit, also, that Rick has convinced me that it is in the best interests of free software and of standards that this probably should be accepted, in spite of a number of valid technical criticisms.

I have just received the most bizarre share purchase offer I've ever seen. It seems some weirdo company called Colonial Capital Corporation wants to pay about 60% of the market rate to buy my shares in Tower Australia Group.

I only have these few shares because of some insurance policy I used to have, and probably I should have sold them years ago, but to be offered 60% market value seems pretty insulting. I wonder how many suckers will be fooled?

A quick search for CCC shows how well-recognised this David Tweed asshole really is.

Good to see that Wikipedia has a pretty thorough write-up on the guy. Maybe someone has some pictures of him that they could upload there as well, so we can recognise him in the street. The Melbourne Age can help out a little on that point, as can the Sydney Morning Herald though he always wears sunglasses, it seems.

The registered office of the Colonial Capital Corporation (NZ Company no. 1891726) is "Andrew James Kennedy, Level 2, 6 Clayton Street, Newmarket, Auckland". I guess if you know that person you should make sure they are aware of the kind of amoral shyster they are fronting. It seems that particular location is a "virtual office" that you can rent for only $120/month from the "Auckland Business Centre Limited", Ph. 09 522 7130. I wonder if Mr. Kennedy takes phone calls, and what company name he gives when he answers?

A previously infamous company also with David Tweed as sole director is National Exchange Ltd (NZ Company no. 1559669). The office for that one was at Suite 102, 63 Remuera Road. No name associated with that, but the constitution is pretty much a license to ensure any funds get offshore as quickly as possible, and a Google search suggests that the address generally has some very dodgy businesses associated with it.

My packages of eaccelerator for Etch caused me a problem last night when I pulled in a new security fix for PHP5 and they all stopped working so I've built some new ones against the new PHP5.

I've also added a few enhancements:

• Create the /var/cache/eaccelerator directory with appropriate permissions
• Install a default basic configuration in /etc/php5/conf.d/php5-eaccelerator.
• Clean out old cache files from /var/cache/eaccelerator

The packages are available in my Debian repository built for i386 and for amd64, with a apt sources line like:

deb http://debian.mcmillan.net.nz/debian etch awm

The repository is signed with my private key, 0x8f068012, which is fairly well-connected and which you can get from subkeys.pgp.net and many other places.

Enjoy!

I've now moved lots of things to a new (old) server which should be noticeably faster than the old (old) 500MHz PIII-based server. Of course since Etch was released I'm now running on Etch. This also meant an upgrade to PHP 5.2, so I spent some time getting bitten by this bug with Drupal 4.7.4 and PHP 5.2 and had to upgrade to 4.7.6. Consequently there has been a wee bit of bouncing up and down today...

In the process I have also upgraded my packages for eAccelerator so that they would work with Etch. Since Andrew Hutchings had taken them off me and played a bit further I have now taken his packages and built some newer ones, including a patch for 0.9.5 to work with PHP 5.2, and an additional build dependency. My new (old) server is still 32-bit, so these packages are only built for 32-bit as yet. I'm currently trying to find a 64-bit Etch box I can build them on as well, but everyone at work seems to have gone home.

You should be able to fetch them from my package repository by adding it to your sources.list with:

deb http://debian.mcmillan.net.nz/debian etch awm


Naturally that repository is signed with my public key (8f068012), which is in turn signed by lots of people in the Debian community and should be readily identifiable - not that that implies trust, of course :-).

Also, since my new (old) server is in a different location (and to ease the transfer) everything is on a new IP address (and a new IPv6 address). Hopefully the system's accessibility over IPv6 on http://ipv6.geek.nz/ will be slowly improving as we incrementally improve our IPv6 connectivity with the rest of the world.

I see Brenda talking about wanting to use "Ruby", and trying to install "Rails". This conflating of the two terms annoys me.

"Ruby on Rails" is a web development framework which is written in Ruby, and which uses Ruby for some customisation, but the primary learning curve in using it is to learn the framework. I installed it ("apt-get install rails", of course :-) and tried using it but found it frustrating, though that may be because the default Debian install was against MySQL.

Ruby, on the other hand, is a language which is generally just as suited to writing off-line text processing scripts as it is to writing on-line scripts. It is also a language which has good database independence and GUI libraries.

Two of the talks I went to at LCA this year which have had an impact on my coding were one about Puppet, a systems management application written in Ruby, and one about writing GTK programs in several languages. The GTK people didn't quite make it through their ambitious schedule so we only got to see them writing GTK in C and in Java (not in Python) but it did suggest how easy it all was.

When I got back to NZ I put those two together and started writing (well, rewriting really) an application in Ruby/GTK, and I have found it a very nice language. It seems that every time I learn something new about Ruby my code gets shorter and provides more function in a clearer and more readable way. Fun.