At DebConf10, there was a BOF entitled "DebConf & Debian", discussing about the similarities and differences of Debian and DebConf. At times this became a little bit heated as people wanted more integration and transparency.I don't think the differences are that great. I don't even see them as separate. I see DebConf as a Debian team, one that has to release every year on a short time frame. Things are rushed, things are not perfect, but we welcome anyone who wants to help.It's my goal to start a series of posts on DebConf, in the spirit of other teams documenting themselves and calling for contributors. I hope to let people know what's the current state of things, how you can get involved.If you want to get involved, join #debconf-team on OFTC, or subscribe to the debconf-team mailing list at http://lists.debconf.org/ . There are many people who would like to help you get involved. Right now (post-debconf) is a bit of an idle time, but one of the few times that big changes can be made. DebConf is a do-ocracy, if you'd like there to be a change, the best way is to help implement it. There may be some resistance, but we (at least I) will help to find a solution.These posts are my take on things, I can't claim to speak for the DebConf team. I don't know all of the history of DebConf, and I may get things wrong. I'll run these posts by the rest of the DebConf team for suggestions/corrections, but there may still be things wrong. You should consider anything useful to be thanks to the DebConf team, and anything wrong to be my mistake.I've only been involved in DebConf for two years. I first got involved as part of DebConf10, but spent most of 2009 working on global management things for DebConf9. This year, I spent more time with local on-the-ground tasks. I'd like to keep being involved next year - and hopefully keep improving, with your help.Tags: debconf, debian

When Lars and I started work on Branchable, the Ikiwiki-based wiki and blog hosting service that we first discussed a year ago, and launched two weeks ago, we didn't know what software to use to build it. Probably, we assumed, we'd need a relational database. (Or maybe Couchdb, we wondered?) To manage the sysadmin jobs of keeping a slew of Ikiwiki sites running, we investigated using Puppet or Chef. (We worried that scaling Puppet or Chef to handle an arbitrary number of ikiwiki sites could be a problem.) For the user interface frontend, we assumed we'd be writing code in some kind of web application framework. Nearly all of that conventional wisdom turned out to be false. Instead, all the frontend code for Branchable runs as part of Ikiwiki. www.branchable.com is just another Branchable site, though one with some custom plugins that can make other sites and display a user's control panel. Other plugins handle things like the DNS setup interface. Those plugins are part of the first public site hosted on Branchable, ikiwiki-hosting.branchable.com. That wiki's git repository holds all the code, as well as the wiki for documentation and bug tracking. Also included in ikiwiki-hosting are some backend programs, like ikisite, which handles the high-level site management (creation, deletion, branching, etc), and is what we used instead of Chef. (Though we may use Chef for server deployment later.) Rather than use a relational database, we did out own little noSQL thing, by using a special, locked-down wiki as our database. That wiki is so special-purpose that it is not even accessible via the web! But it's managed by Branchable just like any other site. Deciding to not use a database was a watershed moment, because at that point we were fully dogfooding everything for Branchable. It's worked out well so far, possibly because our database needs are minimal. We have over a dozen other Ikiwiki sites in Branchable that we use either internally, or for other special purposes. Like this parked site that is branched every day to refresh sandbox.branchable.com. So, no database, no Puppet, lots of dogfooding. Did we use a web app framework? Not really. The closest we came is when developing Branchable highlighted that Ikiwiki needed a more user-friendly openid login interface, so I went off and adapted one, and of course added it into Ikiwiki proper. And that uses the JQuery framework. (I might write sometime about all the other Ikiwiki improvements that Branchable spurred.) We've done a lot of eating our own dogfood at Branchable, but I think it's all been pragmatic, not due to Not Invented Here syndrome. And the result is that Branchable is increasingly flexible in what its sites can do, and runs on a very simple architecture, with no odd special-cases for database servers, etc. It's just a bunch of Ikiwiki sites that work together.

This LWN article is perhaps a bit confused, but it does point out a truth: On modern hardware, with fast, local storage, and large, often static files, rsync is often unncessarily slow. That's probably true to some extent when using rsync across a LAN, but it's especially true when using it to copy files locally. rsync runs as a client/server pair, and both processes MD5 checksum the files as they are being transferred. That's nice, but it's slow too. Funny thing about rsync is that probably 50% of uses of it don't involve the core feature that it was written to provide: Updating files by transferring differences. Which, other than ensuring data validity, is the only reason it needs slow checksums. Instead, rsync is often chosen because of all the other awesome features that were glommed onto it over the past several decades. Compared with rsync, cp is pretty laughable -- it can't even exclude files from being copied by patterns. And unlike rsync, cp command lines are not often developed by repeated trial and error -- cp does not recover well from being ctrl-c'd in the middle, while rsync does. These kinds of things make a lot of us reach for rsync first, even if the situation does not involve incremental file changes. In most any situation, one of rsync's 120-some options is sure to be just what you need... So lots of scripts use rsync to synchronise directories, but the amount of speedup obtained by using the rsync algorithm is often low. (Correction: rsync turns off the delta-transfer algorythm by default for local to local transfers. It still does md5 checksums however.) Since rsync is reasonably fast, we generally don't care that it does these checksums that probably on average slow it down. But if larger files, like videos, are involved, this starts to change.. When rsync is run on a typical home NAS, with a slow (arm) CPU, the picture changes entirely -- now the checksum overhead is unbearable, while the IO overhead is minimal. So, here's local-rsync. It takes all the same options as rsync, with the caveat that SOURCE and DEST must be the first two options, and must be local directories.

% local-rsync huge/ /media/usb/huge/ -a -v --exclude '*~' --delete --max-delete=100

It speeds up rsync in these types of situations, by querying it to find what files need to be updated, and updating them the brute force way, with cp. At the end, rsync is run, to take care of the non-brute force stuff (like deletions and file permissions). On a fast CPU, local-rsync will probably speed up rsync of large, static files by a factor of 2. On a slow CPU, local-rsync is so fast, and rsync so slow, that I have not bothered to benchmark. :) This is just a hack (easily replaced by a --no-checksum option in rsync, of course). But I think it illustrates some interesting things about how a program's underlying assumptions about its environment can change over time, and how free software programs can accrete value until the original differentiating reason for their existence is not the most important thing about them anymore.

Linux People and Voting Chris Samuel (a member of LUV who s known for his work on high performance computers and the vacation program) has described why he s voting for the Greens [1]. His main reasons are the Greens strong support of human rights and for science-based policy. Paul Dwerryhouse (a member of the Australian Linux community who s currently travelling around the world and who has made contributions to a range of Linux projects including SE Linux) has described his thoughts about the Filter Conroy campaign [2]. He gives a list of some of the high profile awful candidates who could possibly win a seat and therefore deserve a lower position in the preferences than Conroy. SAGE-AU and Voting for the Internet There has been some discussion by members of the System Administrators Guild of Australia (SAGE-AU) [3] about issues related to the election. As you would expect there was no consensus on which party was best. But there was a general agreement that the Greens are the only significant party to strongly support the NBN (National Broadband Network fiber to the home in cities and fast wireless in rural areas) and to also strongly oppose censoring the Internet. SAGE-AU has an official position opposing Internet filtering, and while the organisation hasn t taken a position on the NBN it seems that the majority of members are in favor of it (I am in a small minority that doesn t like the NBN). So it seems that political desires of the SAGE-AU members (and probably most people who care about the Internet in Australia) are best represented by the Greens. Note that SAGE-AU has no official policy on this, the above paragraph is based on discussions I ve had on mailing lists and in private mail with a number of SAGE-AU members. Also note that not all the SAGE-AU members who agree that the Greens advocate their positions on Internet issues plan to vote for them. The Green support for the NBN is based on the importance of the Internet to all aspects of modern life, the social justice benefit of providing decent net access for everyone (particularly people in rural areas) is very important to the Greens. I still oppose the NBN and believe that it would be better to just provide better ADSL in all suburbs, better net access (through whichever technology works best) in rural areas, and fiber to the central business areas. But the NBN isn t really that important to me, human rights and a science based policy are much more important and are the reasons why I ve been supporting and voting for the Greens. No Wasted Votes One thing to note is that the Australian electoral system is designed to avoid wasted votes. There are two ways of considering a vote to be wasted in Australia, one is if you live in an electorate where both the upper and lower house elections have an almost certain result such that no expected swing can change the outcome I doubt that this is possible for any region in Australia given the way the upper house elections work, although a large portion of the lower house seats have a result that is almost certain. The other way of having a wasted vote is to vote for someone who doesn t actually represent you. Lots of people mindlessly vote for a party that seems to represent them, either they identify with unions and vote Labor every time, they regard themselves as conservative and vote Liberal every time, or they live in a rural area and vote National every time. The Labor and Liberal parties don t differ much in policies and members in safe seats typically don t do anything for the people who elected them. If you generally support the policies of one of the major parties then it can be a good tactic to give your first preference to a minor party. For example if you tend towards Labor then vote Greens first and preference Labor over Liberal. The result will be that your vote will count towards Labor in the lower house and it sends a message to Labor and prevents them from being complacent. Before Australian elections there is always some propaganda going around about wasted votes, this is usually part of a deliberate campaign to try and prevent people from voting for smaller parties. Because the news has many mentions of wasted votes in US elections (which are watched closely in Australia) it seems that some Australians don t realise that there are significant and fundamental differences between the political systems in Australia and the US. Volunteering Last time I checked the Greens were still accepting volunteers to hand out how to vote cards, so if you want to do more for the Greens than just vote for them then this is one way to do it. If you want an uncensored Internet with freedom of speech and a lot of investment in infrastructure (as well as good support for all human rights) then you really want to help the Greens win more seats at the election on Saturday.

• [1] http://www.csamuel.org/2010/08/17/why-im-voting-green-on-saturday-21st-august
• [2] http://weblog.leapster.org/archives/163-Why-Victorians-should-not-put-Senator-Conroy-last.html
• [3] http://www.sage-au.org.au/

Since I didn t actually come home from Debconf, but instead took a further week s holiday and lazed around by the beach, I haven t sat down to write anything about it yet. Most importantly, I should say thank you to Joey Hess, Steve McIntyre and Stefano Zacchiroli for arranging the Debconf Newbies programme, without which I would have been stuck at work watching the videos again (though this does have the advantage of seeing three talks at once). Every year I am astounded at the generosity of certain companies who sponsor the conference, since I ve experienced for myself the difficulty of trying to put a corporate price on free software even more so to specifically sponsor newbies, who by definition probably aren t as active in ways that interest sponsors than more established developers. Right up to the day I flew I was nervous (as in any social situation) at meeting so many new people in one go, on my own, and long way from home after all, it s not really easy to back out and go home after that But in fact, everybody I met was warm and friendly, and very supportive in all sorts of ways. I got to see and hear many talks; in the first two days alone:

• Supporting Debian machines for friends and family
• Debian at a large Dutch university
• Why is GNU/Linux Like a Player Piano?
• Bits from the DPL
• Packaging Python modules and applications
• The Unity desktop environment
• Collaboration between Debian and Ubuntu

And of course social events, like Cheese and Wine, Keysigning (handy for putting faces to names), many nights in the third hacklab, a day trip to Coney Island, a privileged viewing of the most nerdy organ in the world, and a trip up the Empire State building: The campus was ideally suited to such a conference, and apart from the mugginess we had excellent weather. I discovered that I rather enjoy watching baseball and that one should repeat the application of sunblock after paddling. But what I enjoyed most of all was being in the same area as so many eminent Debian people, and being so inspired by them to be even more involved technically and socially. I hope to see you all again soon!
<script type="text/javascript"> var flattr_wp_ver = '0.9.11'; var flattr_uid = '32970'; var flattr_url = 'http://www.jwiltshire.org.uk/content'; var flattr_lng = 'en_GB'; var flattr_cat = 'text'; var flattr_tag = 'blog,wordpress,rss,feed'; var flattr_btn = 'large'; var flattr_tle = 'jwiltshire.org.uk'; var flattr_dsc = 'The public face of jwiltshire'; </script> <script src="http://api.flattr.com/button/load.js?v=0.2" type="text/javascript"></script>

This Monday, Debian celebrated its 17th birthday. Yay! I was invited to celebrate the birthday at HacklabZAM, but could not make it due to the time (17:00-19:00, and I was just leaving work by 19:00), but still, had some beers with long-time geekish friends Iv n Chavero, Rolando Cedillo, Manuel Rabade and Od n Mojica. Nice hanging around, good beer+pizza time, and explicit congratulations to Debian. On the Debian front, Margarita Manterola, Maximiliano Curia, Valessio Brito and Raphael Geissert came up with a very fun Debian appreciation day page. It even included a (slight) hijacking of the bug tracking system's Web interface, showing happy fun balloons! Guys, thanks for a good laugh, and thanks for providing a vehicle for getting the users' thanks to the project! All in all, that was a great reminder to what we have been repeating as a mantram throughout the last years: Lets keep Debian fun!

A while ago I was with my SO at a concert of a band I might cover at a later point. This time I want to cover the support act of that concert: Jerboa. It was a bit weird to see a single person on stage turning some knobs, but he quickly caught both our attention and heart. And he was a charm to talk with afterwards when we bought his CD. He's definitely worth your attention, and if you are able to see him live take the chance for it.

• Number 1: The obvious number 1 song in the list. Perfect groovy song, great video too.
• Running North (remix): Also interesting output of his creativity.
• Just Another Number: It starts off pretty smooth but then really kicks in. Hard to not headnick along to the song, it is far away from being Just Another Number.

Actually I would have loved to include What if in the songs but unfortunately that one wasn't available so I had to look for a replacement for it. Enjoy!

/music permanent link Comments: 2

An old house, theoretically empty, but still filled with the cruft of its history. Here an old classroom-style pencil sharpener mounted on a wall. In a kitchen cabinet, a plastic bag of dried fish of unknown provenance. Old books. Somewhere, a moldering, out of tune piano. How does this make you feel? Maybe depressed, or urgently needing to wipe it all clean and repaint? Myself, as long as the previous inhabitants are people whose heads I don't mind getting into, I like this environment. I will carve out my own part of it, clean and reorganise that, but generally leave the rest as-is.

---

It's weird that, if we were talking not about houses, but software, I'd probably bulldoze it down, compost it, grow trees from it, and start over.

---

This house has the added complication of a solar power system that has accreted broken parts and workarounds over the years. So far I don't understand the original design, let alone what it developed into! I'm spending a few days here now just to try to learn how it behaves -- how long can I run my laptop and forgetfully leave lights on before the battery bank reaches unsafe levels? Am I even measuring the level of the right battery bank? (Why does this incoming solar power display still read 21, in the middle of the night?) I haven't been in this situation since spring of 2001. And then I only had to contend with no running water, and dialup. Now I also have to deal with limited power. Interesting times.

After reading Do It Tomorrow, I was inspired to try some of the techniques that Mark Forster proposes. I commented in the review about the closed list system, which I'm still mostly using with some success. But I also started playing with the initiative slot. In his system, the initiative slot is first thing in the morning each (eligible) morning, which is used for a special project that you want to make forward progress on. There are several criteria for choosing a task for the initiative slot. One of the strongest is dealing with a backlog. Since I'd been feeling guilty about the backlog of Debian Policy work that had built up, that seemed like a good choice. I picked up Debian Policy backlog clearing as my initiative starting at the beginning of June after the AFS and Kerberos Best Practices Workshop, with a goal of getting the open bug count below 100. This has been very instructive, both from a time management perspective and from a Debian Policy perspective. Here are a few things that I learned on the Policy side:

• The open bugs against Debian Policy by and large represent real work that we should tackle in the Policy document. They're not all fully thought-out proposals, but I didn't find much that I could simply close (apart from a set of bugs requesting additional common-licenses, once I had an analysis tool). From time to time, we've thought about timing out old bugs that have not made any forward progress, but this experience leads me to think that would serve us poorly.
• It takes me about an hour on average to resolve a Policy bug. That includes all the fast five-minute typo bugs (well, ten minutes; I need to improve my Policy workflow to be a bit more efficient in the commit process). Some bugs take easily ten hours or more, such as #504880. I think this is on par with or a bit slower than resolving typical bugs in compiled software I package, and much slower than Lintian, where bugs take about a half-hour on average to resolve, I think.
• Most Policy bugs are making no forward progress because no one has written wording and started iterating on that wording. There are some exceptions, and this process seems to go better for me than it has for some other contributors, but if I pick up a bug and start drafting wording changes, I can usually bring the bug to resolution in about a week, often less. This implies to me that our process for making Policy changes is reasonable but we need more targetted help. This was discussed at the BoF at DebConf and on the list afterwards and I now have three people who have volunteered to supply some of that targetted help and need to get more organized to make use of that offer.
• The normative (rule-affecting) versus informative (informational and documentary) distinction in Policy is tricky and unclear, and most bugs end up becoming normative. While I think our system for dealing with normative bugs is reasonable, this does slow down fixes. I can commit informative changes without review and then tweak them if people object, and it would be nice to fix more wording issues that way, but it's hard to avoid getting tangled up in normative issues.

Things I learned on the time management side:

• I didn't work from a closed list, which is frowned on for dealing with backlogs. I'm not sure if this ended up being a problem or not. The correct approach, in theory, is to work out a system for dealing with new incoming work, make sure that system is in place, and then process backlog independently of all new work. I never did that. I never separated out the backlog into a closed list that would get smaller. I suspect I should have, although I'm not sure of a good way to do that in the BTS in an area where we're already using usertags for another purpose.
• The point of the initiative slot is to unblock something or to clear a backlog, but the initiative slot is supposed to rotate. It's not a good way to deal with something that's going to take a long time to resolve. In retrospect, I was excessively ambitious with my goal. Even apart from not working from a closed list, I can average about a half-hour a day on the initiative slot, which at an hour a bug and a starting point of 160 bugs would mean 120 days to reach my goal. That's too long for one task to dominate the initiative slot.
• The initiative slot really works. We brought the bug count on Policy down from about 160 to 126 over the course of those two months, and I don't think much changed other than my level of activity and of course the normal effect of other people getting more involved when someone is visibly doing work. The bug graph is impressive. It's very obvious when I started working, and also very obvious when the ramp-up to DebConf started and I stopped having time to have a daily initiative slot.
• Doing something that's unrelated to my day job in the initiative slot creates an odd tension, and I'm not sure how to deal with that. On one hand, one of my standard time management failure modes is to spend too much time on work and not enough time on non-work tasks. On the other hand, that's partly because I'm hypersensitive to not focusing enough on work and overcompensate, and taking time each morning to do non-work things doesn't help that. I'm not yet sure what to do about this.
• One of the failure modes of initiative slots that I'm already noticing is that when I move something out of that slot, rather than continuing to work on it at a normal pace, I have a tendency to stop working on it altogether. This doesn't work, particularly if it was used for backlog clearing. I just build up another backlog and then have to use the slot to clear it again. This means I need to give more attention to my time management outside of that slot.

I stopped using the initiative slot while travelling and haven't gotten back into the hang of regular time management since I've gotten back. I haven't yet decided whether to leave Policy work in the initiative slot for right now but change the goal, or whether to swap it out for something else. I'd like to keep momentum, but I'd also like to start using that slot for other things. Still pondering.

I found the notes from Rob Weir on how to crush dissent matching my own thoughts on the matter quite well. Highly recommended for those wondering which road our society should go down. In my view we have been heading the wrong way for a long time.

Git-buildpackage 0.5.6 in experimental got rid of it's pbuilder/cowbuilder examples and added Russ's nice git-pbuilder script. I'm very happy how this turned out, now building with cowbuilder is as simple as:

# Initially create a cowbuilder environment once
git-pbuilder create
# Build the package
git-buildpackage --git-pbuilder
# At a later point update the cowbuilder environment with new versions
git-pbuilder update

Or for another distribution:

DIST=lenny git-pbuilder create 
git-buildpackage --git-pbuilder --git-dist=lenny

The new version also better interacts with dch from devscripts. So things like:

git-dch --bpo --qa --nmu

are now also supported when adding new changelog sections. Git-dch now detects new upstream version numbers automatically and bumps the version accordingly. In order to get this working I finally fixed the tag format. Since the current version in unstable should get a chance to move to testing first, I've uploaded 0.5.6 to experimental.

Here are some notes I took about the lecture Debbugs New developments in the ongoing struggle against bugs by Don Armstrong at Debconf 10 (that I watched from the stream). Note that the slides are at : http://rzlab.ucr.edu/debian/debbugs_presentation_debconf10.pdf, and here, I ll only mention most noteworthy elements I ve noticed. There s a linear growth of number of bugs reported for several years, from the statistics made by Don. In average, there s same number of bugs filed / archived per day : Debian s not losing ground against bugs A new affect command has been added, for bugs present in a package affecting another package. The summary command which can be used to quickly spot the summary of lengthy discussions deserves more love. Included summary -1 to send a new summary by email. The new local-debbugs package : can mirror your bugs locally and allow to search, show, etc. even offline. Lots of ideas for new features still in development (but lacking manpower). Interesting idea about action required sorting which exhibits different interests for triager, maintainer, user, to maximize productivity. I guess this should be implemented in clients of the BTS also. Interesting ideas about distributed bug tracking : sharing status with other bugtrackers (see other report), sideways syncing with other distributions, and making it available to upstream also. Note this was discussed in a subsequent BoF, which I ve already blogged about. Some elements taken from the Q&A :

• To my question about addition of RDfa, not currently on the TODO list I guess I ll have to do it myself ? Need to provide more convincing hints on the usefulness.
• only 3 status in the BTS : Fixed / Found / Absent
• some other projects are using debbugs

Overall, a very interesting presentation. Well worth watching the video recording. See also my report on the presentation by Christine Spang on Distributing bugtracking for Debian with SD which also discussed some debbugs things.

This blog post is actually a response to a talk that was given at the debconf last week. It was marga's talk about Making Debian Rule, again. Now that the beta versions of the talks are available for download I'm able to proper quote what I want to respond to: Is there a reason why we haven't yet updated the website?, perhaps someone can answer. I feel the need to respond to this as I am the main person driving that effort. Unfortunately the question was asked in a talk with no-one involved in that work around instead of addressing those people directly, and the question wasn't brought to my attention before the talk so that I could have provided an answer to offer in the presentation already. Also, as disclaimer, this is my personal story for it and doesn't need to get shared by the other people involved. I hope it can be seen as an answer anyway. As a little of background, Kalle's proposal went a long path before even I found out about it. I was simply in awe in several ways about it because it wasn't just a great mockup of the page (which it actually is, IMHO) but was accompanied by thoughts about not only the main site but also about several sub sites. Also, it was accompanied by patches, so it was seemingly ready to get deployed right ahead. I started working on it, got accused of being discouraging while doing that, got told that it would require a proper vote for a decision and can't happen just as, but those are just the Debian way of communication. I nevertheless did set up several test sites for some over the time to play with it. Some did work out better (like the git one, though this one came last and Kalle improved the CSS over time a fair bit), some weren't ready yet (like wiki, missing e.g. the coloring for the version diff, or the packages one where the separation between the different sections isn't that visible yet). Time passed, other things demanded their attention too. Like the thing where our system administrators did send me a request along about a new www-master server that needs to get set up from scratch. Given that the documentation about the required packages for the website was lacking a fair bit (to say the least) it did require a lot of attention, especially when doing things from scratch the wish to document the dependencies properly is just natural. There are still some issues with that as can e.g. be seen on this page in the empty table at the bottom. The same issue also appears on my testsite for the new design. The last part though is currently the biggest blocking issue for both efforts. There is no way to move forward with either without having that addressed. Simon Paillard did a great job on helping the move along so far, keeping the thread about the server move requirements that I started on the debian-www mailinglist updated with information about what's still pending. Unfortunately Kalle, Simon and me are also facing some private time constraints (amongst other duties that require attention) which weren't helping to move forward at a bigger pace. Unfortunately not very many people actually has shown interest in helping out neither, after all it's easier to go and ask questions about why it's not done yet to the completely wrong audience. My plan is to switch many sites at the same time instead of one after the other simply for the effect but also for less distraction for our users, including less people repeatedly pestering about when this or that site gets done, too. At least we need a final discussion on what should go into the header links and what should be at the bottom before a switch can be made anyway. And for some there is still the opinion that such a switch is nothing that we are rightfully allowed to decide without a vote, so that's also part of the reason to not just deploy it. I hope this answers the question to some extend and like said, if only I would had been addressed about this before the talk was given an answer to it would had been ready for presentation right ahead instead of having a pretty terse statement getting relayed through IRC (thanks, Yoe!) because I was fortunate enough to be around and watching the talk at that time. Feel free to discuss it further or offer your help on debian-www, especially if you are familiar with working on CSS files.

/debian permanent link Comments: 3

I was in New York for three full weeks, before, during and after DebConf 10 took place. Unfortunately, I wasn't able to attend talks or go hang out with folks as much as I would've wanted. Most of the time I was busy at the office with a new product launch we have been preparing for the last few months. However, I was able to come and say hi to a few people, attend the C&W party and talk with friends and ran into. I was, however, following all conversations on IRC so I was pretty informed of all of what was going on. Some random thoughts:

• Being surrounded by so many amazing Debian people made me realize how much I've been apart from the project. My involvement decreased pretty much since I moved to New York. But because of that, I'm now slowly retaking my activity, trying to work on actual things that I use on my daily work instead of just packaging tons of shit that nobody really cared about.
• DebConf is pretty awesome. After attending six out of the last seven Debian conferences, you get to establish a nice connection with people and they become your friends. This year, even if I only came a couple of nights, I made stronger friendships, and for that I'm thankful. It is only within Debian that this human part of bonding really takes place.
• I really regret missing a couple of events: First, the Day trip to Coney Island and the Cyclones game; and the group photo. Both because of work, yes.
• It was interesting to hear the thoughts from one of the Bosnian attendees about next year's DebConf there. I'm really sorry I can't recall his name, but it shocked a bit that he stated that they might try to find better speakers next year, because a lot of them "sucked a lot" here. All I can say is that, even though everybody's opinions are valid, this might come from an outsider, not used to Debian conferences. Where are you going to find better speakers? Us developers are the only speakers out there, good or bad, we are the ones making the conferences by and for.
• I like Zach's attitude as DPL, even when I introduced him to a very nice friend of mine that came to the party to hang out.

DebConf 10 rocked and I appreciate everybody's participation in it. See you in Banja Luka, next year!

As far as I recall the standard for naming Linux Ethernet devices has always been ethX where X is a number starting at 0. Until fairly recently the interface names were based on the order that device drivers were loaded or the order in which the PCI bus was scanned. This meant that after hardware changes (replacing network cards or changing the BIOS settings related to the PCI bus) it was often necessary to replace Ethernet cables or change the Linux network configuration to match the renumbering. It was also possible for a hardware failure to cause an Ethernet card to fail to be recognised on boot and thus change the numbers of all the others! In recent times udev has managed the interface naming. In Debian the file /etc/udev/rules.d/70-persistent-net.rules can be edited to change the names of interfaces, so no matter the scanning order as long as an interface retains it s MAC address it will get the correct name or at least the name it initially had. One of the down-sides to the way this operates is that if you remove an old Ethernet card and replace it with a new one then you might find that eth1 is your first interface and there is no eth0 on the system this is annoying for many humans but computers work quite well with that type of configuration. I ve just renamed the interfaces on one of my routers by editing the /etc/udev/rules.d/70-persistent-net.rules file and rebooting (really we should have a utility like /sbin/ip with the ability to change this on a running system). I have decided to name the Ethernet port on the motherboard mb0. The PCI slots are named A, B, and C with A being the bottom one and when there are two ports on a PCI card the one closest to the left side of the system (when viewed from the front the right side when viewed from the read) is port 0 on that card. So I have interfaces pcia0, pcia1, pcib0, pcib1, and pcic0. Now when I see a kernel message about the link going down on one of my ports I won t have to wonder which port has the interface name eth4. I did idly consider naming the Ethernet devices after their service, in which case I could have given names such as adsl and voip (appending a digit is not required). Also as the names which are permitted are reasonably long I could have used names such as mb0-adsl, although a hyphen character might cause problems with some of the various utilities and boot scripts I haven t tested out which characters other than letters and digits work. I may use interface names such as adsl for systems that run at client sites, if a client phoned me to report Internet problems and messages on the console saying things like adsl NIC Link is Down then my process of diagnosing the problem would become a lot easier! Does anyone else have any good ideas for how to rename interfaces to make things easier to manage? I have filed Debian bug report #592607 against ppp requesting that it support renaming interfaces. I have also filed Debian bug report #592608 against my Portslave package requesting that provide such support although it may be impossible for me to fix the bug against Portslave without fixing pppd first (I haven t looked at the pppd code in question for a while). Thanks to Rusty for suggesting this feature during the Q/A part of my talk about Portslave for the Debian mini-conf in LCA 2002 [1].

• [1] http://www.linux.org.au/conf/2002/debiancon.html

(This blog has slept since I wrote the previous post. That post had to wait for a year to be made public! Anyway, here I go again ) One of the ways people characterise science and technology is by saying that science is about prediction and technology is about design. This is not wrong but I feel that it misses something. An astrologer too claims to predict the future and claims to tell you how to re-design your future. So the above explanation of science and technology could make it indistinguishable from magic! One thing that does distinguish science is that the prediction and design is done by calculation ; this is not restricted to mathematical calculation but includes recipes like mix so much of this reagent with so much of that solvent . In fact, the notion of calculation can be expanded to anything that I can teach someone else to do even an idiot like a computer. This leads us to the view that science is not only about making predictions and designing things but also about teaching others to do the same. At the very first level, this is done by providing formulas which other people can use to make predictions and design things. However, this is not quite far enough, since it would still make the act of creating these formulas a magical thing! So we must take this a step further and be able to teach others how to create their own formulas. In other words, we want to provide formulas for creating new formulas. It does look as if we could be in infinite regression here, for who will then create formulas to provide formulas for creating new formulas! Luckily, the monadic thinking of Turing helps us here. He realised that formulas for creating new formuals are themselves just (slightly more complicated) formulas. Just as a gift-wrapped box containing a gift can be thought of as just a box containing a gift.

What do you do when you have a technical question that you're embarrassed to ask? The first Sunday of Debconf, I led a birds of a feather (BoF) session called Debian for Shy People. The conference team scheduled it on "Debian Day," a pre-conference day that was open to the public and still had plenty of Debian Developers in attendance. I just uploaded the slides to the "Penta" page for the talk. I led it because of my own experience. In 2004 or so, I saw Debian as the cool kids' club, that awesome project that I wished I could be a part of. By 2006, I managed to get over myself, read the New Maintainer's Guide, and find a way to get involved. As of mid 2009, I am a full-blown Debian Developer. I have real ultimate power. But I sometimes do still feel hesitation akin to "Imposter Syndrome". (A bunch of people at Debconf didn't really believe I'm "shy," since I asked a lot of questions at the conference. At core, I don't naturally believe that the things I say are worth hearing, but I patch over this hesitation. Sometimes I speak too much, and then I feel ashamed of burdening everyone. But anyway, this is about Debconf not, me -- so moving on....) In the past year of being a Developer, one thing I've seen is that other contributors ask me privately for help. Rather than blast the public lists like debian-mentors, they email or IRC private-message me, or SMS me, or find me at a Linux Users Group event. I'm lucky to know these people, and they're lucky to have me as a safe person to ask questions of. Moreover, Debian is better because these people could move past their confusion to make a technical contribution. I began the BoF session by talking about when someone asked me for help. Then I asked, "How many of you have someone you can ask embarrassing questions of?" Of the forty people crammed into Schapiro 414, two people' raised their hands. One person put it plainly, "I don't know anyone else who does Debian." It reminded me of a fact that Karen discovered when she was doing market research for us at OpenHatch: the vast majority of free software programmers know zero other people who do free software. I had seen the figure; we even used it in a talk to try and convince venture capitalists to fund OpenHatch last year. But I didn't really feel it until I heard it from a room full of Debian contributors. I structured the BoF in two parts: First, I talked in front of some slides to set the tone properly, and then we enjoyed open discussion. As I was preparing thoes slides, Daniel Morais asked me, "What's the point of having the session? Why not just come up with some ideas, implement them, and not bother also talking about it at the conference?" I had considered this; I decided I wasn't self-confident enough to start implementing ideas without talking to people to make sure I wasn't the only one who saw a problem. But I discovered another benefit of giving the talk: people who want to make Debian more welcoming knew to reach out to me. So here are some thoughts that came from our discussion (and later discussions during the conference):

• We need better mentorship in Debian. Truly, mentorship is a personal relationship. Perhaps matching people up into one-on-one groups would be a good idea. KiBi said that doing so using OpenHatch (if we add mentorship-oriented features!) would be a reasonable way to do it.
• I've heard from quite a few people who would be willing to have more one-on-one relationships with mentees.
• Everyone (except Manoj) knows that Debian contributors are not born experts. It takes a process of learning and teaching to bring them up to speed.

I set up an Etherpad document on cjb's OpenEtherpad.org. This is what we learned together:

• "If your level of understanding might be low, but you want development help, then you might not know if #debian-devel is only for people who are already super involved and know everything and therefore you should feel embarrassed."
• People get anxious over their ability to speak English.
• Bikeshedding over patches can be a major detractor.
• "Asheesh talks too fast."

One idea I had before the BoF was to create a discussion area that was safe for all questions, even if they seem silly. We talked for a while about what name that would take, if it were to become a new IRC channel. We reached something of a conclusion, but in the conference that followed Emmet Hickory offered to help make the debian-mentors IRC channel friendlyer. I think that's the best direction to take things, so the next step is for him and me to write up what we want and send a note to the debian-mentors email list explaining our vision. In the Etherpad document, people discussed the idea of doing Debian discussion over XMPP (also known as Google Talk, also known as Jabber). We weren't sure how such a place would get critical mass; someone briefly mentioned the idea of an IRC/XMPP gateway. I actually think this discussion is along a very reeasonable path, namely discovering what discussion method(s) Debian contributors want to use. (That might explain why I'm now an admin on forums.debian.net.) We also briefly discussed the idea of an anonymous question-answering service. I realize now that I'm not going to be able to have time to run that, but I still think it'd be a really cool idea. Biella would remind me that Debian is already successful at bringing in new contributors. I agree! As a free software project, we have an enormous number of participants. This is a really good thing, and we're clearly doing something right. The purpose of this talk was to figure out how to make contributing to Debian less stressful for those who participate. Truly, a "Debian for Shy People" effort isn't about shy people. It's about the moments of self-doubt we all have in which we don't know what to do and are too embarrassed to ask. I think that if the project more friendly, we can find more participants, make better use of our current ones, and see improvements to our diversity. Whew, that was long. What do you think of all this?

Remember when I said Epiphany worked out of the box with Youtube s WebM? Well, Google has recently decided to deny us WebM, like it did before with Wave, the Pacman doodle, and who knows what else? \o/ Wouldn t it be nice if Google practiced what they preach? Update: so it looks like my message went through to the people who needed to see it, and they found a filtering error in the User Agent sniffing code that made it think Epiphany was a too old Safari - I m told the change will land in Youtube soon, thanks for those paying attention, and working on this! User Agent sniffing keeps being a problem, of course, and there are other stuff to fix, so I will probably still push my patch to spoof the user agent to google services which are still mishandling Epiphany, but it s good to see some progress being made! Update2: I started shipping a patch to send the Chrome user agent string to google domains in the Debian package for WebKitGTK+, when the enable-site-specific-quirks setting is enabled (which is the case for Epiphany); I already found something we were missing out on =D Google Images seems to have been greatly improved, and now faking being Chrome we are also able to enjoy it:

I know I have not updated this blog in quite a long time now, but something caught my attention today: canonical-census.

As slashdot.org reports Canonical begins with tracking their (OEM) installations. Now it's obvious that people are uncomfortable with a program running on their system which phones back to their OS vendor, that's why I have had a quick look at what exactly canonical-census does.

Firstly however, I would like to point out that the report on slashdot.org is very clear about which information is being gathered, being "the number of times this system previously sent to Canonical [...], the Ubuntu distributor channel, the product name as acquired by the system's DMI information, and which Ubuntu release is being used". And it's perfectly correct. After getting the canonical-census Debian source package (using dget -u https://launchpad.net/ubuntu/+archive/partner/+files/canonical-census_0.1.dsc) the source package shows, besides the Debian packaging information, two scripts:

• census (written in Python) and
• send-census (a GNU bash script).

3 interesting small things happened in the weekend. Due to the hard work of mostly Florian Reinhard and George Kiagiadakis, Bluedevil is now available. Bluedevil is a new and improved bluetooth handling thing targetted the KDE Workspaces. The Debconf people have uploaded the Qt Debconf frontend that I blogged about a while ago, so now it should be available. Last, but not least, applications now has more accurate data for if they are online or not, by using the ntrack library. This was especially problematic for people having some interfaces defined in /etc/network/interfaces, and other interfaces managed by NetworkManager.
This feature will be committed to upstream KDE whenever Will gets around to do it. As a added bonus, KDEBindings in Debian has seen a release critical bugfix (python plugins, e.g. plasma widgets, related), and the brokenness of Konsole (libkpty) on the kFreeBSD-arches have been tracked down to a libc issue and a patch has been made. All of this is expected to be part of next stable Debian release, codename Squeeze.