I've started using the phrase "tragedy of targets" recently for those situations where someone does something stupid to meet an ill-specified target, instead of working towards the result in the way the target-setter expected. This gem was published by a Conservatives candidate over in my home county of Northamptonshire and was mentioned in today's Weston and Worle News

"an offender visited approximately 550 domestic properties in Weston-super-Mare with a fake comic relief sponsor form. This person obtained property by deception, (i.e. convinced them to part with money) from no less than 542 separate victims. Following good work from the police, he was caught, arrested, interviewed and I understand he will be cautioned for all the offences. My sources tell me that as a result of the arrest, the North Somerset District was or is planning to claim 542 'detections' for this one job. This will prove to be an amazing result for the bean-counters and has no doubt salvaged the whole 'performance target' result for the area in 2006. Indeed, the local Police Community Support Officers have spent the week going door to door in an attempt to locate every household that was conned, and get them to sign a pro-forma statement of complaint to bolster the clear-up rate"

Do you know other examples where setting a target has had unintended effects? Do you have a suggestion how to set better targets for the police here? Me, I like the suggestion of one anonymous commenter:

"The Police should be measured on the absence of crime not by detecting it."

Debian is this year again part of Google's Summer of Code. Last week, the final decisions about the proposed projects were made and Google granted 9 slots in total for Debian. I am very glad to say that Chris 'lamby' Lambs proposal for Debian Live is amongst those. Here is the abstract from his proposal:

	Live-helper is a utility to build CD, DVD, netboot and USB-stick live
	images of Debian, a GNU/Linux operating system. It boasts support for
	multiple architectures, auto-building images, amongst many other
	features.
	Live-helper is extremely flexible, allowing interested parties to create
	their own system completely specific to their needs, including support
	for custom package lists, kernel parameters, encryption, additional
	commands to configure the live system etc.
	My proposal is to construct a graphical user interface that can be used
	in conjunction with live-helper to build Debian Live systems, allowing
	editing of existing configurations and including a 'wizard'-style
	walkthrough for the first-time user.
	Providing less experienced users with the opportunity to easily create
	live distributions will generate more exposure for live-helper,
	providing more valuable feedback for its developers and ultimately
	helping Debian's image as an extremely flexible and free operating
	system.
	The GUI will be written in Python using the pygtk GTK+ bindings.

The next step on the timeline begins at May 28th, where the students start coding on their projects. I am happily looking forward to it.

Two semi-related things. Firstly, I just got notice that North Somerset Council are going to let North Somerset Housing pointlessly tarmac over a square of grass near us. Planning application 07/P/0464/F claims to provide 3 additional car parking spaces, but it tarmacs 7m width of grass while marking 6m width of current tarmac as no-parking: a net addition of 1m! Not enough for even one additional car! Now they've made this officially-acceptable reasoning, I reckon it will feature in a planning application for building more houses on the village's green spaces. How about: you can build a new house as long as you mark an existing house as uninhabitable? Secondly, Clevedon residents are petitioning the Prime Minister to stop Tesco expansion as reported in the Mercury. Expanding the Tescopoly in Clevedon will harm what already looks to me like an endangered town centre. OK, it's not the PM's responsibility to stop one store expanding in one town, but it is his government's planning policies which are aiding and abetting the continued growth of unsustainable 'big box' stores. I can see Clevedon from my office window. I'd need binoculars to spot Morrisons, but I think Tesco is visible with the naked eye already from the top of Worlebury hill. Every Little Hurts but they just keep on rolling like Renard, not noticing the pain.

I was informed that there's an Etch release party in Leuven, tonight. I've added it to the wiki; if you can still make it, you're welcome to join us. I'll be there, as will (hopefully) a number of other Belgian debian people.

Update: Francies commented:

"I also emailed Barclays regarding their non-listing of Linux and had the "128-bit encryption" where again Linux was not mentioned (have they even heard of it? A friend mentioned today that he has read that Barclays will be issuing chip and pin or card devices to all online banking users so could it be that these will be Windows only? If so the Linux community should complain in case all banks get the same idea."

I've also seen Barclays announce the chip-and-pin readers and a BBC report about them. Anyone seen these before? Comment form at the end of the page.

There are a lot of pages out there explaining how to convert your mail from mbox to maildir. I’m going to add one more, resurrecting the “tips” section of my blog. (All the tips from my blosxom days are grouped together on one page — someday I’ll get around to breaking those up properly.) If nothing else, I’ll never have to write these instructions in an email to someone again, instead I’ll just send them the link to this entry. I hope these steps are specific enough so anyone savvy enough to even have this problem in the first place will be able to follow them. One thing I find consistently concerns people when converting to maildir is how to make sure no mail is lost in the transition. The steps below address that concern. It’s really not hard at all once you understand how maildir works. First, I’m assuming you have mb2md installed and procmail support. Also, if you plan to access your mail through IMAP, your IMAP server needs to know to use ~/Maildir if ~/Mail does not exist. This is often default behavior (at least it is for Dovecot). Finally, I assume that your inbox is in /var/mail/username, and your other mail folders are in ~/mail. So, here goes:

1. Edit your .procmailrc. The first two lines should read:
   MAILDIR=$HOME/Maildir
DEFAULT=$MAILDIR/
   This will cause all new mail to be delivered (after you save your .procmailrc) to be stored in maildir format under ~/Maildir. The key for procmail to know to use the maildir format is the trailing slash in the “DEFAULT” line. Note that under the new system, your inbox and all your folders are kept in ~/Maildir, rather than having an inbox in /var/mail and your folders under your home directory. (This is nice because it makes it easier to back up all your mail together, among other things).
2. If you have any specific procmail rules in your .procmailrc, you’ll also need to change the target folders for that. For example, if you have a spam filtering rule like this:
   :0 H
* ^X-Spam-Level: *****
spam
It needs to be changed to this:
   
:0 H
* ^X-Spam-Level: *****
.spam/
   The trailing slash, again, tells procmail to use maildir rather mbox format for delivery. The leading dot will make the folder appear properly for your IMAP client (there’s a trick I suggest below for making “dot” folders easy to access with a command line client like mutt).

If you have mail being delivered to a nested mail folder, an additional change is needed because maildir has a flat hierarchy. So if your mail was being delivered to “misc/other/spam” the new target should be “.misc.other.spam/”.

Save your .procmailrc. From this point forward, all mail will be delivered to your maildir folders. You can now import all your old mail to the new folders without concern. Since maildir stores each individual message as a separate unique file, you don’t need to worry about any overwriting issues while you are making the transition. New mail will be delivered to newly named files; old mail will be imported to other, unique, newly named files.

Import your mail folders:
mb2md -s ~/mail -R
The -R just means to import recursively through all your folders; if your mail folder is Mail rather than mail, use that instead. No destination is needed because mb2md uses ~/Maildir by default.

Import your inbox:
mb2md -m

Move your old inbox out of the way. Most people won’t actually be able to move or delete files in /var/mail (since they don’t have directory write privileges), so the easiest thing is probably to just open the inbox in your IMAP client or with mutt and save or delete all the messages.

Move your old mail folder out of the way:mv ~/mail ,.bak Once you’ve confirmed that everything is okay, you should be able to delete ~/mail.bak (or compress it and move it elsewhere.) If you saved your inbox to mail folder in step 6, that will get moved out of the way here as well.

That’s it, you’re done.

Okay, so you’re not quite done if you access your mail with mutt rather than an IMAP client. (You could just point your mutt at your local IMAP server, of course). I’ve found the most convenient way to access the “dot” folders with mutt is to create a parallel symlinked folder structure without the dots. Here’s a hacked-together shell script that will do that. This could obviously be rewritten to be much more elegant (probably in perl). But we all have our messy scripts, right?

#!/bin/bash

cd ~/Maildir for x in .*
do
y=$ x##.
if ( echo $y grep -q ‘.’ )
then
mkdir -p ~/mymail/$ y%.*
fi
ln -s ~/Maildir/$x ~/mymail/ echo $y sed “s/.///g”
done for x in *
do
ln -s ~/Maildir/$x ~/mymail
done
Then, just add these lines to your .muttrc file:
set folder="~/mymail"
set spoolfile=”~/mymail” Any questions?

With the Debian 4.0 (etch) release parties out of the way, it's time to devote a little energy to celebrating the forthcoming release of Ubuntu 7.04 (Feisty Fawn). A few of us from the nascent Massachusetts Loco Team in the Boston/Cambridge area have planned a release party -- a Feisty Fiesta if you will -- for Saturday April 21, 2007 19:30 at the Cambridge Brewing Company. For more details, answers to your questions, or to RSVP for the party so we can reserve a big enough table, please visit the party wiki page.

A comment on my post about the failure probability of clusters suggested that a six node cluster that has one node fail should become a five node cluster.

The problem with this is what to do when nodes recover from a failure. For example if a six node cluster had a node fail and became a five node cluster, then became a three node cluster after another two nodes had failed, then you would have half the cluster that was disconnected. If the three nodes that appeared to have failed became active again but unable to see the other three nodes then you would have a split-brain situation.

As noted in the comment the special case of a two node cluster does have different failure situations. If the connection between nodes goes down and the router can still be pinged then you can have a split brain situation. To avoid this you will generally have a direct connection between the two nodes (either a null-modem cable or a crossover Ethernet cable), such cables are more reliable than networking which involves a switch or hub. Also the network interface which involves the router in question will ideally also be used as a method of maintaining cluster status - it seems unlikely that two nodes will both be able to ping the router but be unable to send data to each other.

For best reliability you need to use multiple network interfaces between cluster nodes. One way of doing this is to have a pair of Ethernet ports bonded for providing the service (connected to two switches and pinging a router to determine which switch is best to use). The Heartbeat software supports encrypted data so it should be safe to run it on the same interface as used for providing the service (of course if you provide a service to the public Internet then you want a firewall to prevent machines on the net from trying to attack it).

Heartbeat also supports using multiple interfaces for maintaining the cluster data, so you can have one network dedicated to cluster operations and the network that is used for providing the service can be a backup network for cluster data. The pingd service allows Heartbeat to place services on nodes that have good connectivity to the net. So you could have multiple nodes that each have one Ethernet port for providing the service and one port as a backup for Heartbeat operations, if pingd indicates that the service port was not functioning correctly then the services would be moved to other nodes.

If you want to avoid having private Heartbeat data going over the service interface then in the two-node case you need a minimum of two Ethernet ports for Heartbeat and one port for providing the service if you use pingd. If you don't use pingd then you need two bonded ports for providing the service and two ports (either bonded or independently configured in Hertbeat) for Heartbeat giving a total of four ports.

When there are more than two nodes in the cluster the criteria for cluster membership is that a majority of nodes are connected. This makes split-brain impossible and reduces the need to have reliable Ethernet interfaces. A cluster with three or more nodes could have a single service port and a single private port for Heartbeat, or if you trust the service interface you could do it all on one Ethernet port.

In summary, three nodes is better than two, but requires more hardware. Five nodes is better than three, but as I wrote in my previous post four nodes is not much good. I recommend against any even number of nodes other than two for the same reason.

Aside from Paul Graham's list of reasons not to do a startup on your own (http://www.paulgraham.com/startupmistakes.html), there's another very simple one: pronouns. It's much, much nicer to be able to write "we" on a corporate web site. "We" could be anything from 2 to IBM's zillions, but it implies a real organization, whereas "I" implies some guy off working on his own. Of course, you could lie and write "we", but that will probably catch up with you at an inopportune moment.

5 star hotel tips There are things you don't think about until you spend 2 weeks in a 5 star hotel. In 5 star hotels you have a minibar that you're not supposed to open unless you want to be charged something stupid like 10 euros for 25cl of still water claiming to have been bottled in the opposite side of the world from where the hotel is located. But on top of the minibar there are glasses you can use for drinking, and an ice bucket you can refill in the corridor. This allows you to put ice in tap water. If the tap water is undrinkable, buy a 3l water bottle in the nearby supermarket and use the ice to make it colder without upsetting the minibar. Note: this specific minibar has sensors, and charges you the very moment you take things away from the fridge, so it's out of the question to temporarily empty it to put my things in for a while. Now, the ice bucket, the ice clips in the ice bucket and the glasses used for drinking, how do they clean them? Are they sent 6 floors downstairs to the dishwasher? Certainly not. They use the DETERGENT FOR THE WINDOWS. I went to get some ice and realised that the inside of the bucket (and the ice clip to put the ice in your cocktails) smelled like window detergent. Then I sniffed around: same did the glasses, and one had leftover foam in the bottom. So I had to wash the toxic stuff away from them before using them. Now I can assume that I have to wash the glasses every time I need them, as I know that they are not necessarily cleaned with food-safe detergents. So, here's the tip: before leaving the room in the morning, I put glasses and ice bucket back on the tray on top of the fridge, and I put the cheap-pretending-to-be-fancy cocktail mixing plastic sticks back in the glasses. This succeeded in tricking the cleaning people into believing that I didn't use them. As a consequence they didn't clean them, and now I can use them without needing to wash the window detergent away first. Another tip: don't leave your shoes next to the sofa, or the cleaning staff will put them on the sofa when cleaning (sometimes they forget them on the sofa, so you realise). Even better: don't put them next to the bed. Another tip: if the breakfast buffet has only scary things it takes half a day to digest, make friend with the omelette cook.

Who are the next generation of Debianists? Are they all still coming to us out of different OS backgrounds, or do we now have the significant beginnings of a home grown generation, born and raised in Debian-using families and now making their voices heard? I hope that Debian Jr. will encourage this kind of generational growth of the project. When recently I rewrote the guiding principles of Debian Jr., my vision was a Debian that children would identify as their own. I expect they will be eager to add their own ideas as they grow up with it. It was pointed out to me today that there is some evidence that this is already happening (thanks for the link, Matthew Wilcox). As for my own kids, ages 16, 15, 12, 9 and 5, only the oldest have ever used some system at home other than Debian¹. They all comfortably use our Debian systems daily, discussing regularly with me what they need. This leads to filing bugs and patches on their behalf², and inspires further development of the Debian Jr. project. So, in at least this sense, the children of Debian are already contributing members of Debian, if not voting members. The ideas of families are improving Debian for everyone. As the project grows, I expect the ways in which families will change Debian will be more significant, not only technically but also in Debian’s character.

¹ Before we started using Debian in 1995, the family system was a VT-420 terminal connected to the Solaris system running our community freenet. At that time our kids would sit in my lap and play at typing into pico for their amusement.

² For instance, I was pleased to discover the other day that my egoboo patch was accepted. That was a direct result of my kids asking me to make it work for them.

When migrating tags from Bazaar to Subversion, I generated lots of commits. When I did that, I didn't realise, that CIA will count all my tagging as commit and I will become most active author and Wammu will read 6th position among most active projects. Anyway this has just happened and maybe it will advertise Wammu a bit. But don't expect that I or my projects will reappear there in near future ;-).

A complete set of Debian 4.0 on CD and DVD consists of 292 CDs and 39 DVDs. If you've downloaded or bought all 331 discs, here's how you can throw 324 of them away. Or, how to pick the right ones to get in the first place. First, the one disc that is all you really need for Debian 4.0: The multi-arch DVD! This is the neatest disc available for etch, it can boot on x86 systems, both 32 bit (i386) and 64 bit (amd64), as well as on powerpcs. It will detect the architecture and automatically boot the right one. It contains enough software to install a nice desktop using only the DVD, no network needed. And it includes the source code to all that software on the same DVD. This DVD is perfect for giving out at conferences, or to friends, or for that desert island scenario, and it's really the only Debian disc you need. If you want a second Debian disc, I recommend the netinst CD. This disc is under 200 megabytes in size and is designed to be written to a 3" mini-CD. Much easier to carry around than a full-size CD, so it's great for those Debian installs that you didn't expect. It's also a handy rescue disc (just boot with "rescue"). Four other CDs are of some interest, to round out your collection. The multi-arch CD has the same software as the netinst CD, but it's a full-size CD, that supports the same three architectures as the multi-arch DVD. The first CD from the CD set can install a Gnome desktop system without accessing the network and is a good general-purpose CD. The KDE CD and XFCE CD provide some choice in which desktop environment you install. Finally, one other CD merits mention. The businesscard CD is a tiny but full-featured Debian CD that can be written to a square or "hockey rink" shaped disc that is sized the same as a business card. This can be an eye-catching giveaway, if you can get the businesscard CDs produced in bulk on the cheap (if you do, please let me know). My experience with putting them in a wallet though is that they won't last more than a few weeks. If you want to have Debian installation/rescue media you can carry with you everywhere, you'll have better luck with an inexpensive bootable USB keychain. The other 324 discs are only of interest to archivists, completists, and those in certian oddball scenarios.

This recent massacre at Virginia Tech reminds me of Australia's Port Arthur massacre. That event was pivotal in reforming Australia's gun laws. I wonder what it will take for similar action in the United States? One would argue it's a bigger deal, because Australia doesn't have a constitutional right to being armed, so presumably it's a bigger deal to override/amend in the US. Still, at some point, something's got to change... This madness can't keep happening.

Ok, so it just seems like a hot topic - I just submitted a BoF for Debcamp to talk about the init-related ideas we've been discussing. As Debconf's Pentabarf conference management system does not like disclosing talk details before the talks are accepted, I'll reproduce here my short blurb:

This BoF comes out from several ideas posted in Planet Debian by Erich Schubert, Sven M ller, Joachim Breitner, Mike Homey and myself (so far). It's not to be "chaired" by any of us particularly, but I expect an interesting brainstorming session.
There are several different init systems present in Debian - However, we are only supporting currently one of them, good ol' sysv-rc - We have close to a thousand packages providing init scripts suitable for it, and close to none for all of the other systems.
In current systems, full of hot-pluggable devices, changing network configurations and so on, however, I think this situation is quite prone to change - sysv-rc and its runlevels are better suited for stable server-like systems, and is hard to adapt for future needs.
We will talk about the potential difficulties Debian will face in order to better support more init schemes, and discuss some ideas to solve them.
This should be a brainstorming session, not much material will be prepared (maybe some sketches by each of us, but nothing formal). If you plan on attending, take a look at the messages linked to in the 'links' section.

Note that, following Nomeata's suggestion, I'm presenting this for Debcamp - If you are not attending Debcamp and are interested, we will try to set this up via some sort of videoconferencing (or at least the usual video feed + IRC feedback), and I do hope we can have something showable (at least a broken concept) after Debconf.
In not-so-closely-related topics, I just learnt there is a shadow of doubt regarding my presence in Edinburgh - I will do my best to dispell the threat. I just don't want to miss a Debconf!

First of all, sorry for the delay. Leaving just as the discussion gets started is bad, yes... But I'm only now reading Erich's and Sven's follow-ups. Both (as well as some comments in my blog) ask why not integrating the startup links in each of the packages - Well, basically because I don't think that most maintainers will take care to do this, and we will end up having a situation very close to what we have today: If I'm not interested in supporting your favorite init system in my packages, I just won't bother to make the scripts.
Note: I'm going into braindump mode. Verbose blabber and some stupidity might follow ;-)
Think on the webapp scene - Most webapps ship with an Apache-like snippet so that http://yourserver/thisapp just works(tm). I love that, and it's one of the little details that make Debian shine - Things usually work with the least administrator burden possible. But it happens that there are other web servers around there - They just become somehow second class citizens (I happen to sponsor/comaintain Cherokee, for instance), as nobody cares to include the equivalent snippets for them. Apache is the standard, and is good enough.
The same goes for sysv-rc: It just rules the world. Who will work all the needed patches to support all the different init systems? As the maintainer for a simple package which requires to be started up, I probably won't care to even understand all the intimacies of every init system, at least until they all have a decent user base. But by having one package per (server,init-scheme) pair, any maintainer can come up with the needed initialization.
Of course, this degrades quickly. First of all, as a user: if mydaemon is not correctly starting up, I will probably file bugs at mydaemon, not at mydaemon-initscheme. If mydaemon changes its parameters, we will witness transition of mydaemon-*.
Further, remember this is Debian, and volunteer-work has its downsides. If the mydaemon maintainer is a primadonna (or just does not give a flying crap about the runit init scheme), he will just trash reports regarding a nonimportant init scheme. Bad. And, as Erich points out, we have ~1000 packages including /etc/init.d/something - It will mean 3000 or so packages for a decent (not complete!) coverage of the different schemes. And, of course, a very uncoordinated way of working. But back to my line of thought: If I'm promoting an init scheme, I cannot just push it down each maintainer's throat. I must include at least the most important init scripts somewhere. Maybe we could just group daemons by task, and then have -say- a webservers-runit package providing the init scripts for each webserver for runit? This could cut down from 3000 to some 100 packages, most probably team-maintained... But it still faces many scalability problems, and the bug-filled-somewhere-else problem seems unavoidable.
I think something interesting could come off Sven's idea of providing several independent scripts instead of today's complete init scripts - This would make it easier to adapt startup/shutdown and similar events to different world views, and if not specifically needed, most init scripts could even be autogenerated calling the right bits here and there. That would rock - except in the corner cases (I predict no less than 10% of the packages will become corner cases ;-) ) where it will crumble apart. But maybe if a package declares it should be autostarted and provides the separate bits, the sysv-rc, upstart or runit helper can come up with an autobuilt initscript (or equivalent) - And if it does not work, it can always be overriden by a maintainer- (or user-) supplied, explicitly built script. Humh...
The topic surely calls for a Debcamp session, as Joachim says in comments in two of our posts and Erich acknowledges. Erich, as the main instigator of this blog series, I hope you can at least join via Ekiga or such, as it can be quite interesting - But, yes, none of the people involved so far participates in any of the inits' maintenance... Anyway, please keep the ideas flowing. I want to sketch something up, as I feel this can be useful - and not only for initscripts, but for many of the areas where Debian provides several ways to do the same thing. And, once again, that's one of the best points of Debian for me.

I was delighted at finding Erich's series of posts regarding init schemes - In fact, when reading the bottom of your third message I got disappointing at you stating that this concludes this series of blog posts. Maybe someone can follow up with some details on upstart (which seems to be the most promising init replacement)? - I expected you to delve a bit into other schemes, such as file-rc (which is, AFAIK, quite similar to the standard sysv-rc, but instead of having directories with symlinks has files describing each runlevel in similar terms, and I understand works in quite a similar logic to sysv-rc), runit seems to work in a way quite similar to BSD's RC...
I was particularly interested on your point of view on something like Init NG - And, of course, Upstart sounds sexy, and besides, being Scott's brainchild automatically stamps a must be good legend on it, at least for me. Shame that you didn't follow on with the series - but hey, nobody's paying you to do it ;-)
Anyway... I was thinking on a way we could get at least Debian maintainers work more easily towards having more than one init scheme for our daemons and such - or at least, shipping less cruft for derived distributions to clean up. Specifically, yes, our most notorious descendant goes Upstart, so /etc/init.d/* becomes crufty for them. So, what if:

• All daemon-like packages (i.e. those containing a daemon, or running something at startup, i.e. setting up a service interface) will be affected. Lets call our sample daemon-bearing package example
• example will no longer ship an initscript. In fact, after some time, policy will mandate no initscripts (that is, what we today put in /etc/init.d) are included in our base packages. example will only recommend example-init. Why recommend it? Because it does not even now depend on a specific initscript - I've rolled some systems which are based on my very own init handler, for specific needs.
• The original example package maintainer will probably take his very same initscript, and package it as example-sysvinit. This script will provide the example-init virtual package. (Of course, this will mean a very real proliferation of virtual package names). example-sysvinit will depend on sysv-rc.
• The same maintainer, or a different one, will also package example-nginit, example-bsdinit, example-runitinit and/or example-upstartinit, depending on their respective infrastructures, and providing as well example-init. Ideally, they won't even have to conflict on each other.
• Maybe I'm daydreaming and this could just be a bit too much... But with all support in place, even the init system itself could be handled via /etc/alternatives ;-)

This means, yes, a serious explosion of very small packages. But it also means less dependency on a specific maintainer to be sympathetic to yet-another-init-scheme. If I'm pushing superb-init, which does preemptive reverse dependency tracking and invention and works based on the oh-so-3v1l aptsh, and I'm having a hard time convincing anybody to update their packages to support my init scheme before it matures, I can at least come up with all the needed scripts to get my system usable and considerable for the masses. Sounds decent? Did I smoke too much crack? No, I haven't had my morning coffee yet, so I'll go grab some while this hits the planet.

I just added my blog to http://planet.debian.org, hopefully my posts will not annoy anybody :-). Don't expect much personal things from me, most of blogging is about Gammu and Wammu.

OCaml 3.10.0 Beta in Experimental As per title. It isn't actually fully functional: Julien for example just noticed that ocamlc -version returns "3.10.0+beta" while the libdir is (correctly) /usr/lib/ocaml/3.10.0/, this means that practically all packages using the ocaml CDBS class can't be built properly against it. Still you can give it a try (if you love risk) and perhaps document yourselves on the new API of camlp4, which changed completely. For us it will be useful to see the result of experimental autobuilding ... I'm quite scared about that!

At work, we use Linux (and Debian, in specific) for a lot of different things: everything from our phone system (running on Asterisk) to file serving and running some proprietary applications. I'm one of the people that finds, sets up, and maintains these systems, and I write code for our in-house use as well. I like to learn from others, and get to know others that may have things in common with me and with our environment. So going to conferences is a useful thing to do.

I'm hoping that some reader out there will have a good suggestion for a conference I ought to attend. Here are some that I've looked into and my thoughts on them:

• Usenix Annual Tech Conference: I went last year. There were some very good talks, but the audience size was not all that large. I got to meet some peers there, but I didn't get to talk in-person to anybody I'd worked with online before. (LISA being in fall/winter means it's too early to consider it just yet)
• LinuxWorld Conference & Expo: My general impression of LWCE in the past has been that its technical talks aren't very technical; that is, they either cover things I already know or don't care about. They are starting to publish their program this year, and I see a few interesting things though. There have traditionally been a lot of Debian folks at the .org pavillion.
• Debconf: It seems to be focused almost exclusively on developing the Debian operating system, rather than on using it. While I am a Debian developer and have been for quite awhile, I would find new uses of Debian to be more interesting than new ways to hack on Debian. Plus, the insanely early registration requirements means that it's too late to go this year anyhow. (And my brother is getting married right in the middle of it.)
• OSCon: There look to be some interesting talks in the database area, and some about Xen and virtualization, and Simon PJ (one of the ghc hackers) will be there. So this would be interesting, though somewhat light on the admin side of things.
• OLS: Seems very focused on the kernel, and not much else. That is of interest, of course, but is one piece of many. Though there was a talk about Linux deployment at Nortel that sounded interesting.

My leading candidates are probably Usenix and OSCon. I'm interested to hear what people think, especially those that have attended some of these conferences.