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.

Ten Years of Catalyst IT It's our tenth anniversary at Catalyst this year. Since we have our company 'birthday' in the middle of the year we normally have a private party and, while that's been good in the past, we felt ten years was a milestone of some kind and we wanted to do something a little more special... So this year we decided to set up the New Zealand Open Source Awards, which are all set to go in October. There have been lots of entries rolling in to recognise all sorts of interesting projects and unsung heroes of the revolution, but I'm sure there are still a few out there that we haven't heard of. If you think we might have missed one you've only got 10 more days until nominations close at midnight, New Zealand time, on the 17th of August. Nominate your favourites now in the following categories:

• Open Source Ambassador
• Contributor
• Software Project
• Use in Government
• Use in Business
• Use in Education
• Use for Community Organisations

Note that this is not a vote. All entries will be judged on their respective merits by a panel of New Zealanders with a broad technological background. Good luck, and may the best people / teams / departments / organisations win :-)

A recent thread which started on the Debian Release mailing list caught my eye this week. I attempted to aid the migration of this thread to the debian-ipv6 mailing list, which is really a better place for this and sorely in need of controversial topics for discussion. It is interesting how people can so blindly decide that broken things should be destroyed. Repair often appears not to be an option, even for a long-term, wide-reaching effort like this, though we are all working on open-source software! In this case there are an unknown number of less fortunate people in the world who are located behind some kinds of broken DNS infrastructure which discards 'AAAA' lookups. Of course 'AAAA' lookups are attempts to resolve a name to an IPv6 address, and the resolver in a 'modern' libc (i.e. one from the last five years or so :-) will try to retrieve an IPv6 address before it attempts to resolve a name as IPv4 with an 'A' lookup. That is how the standard is written, so if you want to comply with the standard you have to do it that way. Other things also interfere, but this element of the specified behaviour seems to cause the most annoying and pointless whingeing I have heard. I suppose that the people who want working IPv6 make it so, and do not have problems with this behaviour. But it seems that people who are behind this kind of broken DNS either disable IPv6, or they have to whine about IPv6 being turned on by default, and can't we please all go back to the good old days. What's wrong with IPv4 anyway? Doesn't NAT solve all of it's problems? Are we sure this new (heh!) technology is safe? Fortunately some people are so good at making their pain felt by other people that they can get other people to do their work for them. So Mithrandir has written a nice elegant patch for libc6 so that it won't do the IPv6 lookups unless you have a usable IPv6 configuration. I've filed bug #435646 against Debian to get this included, but Aurelian Jarno justifiably wants a few people to test it a bit harder... So I've taken the original patch and tweaked it to apply against current libc6 sources (2.6-5) and tested it for myself. It works as desired, as far as I can see, when comparing behaviour with an unpatched system. The patch is attached to the bug report, of course. Perhaps some other people out there can put a wee bit of CPU into testing this for other environments so that we can make life easier for those people with no time / inclination to use IPv6, to ensure that they don't just disable it because it is making life too painful for them in it's current form? How to build libc6 for fun and proft If you have appropriate deb-src URLs configured, and are running Sid, then the following will let you build a local copy of libc6 with the patch. This is probably better testing than if I just make my packages available (which are only i386 in any case).

apt-get build-dep glibc
apt-get source glibc
cd glibc-2.6
debian/rules unpack
cd build-tree/glibc-2.6
wget http://tinyurl.com/3xzm3o
patch -p0 <glibc-only-lookup-ipv6-if-it-makes-sense-debian.patch
cd -
dch --newversion 2.6-5+v6 "Apply IPv6 Resolver Sanity"
fakeroot debian/rules binary

Wait a few hours for it to build... Install... And then confirm that this only does 'AAAA' lookups if (when) you actually have a global or site scoped IPv6 address. When you only have a loopback or link local IPv6 address then you should only see 'A' record lookups. Step 3: profit! Whoops! I forgot the fun bit: please update the bug report :-) What the patch does In my opinion this is quite an elegant solution from Tolleff. He has picked a single characteristic of the IPv6 interfaces to further refine whether the IPv6 configuration of some interface is actually usable. With IPv6 it is much more common to have multiple addresses assigned to a single interface. Interfaces are automatically configured with a link-local address which is not globally routable, and the loopback interface is also configured with the IPv6 equivalent of 127.0.0.1 (which is "::1"). To get a usable IPv6 setup you will also end up with a more widely usable address. In most cases this will be a global address, meaning that it is (in theory) globally routable from other people who also have global addresses, or you could have a "site" address, which is the IPv6 equivalent of RFC1918 addressing. The patch considers that for the purposes of name resolution, it will be pointless to do AAAA lookups unless you have an address of the second kind. This means that people behind broken DNS won't be impacted unless the try and set up IPv6, and people who don't try and set up IPv6 won't get the 'hesitation' while their system attempts to resolve each address in IPv6 space first. It will also mean that when people start to enable IPv6 around them, their setup will continue to work correctly.

Is there anything Keith Packard can't do? Tore, Simon Richter, Keith and others have had great fun restoring the pipe organ that was oh-so-conveniently located in the night venue. I don't think that the landlord would have expected this. Apparently we were instructed not to break or fix anything but this was just too tempting for a bunch of geeks. I particularly like the fact that there is no sheet music - that's what laptops are for, surely! More pictures of the night venue.

I'm at DebConf7 now, in Edinburgh, and it is great to catch up with the great bunch of geeks that is the Debian community once more. As well as working on general stuff through DebCamp (the week leading up to DebConf proper) I'm helping out in producing the video streams running the sound desk or one of the cameras. The streams are highly recommended, and you can find them on http://streams.video.debconf.org:8000/, though for the New Zealanders reading this they do, of course, happen at seriously silly times of the day. Here is the DebConf7 schedule if you want to watch :-(. We'll get the talks up in a downloadable format as soon as we can, and I'll point people at them again then. Highlights of the conference so far have been a talk by Nick Mailer on Debian Day, which was a very nicely presented run-down on the ancient history of intellectual property laws here in the UK, and the very interactive session this evening on Maintaining Packages with Git, which had some very good tips from David Nusinow as well as a lot of support from the audience. I now better understand why Penny is so keen on "git rebase", though hopefully I would have figured that out if I worked on more shared projects. It's great to see 150-odd people in the room, many of whom had some experience with Git, and there were some very heavy users with great insight into it's strengths and weaknesses. Contrast that with DebCon5 in Helsinki where I almost felt Martin Langhoff and I were unheard when we acclaimed it, or even at LCA in 2006, where Martin did a first pass at importing X.Org into Git. Of course Git itself has come a long way from then too. Another very interesting session was Martin Krafft talking about 'netconf', which is his proposal for a replacement of the ifupdown infrastructure using a much more stateless, event driven approach. This definitely looks like a well considered design and I hope he can pull it off. I've got my own talk on Thursday, so I'll be concentrating on pulling that together for the next few days. If as many people come as have said they will (50% of the people signed up for any talk at that time) then it will be a very stuffy BoF room. The venue here in Edinburgh is great, and it's nice to have a good network connection. Everything has been running very smoothly for the participants, as far as I can see, though I know plenty of people have been working very hard to make it so, behind the scenes. Weirdly, after only a short time using IPv6 at home and at work, I am finding I miss not having it readily available IPv6. I unfortunately had to disable my tunnels because adding 350mS latency to everything makes the web very frustrating. Perhaps next year we'll be able to add IPv6 to the desired network features for DebConf8 in Mar del Plata. Good to see that in the meantime the availability of the new IPv6 nameservers for .nz has been announced in my absence though.

I followed the advice of the lazywebs a while ago and bought myself a phone (Nokia 6100) on the local auction website then went around to the local Vodafone dealer and bought a SIM card for it. When I signed up I ticked the box saying "Enable Global Roaming" and now that I'm travelling I realise I should have actually confirmed that happened before I left the country, because it didn't happen. Now I'm sitting in Melbourne with only the (free :-) Wifi to keep me company. So looking at the Vodafone site, it appears that I could dial "777" to enable global roaming. Apparently I should have done that a few days ago, because it sure won't work now. Perhaps this "Manage Your Account" thingy will work? A period of perusing pages of FAQs follows, and I eventually conclude that it would work. Except that when I try and register for the service I am told that my phone number is not valid. Yes, I moved my old number across to Vodafone, about the same time Brenda was lamenting the inadequate preparation Vodafone did for Mobile Number Portability, and while the actual phone has been working, Brenda did note back on April 1st that "you can't use the website to manage your account". Two months on and it still isn't possible, which is pretty poor really - you would think Vodafone would be actively encouraging people to move across to their network. So I'm effectively phoneless until I get to Edinburgh and can buy a SIM card. At least I can still get on IRC and ask someone to call Heather and tell her why I'm not phoning.

This is a reply to Andrew McMillan Contracts for people to work on Open Source Software, posted on my blog because of yet another stupid eyetest. It looks like there might be a loophole: Clause 2 maybe gives $ COMPANY rights to access the source code of later versions, just because $ EMPLOYEE used one version at $ COMPANY . I don't think it's fair for $ COMPANY ownership to be the default instead of joint ownership. I didn't spot anything obviously missing. I'd like to see $ COMPANY changed so that the workers are owners rather than merely employees, but that's probably not on offer ;-) However, that's part of how TTLLP side-steps the question - it's a partnership, not a employer-employee situation where the employer's owners try to own the fruits of the worker-employees' labour in addition to the company's assets.

A few years ago we needed to introduce employement contracts for all staff at Catalyst. When we got the example contract back from our HR consultant, she had quite naturally biased it strongly in the employers favour, and as a consequence it had a very anal and lawyerly clause in it regarding the ownership of intellectual property. This clearly wasn't going to work well in our environment so I decided to take the opportunity to try and write a clause which was fair and reasonable, which considered the likely desires of both parties, and which expressed an understanding of the sort of environment which often happens with free open-source software. It seems that many people who are interested in working on open source software are also people who will work on (i.e. fiddle with :-) things in their spare time, but they will not necessarily consider the possible consequences of using conmpany resources to do so. I have heard of situations where employment contracts (or perhaps even government enacted legislation) will give ownership of an individual's work to their employer in such situations, so I also wanted the contract to make it clear where and how this might happen. I would like to hear people's comments on the contract clauses which we use here. Is this fair to both parties? Have I missed something? Is the meaning clear? Also, I need to make it clear that it is OK for people to use this text, so I hereby place the text of the following Intellectual Property clause in the public domain. Intellectual Property

1. All intellectual property, including source code, objects and documentation, relating to work carried out while in the employment of $ COMPANY , remains the property of $ COMPANY , subject to the exceptions outlined below.
2. All intellectual property, including source code, objects and documentation, owned prior to joining $ COMPANY remains your property. If you choose to use such intellectual property, including source and objects during your time at $ COMPANY , $ COMPANY will have the rights to their continued use in perpetuity, including access to the source code of all versions of such software in use at $ COMPANY .
3. If $ COMPANY asks you to do something, then we expect that while you work on that something, you will be being paid by us and we (or our clients) will own the IP. In some cases we may elect to open-source that, and may decide to jointly own the IP or make some other arrangement, but it would be at $ COMPANY s option.
4. If you work on something by your own choice, and on your own time, then you are welcome to own the IP, but if you use the premises or computers of $ COMPANY to do that work then you must license it under a free, open-source license agreed with $ COMPANY .
5. $ COMPANY may choose to fund some part of your time to work on OSS projects in a non-directed way. $ COMPANY will expect to own the IP for such work, and to participate in the choice of license for such code.
6. All of the above is subject to confidentiality of client information, and constraints which clients may specifically request in relation to specific project work from time to time.

Over To You I wrote that because I couldn't find examples around the place of similar things. I guess I still see people looking for that sort of thing so I'm publising it here with the idea of providing a seed which can perhaps grow into something else. A few specific questions I would like you to think about:

• Are there any loopholes in this?
• Does this seem like a fair agreement?
• Is there anything missing?
• Is there any part you would like to see changed?

Then, perhaps, if we can see some general agreement on what would, or would not, be a useful standard we can encourage people to use it in their future contracts. I am hoping that through your collective wisdom I will be changing this clause in Catalyst's standard employment contract.

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.

I see that Jari Urpalainen has written an CalDAV Apache module to support some basic CalDAV functionality. Excellent. Meanwhile my own CalDAV server is going through a period of stabilisation before I start in on some of the handling of "Principals", probably next month. And CalDAV has become RFC 4791 now too.

There are times when you want to track the bleeding edge of a particular project, and having a new laptop is often one of those moments... I've recently bought an HP Compaq nx6320 and while most of it is working, one of the reasons I got it was because of Keith Packard's work on the RandR extensions for X. Well, I was definitely seeing this bug but with a small patch I can get the latest (experimental) packages for xserver-xorg-video-intel to work, and now with a few magic tweaks to my xorg.conf I can make my desktop expand to another monitor when I unsuspend at work, and contract back to just the laptop screen when I resume somewhere else. The Magic Expanding X Config First of all, when I got the driver to actually work, xrandr explained to me that my maximum resolution was 1400x1400:

Screen 0: minimum 320 x 200, current 1400 x 1050, maximum 1400 x 1400
VGA disconnected (normal left inverted right)
LVDS connected 1400x1050+0+0 (normal left inverted right) 305mm x 228mm
   1400x1050      60.0*+
   1280x800       60.0  
   1280x768       60.0  
   1024x768       60.0  
   800x600        60.3  
   640x480        59.9  
TV disconnected (normal left inverted right)

Using a few clues from Ross Burton I managed to get that "maximum 1400x1400" to increase. The trick is to add a "Virtual" setting for screen size into your "Screen" Section, like so:

Section "Screen"
        Identifier      "Default Screen"
        Device          "Intel 945GM/GMS/940GML"
        Monitor         "Laptop Panel"
        DefaultDepth    24
        SubSection "Display"
                Depth           24
                Virtual         2680 1050
        EndSubSection
EndSection

The downside of this is that if you set the width greater than 2048 (as I have here) then DRI won't work, so you won't get 3d stuff. I guess I can manage without ice-cream, just so long as I get my cake! Once I have the "Virtual" setting, when I resume at the office I can:

xrandr --output VGA --mode 1280x1024 --pos 1400x0

And then when I resume somewhere without the external monitor, I can:

xrandr --output VGA --off

Quibbles All of these features are kind of under development, but Xorg 7.3 will support this stuff, and then Gnome and suchlike will have to start thinking about how to deal with it. The dynamic screen changing is not something these environments are completely ready for. One example is that while I know that monitor is always on the RHS of my docking station, X wants it to be the primary monitor and Gnome moves both panels onto that screen. Perhaps that's not a choice that can be made automatically. Someone who had an external keyboard plugged into their docking station might want the opposite behaviour, and there is certainly no way the environment can magically know whether that monitor is left or right of my laptop screen. Eventually I expect that Gnome will recognise this monitor, and will make the panels and location automatically set the RandR environment to match the way I set it last time. It is also somewhat annoying that I have to actually choose the virtual size. No doubt this configuration will disappear in due course and it is not really surprising to see it for something which is admittedly quite bleeding edge! I noticed at LCA that Keith had his own screen set for a Virtual size of 2048x2048, and now I know why: that's the maximum size that is supported for DRI, so if I expand my desktop onto a 1280x1024 screen I'm going to have some overlap. In fact I could almost configure my external monitor to be above my normal screen and use it that way, but it would feel pretty weird I think. In the meantime I've gone back to "blank screen" for my screen saver which admittedly is currently the only application for 3d acceleration on my desktop. Remaining Problems with this Laptop The only outstanding issues for me with this laptop are:

• Suspend/Resume to RAM does not work (I use suspend to disk)
• Fingerprint Sensor does not work (AuthenTec say Linux support will be available later this year)

That's about the best Linux compatibility I have had for any of my last five laptops within a month of buying it. Most of them have had much more significant stuff less supported even after three years of use!

From today my blog is available on IPv6. I've set it up so that http://debiana.org/ is only serving an AAAA record (for this server) and no IPv4 records (+/- DNS timeouts, of course...). Tomorrow I will work on getting a nameserver or two running on IPv6, to extend the IPv6 infrastructure another level. This is all me fiddling now that we have an IPv6 allocation at Catalyst, and are developing our IPv6 infrastructure in order to be able to deploy a couple of the .nz nameservers on IPv6 in due course. I'm not sure if I can point a .org domain at IPv6 nameservers so I might have to pick one of my .nz domains and use that to have a top to bottom IPv6 infrastructure. For IPv6 to start to work, I think people just have to start using it, so I'm going to change the systems that I can change. So I've also put a fixed IPv6 address onto my laptop, which is nice, and I will be converting all of my home systems to IPv6 addresses as well as time permits. Of course I can't get rid of IPv4 yet, but I think I will probably be trying to run that through a proxy somewhere non-local if I possibly can. If you can access this server via IPv6 I would be really interested to see a traceroute from you :-)

There was an interesting read the other week on LKML where someone or other was trying to say that no kernel config options should be hidden, and any that are should be turned into options that are linked, so that you can "see what you are doing". At the time Linus posted an excellent rant straight back, saying that more options should be hidden, and that the knobs and twiddles that people see should be obvious. I thought at the time that Linus response on this was extremely appropriate, but I didn't expect to be bitten by the opposite approach quite so immediately! I have been trying to build 2.6.20 for the last few days and wondering where in hell has the "Software Suspend" option gone. Well, today I found out that if you disable "Hot Pluggable CPUs" the option will never appear. If Linus has his way this problem would not happen, because the two knobs that people might want to twiddle, which appear superficially unrelated would actually have three settings in truth:

• CONFIG_USER_HOTPLUG_CPU
• CONFIG_HOTPLUG_CPU
• CONFIG_SOFTWARE_SUSPEND

The first setting would be a user-selectable knob, which would ensure that CONFIG_HOTPLUG_CPU was enabled, regardless of the state of software suspend. The last one would ensure that CONFIG_HOTPLUG_CPU and CONFIG_SOFTWARE_SUSPEND were enabled. The current approach is that iff I enable software suspend, then the hotplug CPU option disappears, and OTOH if I disable hotplug CPUs the software suspend option disappears. What I did was to start with a clean, unconfigured 2.6.20 kernel and go through all of the options starting at the top, which is something I tend to do with new hardware. The idea of hot plug CPUs seemed like something I didn't need, so I disabled it. With Linus' approach I would then have enabled Software Suspend a couple of minutes later, and the hidden config option would have been re-enabled behind the scenes. With the way things are at present, I built a good number of kernels and went through quite a bit of hardware blaming before I grepped .Kconfig for SUSPEND and found out what had happened, and which option I needed to enable. It is nice to know that their is such deep sanity at the heart of the kernel development process! Hopefully someone in a position to do so will notice this particular little gotcha and fix it soon, or perhaps someone wanting an "in" to start kernel hacking could go through the kernel configuration and clean up such gotchas. It certainly seems to me that Linus would accept patches for this as being rational.