A truckload of compost was dropped off today. Went out this evening to put together a raised bed for it, and when I looked up, I saw a wonderful surprise. I've been trying to catch this groundhog for ages. It's still fat from last year's garden and the whole other contents of the yard, and also, I think, pea shoots that came up recently. But it would not set foot in the trap for any bait, and I had given up (again) and planned to put the trap away this evening. I came out at just the right instant, to confuse the beast, already stressed by the appearance of big piles of dirt, to dodging for the wrong hiding place. It's now enjoying its new home out at the lake, and I'm looking forward to enjoying vegetables.

The Claim I have seen it claimed that renting a virtual server can be cheaper than paying for electricity on a server you own. So I m going to analyse this with electricity costs from Melbourne, Australia and the costs of running virtual servers in the US and Europe as these are the options available to me. The Costs According to my last bill I m paying 18.25 cents per kWh that s a domestic rate for electricity use and businesses pay different rates. For this post I m interested in SOHO and hobbyist use so business rates aren t relevant. I ll assume that a year has 365.25 days as I really doubt that people will change their server arrangements to save some money on a leap year. A device that draws 1W of power if left on for 365.25 days will take 365.25*24/1000 = 8.766kWh which will cost 8.766*0.1825 = $1.5997950. I ll round that off to $1.60 per Watt-year. I ve documented the power use of some systems that I own [1]. I ll use the idle power use because most small servers spend so much time idling that the time that they spend doing something useful doesn t affect the average power use. I think it s safe to assume that someone who really wants to save money on a small server isn t going to buy a new system so I ll look at the older and cheaper systems. The lowest power use there is a Cobalt Qube, a 450MHz AMD K6 is really small, but at 20W when idling means a cost of only $32 per annum. My Thinkpad T41p is a powerful little system, a 1.7GHz Pentium-M with 1.5G of RAM, a 100G IDE disk and a Gig-E port should be quite useful as a server which now that the screen is broken is a good use for it. That Thinkpad drew 23W at idle with the screen on last time I tested it which means an annual cost of $36.80 or something a little less if I leave the screen turned off. A 1.8GHz Celeron with 3 IDE disks drew 58W when idling (but with the disks still spinning), let s assume for the sake of discussion that a well configured system of that era would take 60W on average and cost $96 per annum. So my cost for electricity would vary from as little as $36.80 to as much as $96 per year depending on the specs of the system I choose. That s not considering the possibility of doing something crazy like ripping the IDE disk out of an old Thinkpad and using some spare USB flash devices for storage I ve been given enough USB flash devices to run a RAID array if I was really enthusiastic. For virtual server hosting the cheapest I could find was Xen Europe charges E5 for a virtual server with 128M of RAM, 10G of storage and 1TB of data transfer [2], that is $AU7.38. The next best was Quantact who charges $US15 for a virtual server with 256M of RAM [3], that is $AU16.41. Really for my own use if I was paying I might choose Linode [4] or Slicehost [5], they both charge $US20 ($AU21.89) for their cheapest virtual server which has 360M or 256M of RAM respectively. I ve done a lot of things with Linode and Slicehost and had some good experiences, Xen Europe got some good reviews last time I checked but I haven t used them. The Conclusion When comparing a Xen Europe virtual server at $88.56 per annum it might be slightly cheaper than running my old Celeron system but would be more expensive than buying electricity for my old Thinkpad. If I needed more than 128M of RAM (which seems likely) then the next cheapest option is a 256M XenEurope server for $14.76 per month which is $177.12 per annum which makes my old computers look very appealing. If I needed more than a Gig of RAM then my old Thinkpad would be a clear winner, also if I needed good disk IO capacity (something that always seems poor in virtual servers) then a local server would win. Virtual servers win when serious data transfer is needed. Even if you aren t based in a country like Australia where data transfer quotas are small (see my previous post about why Internet access in Australia sucks [6]) you will probably find that any home Internet connection you can reasonably afford doesn t allow the fast transfer of large quantities of data that you would desire from a server. So I conclude that apart from strange and unusual corner cases it is cheaper in terms of ongoing expenses to run a small server in your own home than to rent a virtual server. If you have to purchase a system to run as a server (let s say $200 for something cheap) and assume hardware depreciation expenses (maybe another $200 every two years) then you might be able to save money. But this also seems like a corner case as the vast majority of people who have the skills to run such servers also have plenty of old hardware, they replace their main desktop systems periodically and often receive gifts of old hardware. One final fact that is worth considering is that if your time has a monetary value and if you aren t going to learn anything useful by running your own local server then using a managed virtual server such as those provided by Linode (who have a really good management console) then you will probably save enough time to make it worth the expense.

• [1] http://doc.coker.com.au/environment/computer-power-use/
• [2] http://www.xeneurope.co.uk/packages
• [3] https://www.quantact.com/signup.cgi
• [4] http://www.linode.com/
• [5] https://manage.slicehost.com/customers/new
• [6] http://etbe.coker.com.au/2010/01/18/why-internet-access-in-australia-sucks/

Fourteen months after the renaming of the Free/Open Source code of GForge 4.x to the new FusionForge name, we're pleased to announce version 5.0. As mentioned in the release notes, this is still an incremental step over version 4.8 rather than a revolution, but the changes are important enough, and numerous enough, that we felt it justified to bump the major version number. Major improvements, beyond a host of bugfixes, include:

• a rewrite of the version control integration (with support for Bazaar, Darcs, Git and Mercurial in addition to the traditional CVS and Subversion);
• a much better integration of Mediawiki (one wiki, with its own set of permissions, per project);
• a cleaner database layer, more robust against SQL injections;
• configurable display for the trackers;
• more powerful tracker engine, with configurable workflows;
• a rework of the default theme, with better accessibility.

FusionForge 5.0 now also includes new plugins that were previously only floating around (or completely private):

• projectlabels gives a simple way of adding bits of HTML onto project description pages, so the forge admin can, for instance, highlight a project of the month ;
• extratabs allows a project to define new tabs in its pages, pointing at external resources;
• globalsearch is a first step in the federation of forges concept, whereby a project search can be conducted on several forges at once;
• contribtracker allows a forge to prominently display major contributors to projects, to give them visibility beyond the simple commit logs.

These plugins, as well as a large part of the improvements in the trackers and the rewritten Mediawiki plugin, are a direct consequence of the upstreaming of work having been done in private instances of forges. We're happy to note that this goal of ours (to merge local patches into the central repository when it makes sense) seems to be working well. For the record, this 5.0 release includes work and plugins that were reintegrated from sources such as Alcatel-Lucent, Adullact and AdaCore. This release is also the first to have had the benefit of automated testing during the whole cycle. Coverage isn't 100 % yet, but the existing unit tests and functional tests help us be confident in the quality of the release. We'll keep adding more tests as time passes, of course. Looking back at the initial goals stated when the project started, we seem to be on the right track:

• stable release pushed out: check (this is the third one, not counting minor releases);
• new plugins merged: check;
• automated testing: check;
• external contributions merged: check;
• explicit governance model and release process: sort-of (there's still a cabal, but it's partially documented).

We still need to work on the database schema and the cross-distro part, as well as cross-forge interoperability. The good news is that work is happening on these fronts already. And with almost 2500 commits, we truly seem to have accomplished at least one of the (implicit) goals: to bring development back to a healthy state. And we're far from being out of ideas for the future, so there's a lot of good stuff still cooking!

I ve been eagerly looking forward to the release of Xero Personal which has been heavily promoted by Xero and BNZ (as MoneyMap) for the last few months. Unfortunately my first impressions of the product today are extremely underwhelming. Xero Personal is definitely not worth anywhere close to $5/month for me at this point in time and I m unlikely to even keep using the free trial. To set the context for that statement, Xero Business set the bar high. I first used the original version of Xero while it was still in beta and even then it was clear that it was an application that took accounting to a new level and would provide an order of magnitude improvement in how I maintained the accounts for our business. That promise held true once we started paying for it, even though the cost of Xero is more than 10% of our annual expenses, the time and hassle it saves makes it a worthwhile investment. By contrast today s release of Xero Personal offers nothing new above existing personal finance websites or desktop packages and would take me extra time to use as it fails to handle many of the basic transactions that a normal household will encounter. The way Xero Personal works is by having you manually upload your bank statements (the automatic import functionality that is so useful in the business version of Xero has been restricted to BNZ MoneyMap customers only). For each transaction you are asked to provide two pieces of information. The first is a category which serves as a basic form of account to track expenses and income. For each category you can set a spending or saving goal which Xero will help you track progress towards. The second is a name to identify the other party in the transaction. Xero Personal comes pre-loaded with some fairly generic categories. Annoyingly you re restricted to no more than 8 additional custom categories and the names associated with each transaction are are simple strings you can t link a transaction to another account or entity. To represent a transfer you need two separate transactions, one in each account, which you assign to the special category Transfer so that Xero knows to essentially ignore it. Nothing links the transactions together or ensures that the values balance. In addition to the basic categorisation functionality the application also attempts to track your assets and liabilities (bank accounts and credit cards show up automatically) so that it can compute your net worth. Unfortunately as soon as you try and use this you hit the problem that there is no way to link transactions from your accounts back to your assets and liabilities. This means unless you regularly and manually update your assets and liabilities the net worth calculation only takes into account changes in your cash position and becomes blatantly incorrect. As an example, take the common case of a household with a weekly mortgage (or other loan) repayment. You want the weekly payment to decrease the balance of your current account, increase the balance of your interest expense category and decrease the value of your mortgage liability. Your net worth should decrease by the value of the interest expense only, as the decrease in the value your mortgage liability offsets the remainder of the decrease in the value of your current account. Xero Personal doesn t come close to being able to handle this example today. The ability to split payments to different categories has also been left out (even though it s present in Xero Business and therefore presumably in the underlying engine) so your only option is to categorise the entire payment as a mortgage or housing expense, decreasing your net worth by the full value of the payment. Even if you could split the payment between two categories, one for the interest and one for the principal the inability to link the category for the principal to the liability account means the net worth calculation will still be incorrect. Maybe I m being to hard on this newly released product? It is a SaaS application after all and Xero has an excellent history of releasing regular updates to the business version of Xero. The reason I m so surprised and disappointed by this initial release is that it essentially lacks any double-entry accounting support many of the missing features are core functionality that is already implemented in the accounting platform that supports the business version. Assuming that Xero Personal is built on the same platform (and that would be the obvious choice wouldn t it?) the fact that Xero Personal has been released and is being heavily promoted without these features (compared to the initial version of Xero Business which was fully functional and obviously awesome even in beta) suggests to me that it s a conscious decision to significantly limit the scope and usefulness of the application rather than simply a limit on what could be implemented before the initial release. I sincerely hope that I m wrong and that the coming months bring significant improvements to the functionality of Xero Personal, but until it can support common transactions like mortgage repayments correctly I won t be using it or recommending it to anyone.

Hector Oron:

Secondly, I was wondering how Debian could make it easier for people to contribute than other (derivatives and non-derivatives) distributions. I came up with a really nice draft howto[1] which I would like to bring up to your attention, so the basic question would be what do you think you could do to make contributions paths easier (take in account not all teams, groups follow such community guidelines)

Human beings are not computers, so I find that applying HOWTOs to them to be misguided at best. As for enforcing a set of arbitrary community guidelines, I would not do that. Frank Lin PIAT:

planet.d.o has became one of the most visible media for Debian, if not the most visible one. Do you think it is a good thing?

I consider it neutral. If people start thinking of blogs or microblogging as important though, I think we might have a problem. I am in favor of our informal policy to never post anything important on blogs unless it is merely a copy of something communicated properly on an official channel. This includes anything that would go into our packages. Consequently I do not think it a valuable goal to respect copyright law by enforcing DFSG-free licenses on blogs, whether they are aggregated or not. Kumar Appaiah:

One of the questions which I've not yet seen exactly in the discussions is on the transparency in the maintenance of non-core but "important" packages, such as python, wherein the maintenance of the package and policy (till a short while ago) has been, poor at best, and we've had near zero communication from the maintainer(s) for over a year. This has led some parts of the "community" (Debian Python, in this case) to knock the doors of the tech-ctte[1] (recommended reading, unless you have done so already).

I think that is a failure of the entire community that the situation has even come to this point. In other analogous situations, the package would have been hijacked by now and the situation resolved. I think it would be appropriate for the DPL either to step in and mediate situations like this before they get anywhere near the tech-ctte, or to delegate someone to do the same. I think it would be equally appropriate for the people involved to resolve this themselves. Of course all of this should be open.

I have been at Amazon.com for a very short while (I have only gotten one paycheck from them so far), but long enough for first impressions to have settled. Dress is casual, Parking is limited. Cafeteria food is merely OK, and is not free. There is a very flat structure at Amazon. The front line work is done by one-or-two pizza teams size measure by the number of large pizzas that can feed the team. Individual experiences with the company largely depend on what team you happen to end up with. I think I lucked out here. I get to work on interesting and challenging problems, at scales I had not experienced before. There is an ownership culture. Every one including developers get to own what they produce. You are responsible for our product down to carrying pagers in rotation with others on your team, so that there is someone on call in case your product has a bug. RC (or customer impacting) bugs result in a conference call being invoked within 10-15 minutes, and all kinds of people and departments being folded in until the issue is resolved. Unlike others, I find the operations burden refreshing (I come from working as a federal government contractor). On call pages are often opportunities to learn thing, and I like the investigation of the current burning issue du jour. I also like the fact that I get to be my own support staff for the most part, though I have not yet installed Debian anywhere here. While it seems corny, customer obsession is a concept that pervades the company. I find ti refreshing. The mantra that it s all about the customer experience is actually true and enforced. Whenever a tie needs to be broken on how something should work the answer to this question is usually sufficient to break it. Most other places the management was responsible for, and worried about budgets for the department this does not seem to be the case for lower to middle management here. We don t get infinite resources, but work is planned based on user experience, customer needs, and technical requirements, not following the drum beat of bean counters. The focus is on the job to be done, not the hours punched in. I can choose to work from home if I wish, modulo meetings (which one could dial in to, at a pinch). But then, I have a 5 mile, 12 minute commute. I have, to my surprise, started coming in to work at 7:30 in the morning (I used to rarely get out of bed before 9:30 before), and I plan on getting a bike and seeing if I can ride my bike to work this summer. All in all, I like it here.

RCBW - #25 Last (long) week has finally passed: first in Geneve visiting Gismo, then in Sierre/Crans-Montana to present a paper at SAC 2010, then back in Paris for half a day before a day in Bruxelles for the 2nd year Mancoosi project review. (And of course campaigning has always been going on ...) All went fine and I can finally relax a bit for a week-end back "home" (i.e. Paris). Regarding RCBW, it looks like that in the past 2 months I've stabilized around 3 issues per month, which makes me happy nevertheless. Without any further ado, here are this weekissue's squashes:

• Debian bug #570727 - xmldiff - fix tree comparison (on i386), patch by Daiki Ueno
• Debian bug #574640 - turbogears2 - ensure compatibility with new routes, patch by Piotr O arowski
• Debian bug #574083 - wwwoffle - add missing dep on net-tools, needed by init.d script
• Debian bug #555036 - bash-completion-lib - RM/RoQA/ROM (see Debian bug #575260)
• Debian bug #574228 - mediamate - request RM/RoQA (see Debian bug #575508)
• Debian bug #574025 - mathgl - switch to octave3.2 (bonus: QA upload w/ proper orphaning)
• Debian bug #482790 - elserv - fix emacs deps wrt current emacsen flavours (malus: fought with cdbs' DEB_AUTO_UPDATE_DEBIAN_CONTROL)

Random points:

• Up and downs in the "RCBW community": gregoa rock's (as usual) whereas Lucas is subverting the rules! (bad Lucas, bad).
• Some of the side comments by Gregor made me realize that I have probably chosen the wrong tagline/acronym for RCBW, as the point is not really keeping a sustained average (or feel bad about not keeping it), but rather doing that "constantly" in some available Debian time slots, as well as trying having others do the same.
• Clint has commented on BSPs also mentioning RCBW. (I mention en passant that I've never claimed RCBW to be innovative, as my kudos show; my memory is short though, I'll be happy to integrate the list with pointers to similar initiative more far in the past.) The idea of newbie/teaching-oriented BSPs is just wonderful, it only needs some motivated people to (continue) organizing them.

Diagnostic Changes for Autism Spectrum Disorders Currently Asperger Syndrome (AS) is one of a group of conditions that are grouped into the category Autism Spectrum Disorders (ASD). The American Psychiatric Association plans to merge Asperger s Disorder into Autism Spectrum Disorder [1] in version 5 of their Diagnostic and Statistical Manual (DSM). Apparently a primary reason for the change is the difficulty in assessing people into the various categories (AS, Autism, and PDD-NOS) and some variation in diagnosis between regions. Professor Simon Baron-Cohen (a leading researcher on Autism and Asperger Syndrome) wrote an insightful article about this for the New York Times [2]. He suggests that while genetic research about the causes of Autism Spectrum Disorders (ASDs) is in progress there should be no change. If it turns out that AS and Autism have the same genetic cause then that would be good evidence to combine them into a single diagnostic category. If however they turn out to have different genetic causes then they would need different categories and he suggests that changes should be delayed until this issue is resolved. Simon also raises the issue of the status of people who have already been diagnosed, this is one of the social issues relating to a change in diagnostic criteria. Social Issues related to Diagnosis Unlike some disorders listed in the DSM, many (possibly most) people with AS really care about such things. I think that a common reaction to being diagnosed with Aspergers is to make the study of ASDs a Special Interest , which therefore makes it impossible to ignore what the psychologists are doing in this regard. The biggest problem with changing the diagnostic criteria in this regard is that AS has a good reputation. Some people even think that it s generally a good thing and seem to imagine that every child who is diagnosed with it will end up working for Google! This means that parents will be less likely to reject a diagnosis and therefore will be more likely to try and create a good environment for their child and seek appropriate therapies (such as social skills training and occupational therapy). I expect that a child who is diagnosed as Autistic but who doesn t obviously conform to the worst stereotypes will likely have their parents reject the diagnosis which will lead to a bad result for everyone concerned. The contrary view in this issue is that people who are on the spectrum but who insist that they aren t Autistic are prejudiced and they should embrace the Autism Spectrum label as a measure of solidarity [3], while that s a reasonable point it s not going to happen in the short term. Also there is the issue of adult diagnosis of AS, there are lots of adults who could benefit from being diagnosed and obstacles to such diagnosis (such as associating it with a label that is not well accepted such as Autism) are not going to do any good for anyone. Is Asperger Syndrome really that similar to Autism? Roy Richard Grinker (Professor of Anthropology) wrote a positive article for the New York Times about the diagnostic changes [4]. He seems to think that because in some cases it is difficult to distinguish the difference between Autism and AS they should be in a single diagnostic criteria. Based on that logic you could say that no-one should be diagnosed with an ASD because there is never a clear dividing line between the Neuro-Typical and those who are on the spectrum! Some people are clearly on the spectrum, some clearly aren t, and some are near the border. Roy cites his daughter and Temple Grandin as examples of Autistic people who have greater ability to relate to animals than someone who is Neuro-Typical (NT). I don t have any particular skills in terms of relating to animals. Animals have smaller brains than humans and have thoughts that are less complex and more related to short-term issues, this makes them easier to predict in some situations. I do have significantly better skills in figuring out how to operate machines than most NTs, and this doesn t appear to be uncommon among Aspies. I ve read some of the material that Temple Grandin has written and watched the video of her TED talk, and I get a strong impression that she isn t like me. Even the Aspies who are the least successful in terms of their career (IE quite unlike Temple Grandin) often seem to be like me, I can understand the way they think and recognise that the problems they face are similar to mine but merely more severe. It seems to me that there are significant personality differences between people who have an affinity for animals and those who have an affinity for machines, maths, and engineering. I wouldn t be surprised if it was discovered that Autism and AS had different genetic causes, and this might mean that someone could have both sets of genes. It is obvious that the dividing line between Autism and AS is not that clear. It also seems that part of the diagnosis as implemented by psychologists may be based on the ability to act like an NT and succeed by objective criteria IE earn a good salary in the case of adults. One thing that Roy does get right is that he notes that among people diagnosed with AS and Autism there are both high and low functioning individuals. One thing that Roy gets wrong is the implication that Autistic people can become Aspies. An adult who is assessed without background information on their childhood may get a different diagnosis. If someone was reassessed as an adult with the full facts about their childhood available then (barring DSM changes) the same diagnosis should be returned. Conclusion It appears that this DSM change is going through regardless of the opinion of the people who are affected. While there is a logical basis for giving more weight to researchers than to the research subjects (who are bound to be more biased) it seems that there are some things you can t properly understand unless you live them. When a good portion of the research subjects feel compelled to share their experiences with anyone who will listen it is disappointing that so few of the researchers appear to be listening.

• [1] http://www.dsm5.org/ProposedRevisions/Pages/proposedrevision.aspx?rid=97
• [2] http://www.nytimes.com/2009/11/10/opinion/10baron-cohen.html
• [3] http://chaoticidealism.livejournal.com/76484.html
• [4] http://www.nytimes.com/2010/02/10/opinion/10grinker.html

Bernd Zeimetz:

From the other candidates I'd like to know their opinion and plans (if there are any) about license/copyright requirements in Debian.

I believe that intellectual property laws are wrong and should be abolished, so I am not particularly in favor of giving copyrights any more respect than necessary. However, I do not think that Debian is the place to undermine copyright, and that we should attempt to maintain standards which not only protect people from legal liability, but are also in the best interests of our developers and users. I do not know what level of nitpicking best serves our developers and users. A GR seems like an interesting way of determining at part of that. Anthony Towns:

What's your estimate of the current number of Debian users?

I do not have one. While I do acknowledge that the number of users does affect us in terms of potential contributor base, and scaling issues (including bug reporting), I do not think that the exact number is important at all to what we do. Also I would hope that whichever DPL is elected chooses to focus on practical matters rather than academic exercises. Kurt Roeckx:

I think that one of issues we have is that there is alot of work to be done by some teams, some of them even regularaly mail that they need more members, but they seem to have a hard time keeping the numbers up, burning the other team members out. What are your ideas to make sure those teams keep running?

• Diffusion of power throughout the rest of the project
• Delegation of people who do not seek to be core team members if they have the time, are willing, and would make good additions.

Note that I do not think it appropriate either for core teams to choose their own members or to reserve the privilege of demanding that a new person be able to work with them in a certain way. An ideal team member should be able to work with anyone. If the existing delegates are unable to work with new people, perhaps they are not ideal team members. Charles Plessy:

During the discussions that started after the GR, I suggested that the GR proposer should have more control about the options put to the vote. In particular, it would be useful if he can refuse an option that would disequilibrate the voting system. That would make him responsible for the success of the GR: discarding a popular option is taking the risk that the whole GR is refused and the option is accepted as a separate GR, which is the kind of public failure that I expect that people will avoid.

I do not think GR proposers should have any special control over general resolutions beyond what is Constitutionally granted at present. In fact, I would prefer if people did not try to propose multiple options or strategically craft ballots for any purpose. To me, the only honest method is to propose the outcome one genuinely wants to win, and let our strange and special brand of parliamentary procedure take care of the rest. As for the supermajority issue, I am not a huge fan of political word games. Debian distributes non-free software. We have a non-free section within our normal infrastructure, and while it is segregated and does not receive quite the same love that main does, it is still very much part of what we work on and distribute from our official infrastructure. So there is no amount of word lawyering, cognitive dissonance, or NM indoctrination that can make me believe that it is an honest statement to say that non-free is not part of Debian. Likewise I do not believe in redefining success or the meanings of Foundation Documents. I do not think that we should allow ourselves to pass any kind of magical resolution that contravenes the DFSG or Social Contract without actually modifying them. That seems utterly absurd to me, and I have seen what has become of the United States government.

When I first converted my journal from Movable Type, I converted all the comments with it and planned on adding comment support, as a long-term goal. But I've increasingly found that not having comment support is nice, and recently after reading several different takes on this topic, I've decided to take this off my long-term to-do list. A point made by both people involved with sites with strong commenting communities (Making Light and John Scalzi's Whatever) and others who have turned off comments is that maintaining a good comment community in the face of significant interest is a lot of work. One of my goals right now is to do less work that isn't directly interesting so that I can reserve my energy for things that I consider more core. I've now added a link to my explanation for why there are no comments to all of my journal posts and indices. A few more thoughts in addition to the ones there: I've been reading a lot of comments recently, mostly from following the debate in the US about health care reform, and I've been struck at how rarely comments are meaningfully addressed to the original post author or show intent to participate in a discussion. On political topics, most comments appear instead to be taking advantage of the comment platform to post one's own opinion in public, sometimes with the additional gratification of forcing that opinion to show up in the space of someone who obviously disagrees. I'm not interested in participating in or enabling that. If you want to make a controversial statement or take a political stance, own your own words and take that stance in your own space. I also suspect that one of the reasons why this happens so much in comments is that comments are considerably more anonymous than journals. Even if one's journal isn't openly connected with one's real name and life, like mine is, there is some persistance and history to most journals. I'm a strong believer in anonymous speech for a variety of different reasons, but one of those reasons is not to permit drive-by content-free attacks on other people. And that's the standard behavior in both political blogs and comment pages on newspaper sites. The anonymous speech I have the most respect for is the type that creates and builds reputation for an anonymous nom de plume, presenting a consistent public image and taking responsibility for one's previous beliefs. This isn't what happens in comment threads. Finally, I consider all of my web site, including my journal, to be to some extent permanent. I mostly do not take down pages, and I wouldn't want to take down comment threads. But for the most part comments, particularly on controversial topics, don't fit into that model. There's nothing wrong with that, but it makes me want to redirect them to a more appropriate forum. If I felt like there was some lack in the world of places where people could anonymously publish controversial opinions, I might feel more obligation to provide one in my journal, but I don't. It's also not something that I'm good at; other people are doing a much better job. So I'm going to stay out of hosting that type of on-line discussion and leave it to people with more interest and time. I welcome e-mail replies to journal posts, and have had several good discussions in those e-mail exchanges. That's what works best for me.

Gerfried Fuchs:

I have a question to the candidates: History has shown that DPLs more or less disappear not too long after their period or at least reduce their visible efforts immensly. I wonder where you see the reasons for this trend, what your impression is about it and wether you try to follow that trend or what you will try to do to not have this happen to you, too.

I think that some DPLs are overwhelmed by the amount of requests they receive, and more importantly, are overwhelmed by the feeling of futility from perceiving that it is impossible to fix the things that they had intended to fix. So, unless there are other factors I would need to adapt to, I would try to discourage the number of private requests, and to not lose hope and faith in Debian. I imagine that delegation could be very useful in both these areas. Gunnar Wolf:

What would be different if there was no leader? Where would the project lose more? Would it gain in some aspect?

The DPL is theoretically one of the most important checks against the power of delegates. The absence of a DPL would thus increase any power imbalance in the the project, and likely to make the fighting between core teams even more political and harmful. Communities and teams are destabilized by egos because people stop paying attention to their healthy shared goals and the people around them and instead focus on their own individual success. So if the project were to achieve some kind of anarchic utopia where this is not an issue, I could imagine that the DPL would be the last remaining ego threat, and removing that role would make things better. However, we are nowhere near that now, and I think the DPL can do more good on this front. Yavor Doganov:

What do you think the project should do (with or without or regardless of your help as potential DPL) to preserve this goodness (maximum supported architectures) for as long as possible? Do you think it is "goodness" or you're in the "good riddance" camp?

I definitely think that one of our strengths is being available on a large number of architectures, and beyond that, providing nearly identical experiences on each of those platforms. I am saddened when porters or package maintainers make decisions to stray from the norm on a particular architecture, because I truly enjoy the consistency. I have run Debian on i386, sparc, hppa, powerpc, amd64, and in the few cases where something was different, I found it irksome. However, there is definitely a point where the cost in maintaining a release architecture far exceeds the benefit, and at that time I think we must regretfully bid it farewell. So you are right that porters are a precious resource, and as DPL I would try to reduce their attrition. Speaking as a former porter, I found the unresponsiveness and uncooperativeness of certain buildd maintainers (especially when not porters themselves) to be extremely demotivating. I would try to find a way mitigate porters being demotivated in such a way.

In just under a month, Belgium will face Estonia in a Fed Cup World Group Playoff tie. The winning team will participate in the world group next year, which, in theory, opens the possibility of winning. So this is an important encounter. When team captain Sabine Appelmans announced the Belgian selection, it was described by the Belgian press as the 'dream team' Clijsters, Henin, Wickmayer and Flipkens, aka the four best Belgian female Tennis professionals. That, combined with the possibility of a World Group promotion, seems to excite much of the country, to the extent that 10000 tickets have been sold in no time. Yes, I'll be there too. But one man seems unhappy. Marc Wickmayer, father of Yanina, will say to everyone who wants to hear it, that 'Appelmans needs to choose'; that he's 'tired of the hypocrisy', and so on. His arguments: Clijsters and Henin have not been part of the Fed Cup selection in two years, and his daughter should not be the fourth wheel on the wagon after having been much of the reason why Belgium is playing these playoffs. Sigh. Let's check some facts, shall we?

• There are four singles rubbers. There are four players. Appelmans does not have to let any player play more than one singles rubber.
• Wickmayer is currently still the highest-ranked Belgian tennis pro, at number 14. Clijsters (17) and Henin (33) may have been ranked 1st before their respective comebacks, they are not now; and both still seem to be not entirely in their rhythm yet especially so Henin. Appelmans would be stupid to bet the entire encounter on them.
• Last but not least, let's not forget that the opposition may not be easy. Kaia Kanepi, Estonia's top player, may be ranked 100 now; less than a year ago, however, she was at her career-high of 18. Due to several injuries, a viral ilness, and some bad luck, she has not won much anymore since last may, but she may be a tough nut to crack.

Curiously, Yanina herself does not share her father's opinion. She's been quoted several times as being excited to have Clijstes and Henin on the team, since 'the team is much better with them'. Indeed. Her relationship with her father, is often described as being 'very close'; apparently that doesn't mean they are of the same opinion on everything. Maybe it is time for the two of them to have a little chat on the whole Fed Cup thing, before this gets out of hand. I'd hate for Appelmans to have to make the wrong choices to appease people...

Note: this post was written on March 16 and posted after our return home. Also, I took no photos in Berlin, reasoning that I could leave my camera at the hotel so as to not worry about it, since I m sure there are enough photos of the Brandenburg Gate in the world already. Photos on this story only are from others. We ve had a good time in Berlin it s been adventurous to be out on our own in an unfamiliar city with an unfamiliar language, but has gone well. I feel that I m finally getting used to it a bit, and now tomorrow we move on to Leipzig. Stepping off the train at the Berlin Hauptbahnhof, and seeing all those people connecting to all those trains, I had a feeling of excitement: here is a grand train station that is actively used by so many people. I got a sense of what the beautiful and enormous Kansas City Union Station once felt like, I think; that station at its peak served almost the same number of people in a day at Berlin Hbf does.
(photo by eliotc) Stepping outside in the cold and snow to wait for our bus, I got the first sense that Berlin felt a bit more like an American city than did L beck: a beggar with a suspicious story was working the crowd with Speak English? (We saw many dressed similarly using the exact same tactic during our stay in Berlin.) Our bus ride to the hotel showed us some graffiti a fact of life in many cities in the USA too. Our hotel, the Circus, most definitely did not feel American. The staff was very friendly (I think I ve only seen that level of friendliness and helpfulness at one hotel in the USA: the Portland Doubletree). The room was small (which we expected) but very nice. There was a fresh flower waiting, and a whole printout of information with my name on it waiting in the room: info about the hotel, restaurant, and a multi-page history of this part of the city. They are very energy-conscious there. The hall lights automatically turn off, but you can touch your (apparently RFID-enabled) room card to any switch to turn them on for a few minutes. When in your room, you put your key card in a little holder that keeps it safe and enables the use of the lights. They don t put shampoo in the rooms, but have a selection free for the taking at the front desk: the rationale being that it generates waste when they have to replace it for people that don t need it replaced. They are very environmentally conscious with everything except the showerhead, which appears to use so much water that it would be illegal in the USA. Here s the obligatory surprising to an American comment about Germany: the complete lack of water drinking fountains. In the US, you can get a drink of water at any building of any size airports, train stations, museums, shopping centers, and also in many public places such as parks. I may have seen exactly one water fountain in the Hamburg airport, but that was it. It is odd given the general sense of environmentalism here that so much energy is being wasted on bottling water, not to mention the expense of having to pay for it all over the place. The bus ride to the hotel was interesting. I needed to buy two tickets from the bus driver. I didn t know the German word for ticket, so I just guessed and went with Zwei Ticket, bitte. Wohin? Rosenthaler Str. Then the price came up. I believe that was my first completely successful German-only conversation. (Most Germans hear a couple of words of mine and quickly switch at least partially to English, which probably gets things done a lot faster, and saves me embarrassment, but doesn t give me much chance to practice my German.) We ate dinner Monday night at the Hackesche H fe at Weihenstephaner, a Bavarian restaurant. It was a fun meal, and the tables were long and seated multiple parties. I tried out their special Bavarian beer, and of course had some Wienerschnitzel. I had noticed apple strudel on their website but not on their menu, so when it was time for dessert, I asked our waitress if they had apple strudel today. They did, and it was delicious. Tuesday began with a walk to the Pergamon Museum. From our hotel, this was a walk of about a mile. We had been introduced to excellent German bakeries during our time in L beck. So, since we hadn t had breakfast, when we spotted a bakery along the road, we went in. Terah got a croissant with chocolate on top, which turned out to also have chocolate inside. I found a couple of smaller rolls with various seeds and flavorings on top. All were excellent, and I believe we spent less than EUR 2 all together. We ate our breakfast of rolls as we walked towards the museum. It was a cold and somewhat windy morning, but it was also fun and exciting to be there. The Pergamon was quite the experience. The Pergamon Altar was the first large artifact we saw, and was particularly interesting given that I have recently read The Iliad and The Odyssey.
(photo by *hoodrat*) The Market Gate of Miletus was also impressive, but the true highlight has to be the Ishtar Gate and processional way. Wow. It was built in 575BC by King Nebuchadnezzar II, and importantly was built out of glazed tiles, so the original artwork, color and all, still survives. You can walk through the processional way and get the feeling of kings and armies proceeding there. Truly spectacular.
(photo by Rictor Norton & David Allen) After the Pergamon, we crossed a bridge to the east taking us off Museumsinsel (Museum Island). We walked down a quiet and somewhat forgotten back street and found a small restaurant for lunch. I had the Berlin Wurst , some excellent sausage with excellent and not-so-sour sauerkraut. Terah had some breakfast-type items with fruit. After that, we walked over to the famous Unter den Linden. It wasn t yet spring, so the scenery wasn t all that spectacular yet, but that and the light snow didn t stop the tourists, or the tacky tourist shops, which appear to be a universal global feature. ( Berlin flip-flops and t-shirts made in China, anyone?) The destination of all this walking was the Brandenburger Tor, the famous Berlin icon. The Brandenburg Gate was immense, and the sense of history of standing there was impressive.
(photo by Andrew Mason) We of course walked through the Brandenburg Gate on our way to the Bundestag, which we intended to tour. We didn t, though, due to the cold and very long line snaking out of the building. We then got on the train to Checkpoint Charlie. We saw the outdoor checkpoint still in the middle of the street. We intended to visit the museum Haus am Checkpoint Charlie, but was so packed that it was difficult to even get in the door. We stood in line to buy tickets for a few minutes, but made absolutely no progress; meanwhile, it appeared that an entire school group came in after us somehow and was also waiting to pay. So we decided to go see Schloss Charlottenburg instead.
(photo by Poom!) The Schloss (palace) was a baroque design, intended to impress visitors with the power and wealth of the owners. Only the old wing was open Tuesday, but we had about an hour and a half available to tour it: enough to see the whole thing, but not enough to linger and read all of the information. It was impressive and interesting. Particularly interesting was the chapel, which was this odd state/religion combination decorated both with sacred symbols as well as symbols of the king. After Charlottenburg, we had dinner at the Prussian Restaurant Marjellchen near the Savignyplatz S-bahn. We started with a smoked herring appetizer. Then I had the K nigsberg meatballs, and Terah had creamed ham. Both of us really enjoyed our meals, and Terah s reminded her of Verenike. Wednesday started with an early rise, then we went to Mauerpark to see a remnant of the Berlin Wall. I am glad to have seen it, and was a bit surprised with how small it was at that point compared to my expectations.
(photo by Eichental) Then we had a few minutes back in our hotel to munch on some rolls for breakfast; after that, it was off to the Hauptbahnhof for our train to Leipzig.

Note: This post was written in March 14-15 and posted after our return. When I think about L beck, the first thing that strikes me is the feeling of history underfoot. It struck me most when we set foot inside the Marienkirche. I had never quite felt a wave of a feeling of stepping back in time like that before. The stones on the floor were uneven and imperfect. L beck has had a wet and snowy winter, so the city had spread sand everywhere: sidewalks and roads. Walking into any grand church, I could hear the sound of sand under the shoes of everyone nearby, and feel it under my own shoes. I think I will long associate with L beck the feeling of walking into a grand old church, looking up at the top of the old building at seemingly impossible heights, while feeling the grit of sand and uneven stone beneath my feet. Marienkirche isn t perfect, like some American churches I ve been in, such as the Basilica of Notre Dame. It doesn t have a lot of gold, either, and both of these attributes are wonderful. Look at a column of bricks, and you can see that each brick isn t exactly like its neighbor, and the entire column isn t perfectly straight. Lots of things in L beck are so old that they aren t perfectly straight, and it made me think that our American notion of always having to fix such things might be somewhat off sometimes. Look up, and you see the frescos from the 1300s, revealed after many years after the building was struck by an allied bombing raid in 1942. This heavily damaged the building and knocked down plaster from the walls and ceiling, revealing the old artwork. Many parts of Marienkirche were lost as a result of the bombing, which perhaps adds to its slightly sparse and ancient feel. The church bells were sadly melted and crashed to the ground due to the bombing, and have been left exactly where they fell as a memorial. Look down, and you see the uneven floor, and the concrete slabs above where important people were buried under the floor an attribute common to many of the churches we visited. It was common to see dates of graves from the 1600s and 1700s, though in some places it would go as far back as the 900s. The main part of the church has no heating or cooling, and visiting it on a day just a bit above freezing adds to the feeling of, well, old. Marienkirche has to be my favorite sight in L beck. Walking around the city, I get a similar feel. Many streets and sidewalks are made of stone. The streets that weren t damaged in the war have rows of beautiful old facades. Walk down many streets, and every so often I d see a little tunnel ( just wide enough for a coffin ) that goes under the street-facing houses to a nice little inner courtyard. These are open to the public, but tend to be very quiet and somewhat private. In the courtyard are smaller houses, which would have originally been used by the less wealthy. We also saw the L beck Dom (cathedral), which had a small museum about the destruction due to the Royal Air Force bombing in 1942. It was very sad to see the photo of the Dom in ruins, still smoking, even now. I can only imagine what it must have felt like to residents of L beck to wake up to see many of their priceless centuries-old landmarks and places of worship so horribly destroyed and all of this for little strategic purpose really focused on the morale of the enemy civil population . It s sad that the allies would do such a short-sighted and terrible thing. Europeans have long had to live with the legacy of war upon war, while we Americans have rarely had to see the consequences of war up close. I think it would be good for more of us to visit these sites and come up face to face with what a bomb can do, and then perhaps we will be more judicious with them in the future. Shifting gears now to where we stayed: Andreas & Sigrid, with whom we stayed, have a beautiful 500-year-old house, with lots of original wood beams exposed, and some very old paintings on the walls and ceilings. Nearby were excellent bakeries and a chocolate shop. Terah and I visited it today and bought some very good chocolate. And this brings me to the second thing I ll remember: Andreas & Sigrid s children, Lukas and Rahel. Now, Terah knows no German, I know only a little bit, and the children know no English. So it was a bit slow getting to know each other to start out, but we managed to work around the communication barrier and had a great time. Terah played board games with Rahel, while with me, she kept inventing games to play: hiding somewhere, saying Hallo! , and laughing at how many unsuccessful attempts I might make to find her. I showed Lukas the camera on my Droid, which he used a lot, though a racing game on Terah s iPod Touch was more exciting. They both enjoyed looking at videos of American trains a bit, but especially pictures of our house and yard with Jacob and Oliver. They tried to teach me the German words for things, and also made futile attempts to correct my pronunciation! When we were leaving today, Rahel came over and gave me a kiss on the hand, then the same to Terah s hand, then a little kiss on one of our suitcases. It was touching and sweet. This was one of those experiences no guidebook prepared me for, and no tour bus would have provided. It is something neat to make friends with children despite the large language barrier. On to the rest of the visit We had arrived a little late into Hamburg. After getting our bags and some Euros at an ATM, the next step was to find the bus to L beck. No signs for it were evident, so I found an information desk. The person at the desk was carrying on a conversation in German with the person ahead of me in line. I figured an information desk person in a busy airport would speak English, and was all ready to ask Sprechen Sie Englisch? , but when I walked up, he got a polite smile, and said, Good morning! How can I help? Guess I m obvious. He directed me to the bus, gave me a brochure about it, and told me what time it would leave. Terah and I found the spot to wait, and for a moment I stepped inside the airport terminal. Terah won t let me forget that someone came up to her and asked a question in German, whereas I was spoken to in English. Anyhow, we found the bus, managed to communicate with the driver that doesn t speak English, and sat next to the friendly person that was talking to Terah. He turned out to be a violin player from Munich, and we had a great conversation for the next hour he asking questions about the USA, us asking questions about Germany and Munich. At one point, he commented, You two are so open minded and you re also Americans! He sounded surprised. We exchanged email addresses at the train station. Andreas found us there, and we walked through the city to his house, with him pointing out the sights along the way. L beck is a beautiful city, and though it was damaged in World War II, much of the really old parts still remain. The famous Holstentor Gate has a museum inside, which was fascinating to visit. On Sunday, we went to church with the family we were staying with, Andreas helpfully translating for us. There I met a British Python programmer, which was fun. His wife is a social worker, which was fun for Terah. Monday it was time to get on the train to Berlin. We again walked through a cold and rainy city to the Hauptbahnhof, ready to head to Berlin. There we got on a train to Hamburg, then an ICE train to Berlin. Despite having just a few minutes for a connection in Hamburg, it all went perfectly smoothly. The train left Leipzig about 10 seconds late the clock inside turned over to the minute, then the doors closed and we were off. Impressive. Note: the rest of my photos from L beck are available on Flickr.

When in California last year I visited the NoiseBridge [1] Hackerspace. I was very impressed with what I saw, good equipment and very friendly people. The general concept of a HackerSpace is that it is an environment to support random creative projects. The first picture is a sign near the door which is clearly visible to anyone who is leaving, it encourages people to be AWESOME and EXCELLENT by cleaning up after themselves (and maybe others). I think that this demonstrates the core of what is needed to get such a community project going. Generosity towards others was on display everywhere, there was some free fruit on a table as well as a bottle of Port for anyone to drink. Someone had written a note saying that it s not an insecure Port (a computer security joke). Someone had created an artwork that resembled an advert which some idiots had mistaken for a terrorist bomb (the creature displaying the Impudent Finger). The main (only?) phone in NoiseBridge is apparently a VOIP phone, it is located next to an old pay-phone along with some Magnetix and other toys that can be used by curious people of any age. Magnetix have had repeated safety problems that caused recalls so maybe such things are best placed in an 18+ environment. When I visited about 10 people were working on electronics projects. There were a number of soldering irons in use and some serious test equipment (including a couple of CROs) was available. The people doing the soldering were eager to teach other people about their work. Other equipment that was available included some serious industrial sewing machines and some drill presses. A lot of that equipment is unreasonably expensive to buy for personal use and is also rather bulky to store, having it available in a central location is a great service for the community. Finally Noisebridge has a lot of space. There are rooms that could be used for giving small lectures and couches in the central area for people to relax and have impromptu meetings. Of course they had wireless net access too. Australian Hacker Spaces Kylie Willison has written about the Adelaide Hackerspace which sounds promising [2]. The Connected Community Hackerspace is a new one in Melbourne [3]. It operates out of the homes of members so it s not nearly as big as Noisebridge (which has a substantial property rented for 24*7 operation). I hope that we can get something running permanently in the Melbourne city area in the near future. The Noisebridge membership dues are $80 per month (or $40 for starving hackers). I would pay that for a comfortable chair in a convenient city location with net access surrounded by cool people!

• [1] https://www.noisebridge.net/wiki/Noisebridge
• [2] http://kyliewillison.blogspot.com/2010/03/adelaide-hackerspace.html
• [3] http://groups.google.com/group/connected-community-hackerspace

Note: I wrote most of this before Neil Williams' recent comments on the 3.0 family of formats, so despite the timing this isn't really a reaction to that although I do have a couple of responses. On the whole I think I agree that the Lintian message is a bit heavy-handed and I'm not sure I'm thrilled about the idea of the default source format being changed (though I can see why the dpkg maintainers are interested in that). That said, as far as I personally am concerned, there is a vast cognitive benefit to me in having as much as possible be common to all my packages. Once I have more than a couple of packages that require patching and benefit from the 3.0 (quilt) format as a result, I find it in my interest to use it for all my non-native packages even if they're patchless right now, so that for instance if they need patches in the future I can handle them the same way. It's not unheard of for me to apply temporary patches even to packages I actively maintain upstream, so I don't discount those either. I haven't decided what to do with my native packages yet; unless they're big enough for bzip2 compression to be worthwhile, there doesn't seem to be much immediate advantage to 3.0 (native). Anyway, on to the main body of this post: I've been one of the holdouts resisting use of patch systems for a long time, on the basis that I felt strongly that dpkg-source -x ought to give you the source that's actually built, rather than having to mess around with debian/rules targets in order to see it. Now that the 3.0 (quilt) format is available to fix this bug, I felt that I ought to revisit my resistance and start trying to use it. Migrating to it from monolithic diffs is of course a bit more work than migrating to it from other patch systems, so it's taken me a little while to get round to it. I'd been thinking about holding off until there was better integration with revision control (e.g. bzr looms), as I feel that patch files really ought to be an export format, but I eventually decided that I shouldn't let the perfect be the enemy of the good. I have enough experience with co-maintaining packages that use build-time patch systems to be able to compare my reactions. After experimenting with a couple of small packages, I moved over to the deep end and converted openssh a few weekends ago, since quite a few people have requested over the years that the Debian changes to openssh be easier to audit. This was a substantial job - over 6000 lines of upstream patches - but not actually as much work as I expected. I took a fairly simplistic approach: first, I unapplied all the upstream patches from my tree; then I ran bzr di interdiff -q /dev/stdin /dev/null >x, reduced it to a single logically-discrete patch, applied it to a new quilt patch using quilt fold, and repeated until x was empty. This was maybe an hour or two of work, and then I went through and tagged all the patches according to DEP-3, which took another few hours. After the first pass, I ended up with 38 patches and a much clearer idea of what has been forwarded upstream and what hasn't; I currently have 5 patches to forward or eliminate, down from 18. Good things:

• I don't lose any of my history. Since all the patches remain applied to the tree in revision control (this is what dpkg-source -x gives you, so it's the natural representation in revision control too), bzr blame works just as you'd expect and displays both upstream and Debian changes at once. I rely on tools like blame a lot, and I really hate the way build-time patch systems make it hard to use revision control when the tree is in a built state, so this was a hard requirement for me.
• I've used patch tagging before, so I was expecting some benefits, but viscerally I feel much more in control. It's so much less laborious now to see what I need to do by way of forwarding. I don't regret waiting for 3.0 (quilt) to become available, but I hadn't realised quite how much I was being held back beforehand.
• Adding new patches is pretty natural, much more so than with build-time patch systems. You can create and apply the patch, test-build, and commit when it works. I much prefer this over having to clean the tree before committing (or commit just part of the tree, which is error-prone). The more that committing to a Debian package feels like committing to an upstream project, the better.
• There's definitely something to be said for patch-tracker being more useful. It deals with DEP-3 to the extent of linkifying URLs, although it might be nice if patch descriptions were displayed on the overview page for each version.

Bad things:

• It's a bit awkward to set things up when checking out from revision control; I didn't really want to check in the .pc directory, and the tree checks out in the patched state (as it should), so I needed some way for developers to get quilt working easily after a checkout. This is sort of the reverse of the previous problem, where users had to do something special after dpkg-source -x, and I consider it less serious so I'm willing to put up with it. I ended up with a rune in debian/rules that ought to live somewhere more common.
• Everything ends up represented twice in revision control: the patch files, plus the changes to the patched files themselves. I'm OK with this although it is a little inelegant.
• Although I haven't had to do it yet, I expect that merging new upstream releases will be a bit harder. bzr will deal with resolving conflicts in the patched files themselves, and that's why I use a revision control system after all, but then I'll have to go and refresh all the patches and will probably end up doing some of the same conflict resolution a second time. I think the best answer right now is to quilt pop -a, force a merge despite the modified working tree, and then quilt push && quilt refresh -pab until I get back to the top of the stack, modulo slight fiddliness when a patch disappears entirely; thus effectively using quilt's conflict resolution rather than bzr's. I suppose this will serve as additional incentive to reduce my patch count. I know that people have been working on making this work nicely with topgit, although I'm certainly not going to put up with the rest of git due to that; I'm happy to wait for looms to become usable and integrated. :-)
• It would be nice if there were some standard DEP-3 way to note that a patch has been accepted or rejected upstream, beyond just putting it in the description. In particular, it seems to me that listing patches accepted upstream could be used to speed up the process of merging new upstream releases.

On the whole I'm satisfied with this, and the benefits definitely outweigh the costs. Thanks to the dpkg team for all their work on this!

Note: I wrote most of this before Neil Williams' recent comments on the 3.0 family of formats, so despite the timing this isn't really a reaction to that although I do have a couple of responses. On the whole I think I agree that the Lintian message is a bit heavy-handed and I'm not sure I'm thrilled about the idea of the default source format being changed (though I can see why the dpkg maintainers are interested in that). That said, as far as I personally am concerned, there is a vast cognitive benefit to me in having as much as possible be common to all my packages. Once I have more than a couple of packages that require patching and benefit from the 3.0 (quilt) format as a result, I find it in my interest to use it for all my non-native packages even if they're patchless right now, so that for instance if they need patches in the future I can handle them the same way. It's not unheard of for me to apply temporary patches even to packages I actively maintain upstream, so I don't discount those either. I haven't decided what to do with my native packages yet; unless they're big enough for bzip2 compression to be worthwhile, there doesn't seem to be much immediate advantage to 3.0 (native). Anyway, on to the main body of this post: I've been one of the holdouts resisting use of patch systems for a long time, on the basis that I felt strongly that dpkg-source -x ought to give you the source that's actually built, rather than having to mess around with debian/rules targets in order to see it. Now that the 3.0 (quilt) format is available to fix this bug, I felt that I ought to revisit my resistance and start trying to use it. Migrating to it from monolithic diffs is of course a bit more work than migrating to it from other patch systems, so it's taken me a little while to get round to it. I'd been thinking about holding off until there was better integration with revision control (e.g. bzr looms), as I feel that patch files really ought to be an export format, but I eventually decided that I shouldn't let the perfect be the enemy of the good. I have enough experience with co-maintaining packages that use build-time patch systems to be able to compare my reactions. After experimenting with a couple of small packages, I moved over to the deep end and converted openssh a few weekends ago, since quite a few people have requested over the years that the Debian changes to openssh be easier to audit. This was a substantial job - over 6000 lines of upstream patches - but not actually as much work as I expected. I took a fairly simplistic approach: first, I unapplied all the upstream patches from my tree; then I ran bzr di interdiff -q /dev/stdin /dev/null >x, reduced it to a single logically-discrete patch, applied it to a new quilt patch using quilt fold, and repeated until x was empty. This was maybe an hour or two of work, and then I went through and tagged all the patches according to DEP-3, which took another few hours. After the first pass, I ended up with 38 patches and a much clearer idea of what has been forwarded upstream and what hasn't; I currently have 5 patches to forward or eliminate, down from 18. Good things:

• I don't lose any of my history. Since all the patches remain applied to the tree in revision control (this is what dpkg-source -x gives you, so it's the natural representation in revision control too), bzr blame works just as you'd expect and displays both upstream and Debian changes at once. I rely on tools like blame a lot, and I really hate the way build-time patch systems make it hard to use revision control when the tree is in a built state, so this was a hard requirement for me.
• I've used patch tagging before, so I was expecting some benefits, but viscerally I feel much more in control. It's so much less laborious now to see what I need to do by way of forwarding. I don't regret waiting for 3.0 (quilt) to become available, but I hadn't realised quite how much I was being held back beforehand.
• Adding new patches is pretty natural, much more so than with build-time patch systems. You can create and apply the patch, test-build, and commit when it works. I much prefer this over having to clean the tree before committing (or commit just part of the tree, which is error-prone). The more that committing to a Debian package feels like committing to an upstream project, the better.
• There's definitely something to be said for patch-tracker being more useful. It deals with DEP-3 to the extent of linkifying URLs, although it might be nice if patch descriptions were displayed on the overview page for each version.

Bad things:

• It's a bit awkward to set things up when checking out from revision control; I didn't really want to check in the .pc directory, and the tree checks out in the patched state (as it should), so I needed some way for developers to get quilt working easily after a checkout. This is sort of the reverse of the previous problem, where users had to do something special after dpkg-source -x, and I consider it less serious so I'm willing to put up with it. I ended up a rune in debian/rules that ought to live somewhere more common.
• Everything ends up represented twice in revision control: the patch files, plus the changes to the patched files themselves. I'm OK with this although it is a little inelegant.
• Although I haven't had to do it yet, I expect that merging new upstream releases will be a bit harder. bzr will deal with resolving conflicts in the patched files themselves, and that's why I use a revision control system after all, but then I'll have to go and refresh all the patches and will probably end up doing some of the same conflict resolution a second time. I think the best answer right now is to quilt pop -a, force a merge despite the modified working tree, and then quilt push && quilt refresh -pab until I get back to the top of the stack, modulo slight fiddliness when a patch disappears entirely; thus effectively using quilt's conflict resolution rather than bzr's. I suppose this will serve as additional incentive to reduce my patch count. I know that people have been working on making this work nicely with topgit, although I'm certainly not going to put up with the rest of git due to that; I'm happy to wait for looms to become usable and integrated. :-)
• It would be nice if there were some standard DEP-3 way to note that a patch has been accepted or rejected upstream, beyond just putting it in the description. In particular, it seems to me that listing patches accepted upstream could be used to speed up the process of merging new upstream releases.

On the whole I'm satisfied with this, and the benefits definitely outweigh the costs. Thanks to the dpkg team for all their work on this!

Overview The German supermarket chain Aldi has been running in Australia for 8 years now [1]. Their standard practice for a long time has been to offer regular special deals on a few items of consumer electronics every week, my chocolate fridge is one thing I bought from Aldi [2]. Today Aldi have started selling Noise Canceling Headphones [3]. These headphones are badged by Bauhn but that name is apparently applied to random products from cheap manufacturers, it may be an Aldi name that is applied to stuff that they sell. The headphones cost $69AU which is really cheap. But the deal will probably end in less than a week when stock runs out. Noise canceling headphones can be used in server rooms and other noisy environments. Every company that has a server room should buy a few sets. One of the features of noise-canceling is that it works best on low frequencies and on regular sounds it specifically doesn t block human voice well. In some noisy environments it will be easier to hear people talk if you wear such headphones! Noise canceling headphones are also very useful to people who are on the autism spectrum and other people who get more annoyed by noise pollution than average people. I have been wearing my Bose headphones on public transport and when walking around in the city, this not only stops traffic noise but it also helps to avoid people thinking that I want to talk to them. Features The first picture shows me wearing the Bauhn NC headphones, it s from the right to show the controls for the built-in MP3 player. I have not yet tested the MP3 functionality. It appears that as the controls are one power button, buttons for next/previous track, and for controlling the volume. This is fairly poor for MP3 functionality, ideally you would want to have a display to see a list of tracks, maybe have directories to store files, etc. I guess this could be a convenient feature on occasion, but you wouldn t buy the headphones for the MP3 functionality.
The next two pictures show a comparison of the Bauhn headset with the Bose QC-15 headset that I bought last year [4]. The cases of the Bauhn and Bose devices are almost exactly the same size and of a very similar shape, the Bose case is tapered and indented and also has a finer weave on the cloth covering it looks much nicer. Both devices come with an adapter for an airline socket and with a detachable cable. They also both have pouches attached to the inside of the case with velcro. But the Bauhn headphones come with an adapter for the 6.5mm TRS connector which could be convenient if you want to plug them in to a larger amplifier, the basic connector is 3.5mm in both cases. The Bauhn device uses a standard TRS connector at the headphone end while the Bose QC-15 use a special connector that matches the shape of the headset and which has a TRRS plug (to cater for the high/low volume switch), so it seems that a damaged Bauhn cable could be replaced cheaply while a replacement Bose cable would have to be purchased from Bose (presumably at great expense and delay). The Bauhn case also has a velcro attached pocket for storing business cards (or maybe a name tag or something). The supplied cable for the Bauhn is described as being 5 feet long which isn t quite long enough to reach a tower PC that is sitting on the floor. The Bose has a cable that is about a foot longer (maybe 6 feet total), but due to the non-standard connector you can t replace it. I presume that I could easily buy a 4 meter cable for the Bauhn headphones, but I could of course buy an extension cable to use with the Bose. Bose advertise the QC-15 headphones as having 35 hours of battery life from a single AAA battery. Aldi advertise the Bauhn headset as having 5 hours of battery life when NC is turned on and they use two AAA batteries. It s widely regarded that rechargeable batteries don t last as long as the batteries used for estimating the battery life (which presumably are the most expensive long-life batteries available). I ve found a single rechargeable AAA battery to last well over 5 hours in my Bose headphones, so it seems that battery life is considerably worse for the Bauhn device. One feature of the Bauhn device is that it can be used without any batteries for playing external music. The Bose headphones can t be used at all without a battery. So while the Bauhn will use the batteries faster it will at least be usable when the batteries run out. But if you are buying headphones for the purpose of avoiding noise then the Bose headphones are simply better. Comfort The Bose headphones have significantly deeper ear wells than the Bauhn about 23mm vs 18mm. If your ears stick out more than 18mm (as mine apparently do) then this is a good reason for choosing Bose. The Bose headphones are a tighter fit, the spring that pushes the ear-pieces together is stronger. But they have better padding so this doesn t cause me any discomfort. Also the Bose headphones have better passive noise reduction due to having a more snug fit around the ears. I ve worn my Bose headphones on a flight from the US to Australia with hardly a break and they were quite comfortable I would never want to do that with the Bauhn headphones. Noise Reduction I tested the Bose and Bauhn products against three noise scenarios, external music, an air-conditioner, and a car engine. The Bose headphones made good reductions of the noise from the external music (Numb by Linkin Park) and the air-conditioner. The Bauhn headphones did little to stop Linkin Park and was not very effective against the air-conditioner noise. I think that this is largely due to the lack of passive noise reduction, the air-conditioner in question makes little vibration noise and the sound of rushing air is generally immune to active noise cancellation. Both headphones were very effective when in a car with the engine idling. The engine noise of vehicles seems to fall in an ideal frequency range for active cancellation. Music Quality When listening to Youtube music played on my Thinkpad I could not notice any quality difference between the two sets of headphones. I did notice that the Bose headphones seemed to have a greater response in the higher frequency range, but that doesn t necessarily mean that one set is better than the other. Maybe if I was listening to FLAC0 encoded music that I had personally ripped from a CD then I would notice a difference. But for most people the Bauhn music quality should be good enough. Design Quality The Bose product is solidly designed, while the Bauhn product appears cheap in every way. Opening the battery compartment on the Bauhn headphones is difficult and if you do it wrong you could easily break the lid off, I expect that every set of Bauhn headphones that is used by children will be broken in a small amount of time but it should still be fully functional with a broken lid. The matt finish of the Bose headphones should hide minor scratches much better than the shiny Bauhn headphones. The Bauhn headphones also have lower quality plastic parts, it appears that the molds used were designed cheaply and without adequate care to prevent marking the final product. The design flaws that affect usage of the Bauhn product are the shallow ear wells, the poor fit of the cushions around the ears (which is probably mostly due to a weak spring pressing the ear cups to the wearer s head), and the battery compartment lid which is difficult to open and appears prone to breakage. The other flaws are all cosmetic. I wonder whether the Bauhn product was made by one of the big name manufacturers who deliberately reduced the quality to avoid competing with their more expensive products. It seems that the major flaws could have been corrected at design time with almost no increase in manufacturing costs. Recommendations If you can afford the Bose QuietComfort 15 Acoustic Noise Cancelling Headphones then they are really worth the extra expense, I have no regrets at all about spending about $320US (including tax) on my Bose QC-15. The Bauhn product is good for when you want something cheap, for example a set to be used in a server room, or for the use of children. I bought a Bauhn headset for a friend who is a pilot, he spent $1,100 on a noise-canceling headset for his plane but had never got around to buying one for recreational use I expect that he will allow his children to use his new Bauhn headphones, if they get broken it s only a $69 expense. The second cheapest NC headphones I ve seen on offer in Australia is Harvey Norman selling Phillips HN-110 Noise Canceling Headphones for $100AU [5]. Amazon sells Philips HN 110 Folding Noise-Canceling Headphones for $50US but doesn t seem to ship them outside the US (at least not to Australia). JB Hifi also has some NC headphones on sale in Australia [6], but they are more expensive at $219 for AKG and $319 for Sennheiser. Also the models they sell are on-ear which means that they will inherently have very little passive noise reduction and will also annoy anyone who doesn t like having their ears squashed. If I was buying NC headphones for my own use and didn t want to spend $300US then I would either buy the Philips HN 110 Folding Noise-Canceling Headphones from Amazon and get a friend in the US to post them to me or I would buy them from Harvey Norman. But the Bauhn product is good if you want cheap headphones to stop engine noise and give reasonable quality when playing music.

• [1] http://aldi.com.au/
• [2] http://etbe.coker.com.au/2010/02/28/chocolate-fridge/
• [3] http://aldi.com.au/au/html/offers/2827_12539.htm
• [4] http://etbe.coker.com.au/2009/12/20/bought-the-qc-15/
• [5] http://www.harveynorman.com.au/product/1255509334278/phillips-full-size-noise-reduction-headphones
• [6] http://www.jbhifi.com.au/portable/mp3-players/head-phones/noise-cancelling/

Yay! The dlr-languages package has been migrated to testing, which means that it will be included in squeeze, the next release of Debian. Jo has uploaded the -2 version and it is now in sid. This version addresses the issues brought up in the Ubuntu Feature Freeze exception (FFe) bug, so I expect that it will be accepted shortly. Still lots of ifs , but this is pretty exciting for me, since this is my first debian package, and I ve been intending to get it in for over two years. I m not just sitting on my hands while this happens. I ve been working with Ivan, Ankit, Dino and Michael to get the next version of the package put together. I m currently merging Ivan s latest branch into the changes I ve made for DFSG compliance. Dino recommended that the next release include IronRuby 1.0 and IronPython 2.6.1, which should be released by upstream around the middle of April.

So, Thailand Mini-DebCamp 2010 in Khon Kaen has already ended. It's another memorable event I've joined, and especially for this one, been in the organizing team. We owed many people for its success. I'd like to thank our guest DDs for their talks, many of which are improvised. Special thanks to Paul Wise and Yakiharu Yabuki for preparing the talks on Debian Social Contract and Debian packaging in one night, so our audiences can prepare themselves for the Bug Squashing Party in the next 3 consecutive days. Thanks Paul Wise, Andrew Lee, Yakiharu Yabuki, Daiki Ueno, Christian Perrier and our local participants for their efforts in tackling more than 50 bugs during the BSP, 30 of which have been closed and 14 with proposed patches. Thanks Christian Perrier for several talks in the last two days. We also had Andrew Lee's talk on Debian EzGo project, along with talks from our local distro developers (Linux SIS, Linux TLE) on what are being worked on and what can be pushed into Debian. And Neutron Soutmun had presented some future plan on the RahuNAS, a captive portal software based on Debian. A special agenda had been arranged to improve Debian mirroring in Thailand. Chatchai Jantaraprim, the ftp.th.debian.org maintainer, had shared us the backgrounds and motivations behind the official mirror setup for Thailand. Andrew Lee, the ftp.tw.debian.org maintainer, had introduced us to the Debian mirroring infrastructure, and encouraged the local mirror Debian mirror maintainers to do it Debian way. We had exchanged experiences and problems found among the current mirror sites, which can be much useful for their improvements, as well as cooperation in the future. Christian Perrier had also introduced us to the Debian translation workflow and how to coordinate translation via mailing list. This can be useful in the future for Thai if we can form a team, rather than a single-handed translation as present. Christian's talk on Debian contribution paths, along with their fresh hands-on experience in the BSP, had indeed motivated many local people to join Debian. I've been told by some people that they wanted to actually join Debian after this event, after just having a wish to do so for a long time. And Christian's yet another talk on key signing, with live demonstration, was really helpful for Thai audiences, as few of us were familiar with the concept and practice. Yes, taking care of PGP key does require special cares! Night chats and parties were also cool. We enjoyed the drinks (especially, Debian wine!), snacks, and chats together, and exchanged many stories. For me personally, it made me feel Debian as a live community, with people living in it. For the record, we even had a real bug squashing party, as fried bugs are among well-known Esaan dishes. And we had immediately got new voluntary vegetarians because of it! Hee hee.. Hello Christian, I witnessed it. ;-) And thumbs up to Yabuki for his bravery! Yes, it's a wonderful event for me indeed. Thanks Khon Kaen University (Kitt Tientanopajai et. al.) for hosting it. Thanks NECTEC Information and Mobile Applications Program and Science Park KKU for the financial support. Thanks NECTEC people for taking care of foreign participants in traveling between Bangkok and Khon Kaen. And thanks all participants for their contributions to make this event a great one! Picture credits: Supphachoke Suntiwichaya, DebConf Gallery