(This has ended up longer than I intended, largely because I felt I should then get into why. I'm aware I haven't got into all the nuances, so I hope readers familiar with the area will appreciate this is the compact version.)

Thorsten had a rant last week about PGP keysigning problems. He apologises for his tone, but that's not the issue I take with his rant.

It starts "Keysigning is useless". And yet his complaints seem to be:

• Dealing with the private half of your GPG key securely involves some faff (in this case booting with a live CD and having to set things up ready to keysign).
• He doesn't get on with caff.
• People reject email from machines with invalid HELOs and perform other anti spam measures on ISP access ranges (I'm not clear if it's just greylisting or outright rejects as that's not made clear).
• PGP/MIME is a protocol violation (yes, but it's much better than inline OpenPGP. Unless you have to deal with RT, which mangles it. *sigh*)

None of these seem to actually be about keysigning being useless. The process of doing it, maybe, though he misses the main valid rant about this I'd have, which is that most mass keysignings don't actually allow you to accurately verify the identity of other participants unless you already know them reasonably well. (The LCA2010 keysigning and DebConf5 in Helsinki spring to mind as 2 good examples of bad keysignings I've attended, but speaking to others suggests it's far from an isolated thing.)

Torsten does say that he'll continue to do keysigning on a per-person basis, so it doesn't sound like he's completely given up. I'm posting this largely so other Debian related people don't get the idea that it's not important to think about keysigning.

Why should we care?

Firstly, let's clarify what I mean when I sign someone else's key. If I sign your key then I think that I believe you hold the private part of a key that has your name and an email address I believe I can use to contact you on it. It means I have seen government issued ID that matches that name. It also means that I have interacted with you (and watched others interact with you) under that persona. In short I am happy that the key is a reasonable digital representation of your identity - something signed by it either comes from you or has involved the key being compromised or you coerced into using it against your will.

Why is this useful?

It gets useful thanks to the web of trust; ie the idea that there are a bunch of people I trust partially to sign other keys, and if enough of them have signed a key then I can have a reasonable expectation that the key belongs to the person I want to talk to. Which means I might be prepared to send private data to them. Or Debian might be prepared to accept an upload from them. Which, when you're dealing with a community that spans the planet and where most of the contributors haven't met each other, is pretty freakin' useful - I, as part of Debian's keyring team, don't need to personally be able to identify every Debian developer. All I need to do is be able to trust other DDs to be able to do so. (Though maybe I'm missing out on something here - perhaps Debian should be paying for Gunnar and me to travel the world verifying fingerprints. \o/)

(I still do mass keysignings btw. I'm picky about which keys I actually sign - this is in no way intended as a slight against those I don't, but a mass keysigning at least lets me know that the people involved are happy to exchange fingerprints. Though, FWIW, I normally have ID on me and frequently have fingerprint slips, so if you know me and want me to sign your key/want to sign mine then by all means ask me when you see me!)

Or should I say *we* are going to Debconf 10? Last week-end, I booked the whole set of plane tickets for the Perrier family to fly to USA next summer:

• Jean-Baptiste (aka "Habanero" on IRC) and myself will from from Paris Charles de Gaulle on Wednesday July 28th, arriving in NYC after a connection in Dublin (shame that connection flights are much cheaper than direct flights). As I already wrote earlier, I'll attend Debconf with my son, yay!
• Elisabeth, Sophie and Magali will fly the same route on Aug 5th. We'll stay partly separated during the first days: JB and I at Debconf and them doing some sightseeing in NYC.
• On Aug 8th, we'll start ou family holidays: first stay a 1 or 2 more days in NYC, sightseeing together
• Later on, we plan some trip in the NE part of USA: probably something around Boston and New England, wandering around undertermined places in NY and Vermont states, maybe up to Montreal...then back to NYC
• Finally 5-6 days in our family in the Kansas City area
• Then back to Paris, via New York again, on Aug 23rd and 24th

Nice.

I don't know if anyone else has been tracking this recently, but a while back I got curious about the relative proportions of dh(1) and CDBS in the archive, and started running some daily analysis on the Lintian lab. Apologies for my poor graphing abilities, but the graph is here (occasionally updated): Although dh is still a bit behind CDBS, the steady upward trend is quite striking - it looks set to break 20% soon, up from under 13% in September - compared with CDBS which has been sitting within half a percentage point of 25% the whole time. Incidentally, was that an ftpmaster trying to sign his name in the graph over Christmas or something? :-)

Start with the sentence: I'm pleased to present you on this Windows notebook in the Linux forum a talk about FreeBSD... How to not loose their attention Have the Windows notebook you where supplied with install some security updates during your talk, and then be constantly busy clicking the Please reboot popups away... Well, I hope the video was working. I'm really looking forward to see that video.

Today, I arrived at the CeBIT conference in Hannover, and had a first look around. I find trade fairs like that quickly boring, and I was glad to meet some some other Debian folk and listen to some of the talks at the CeBIT Open Source Forum in hall 2, including tolimar s talk about Debian GNU/kFreeBSD. Tomorrow (Wednesday), I will talk at the same place at 13:45, explaining some basic stuff about patches and bug tracker. The target audience are users of Free Software who modify it for their private or company-wide use and would like to see their changes included in the official project. There will be a live stream of the talk, which I am officially holding as an employee of the ITOMIG GmbH.

Nathanael Boehm wrote a nice essay last month called The Future of Employment?, about a disconnect between workers' and employers' views of social networks. (This post is based partly on my comment in the ensuing Hacker News thread.) Boehm wrote:

When I need help with a challenge at work or need to run some ideas past people I don t turn to my co-workers, I look to my network of colleagues beyond the walls of my workplace. Whilst my co-workers might be competent at their job they can t hope to compete with the hundreds of people I have access to through my social networks...

The late Sun Microsystems taught us that the network is the computer. It's true: we still use non-networked computers for specialized tasks, but nobody wants one on their desk it's just so useless compared to one that talks to the entire world. Boehm could have titled his essay The Network is the Employee. There are still tasks that people do in isolation, but the ability to contact a network of peers and experts makes the difference in my job, and many others. Alone together The lone computer programmer in a small business has thousands of colleagues on Stack Overflow, Reddit, and so on. It's a chaotic and messy way to find answers, but it's better than the days when your only choice was to call tech support or smack the box with your fist, whichever seemed more useful. I can't begin to list all the problems I've solved and things I've learned by Googling for others with relevant experiences, and getting help from a different expert for every problem. Decades before the web, computer geeks had virtual communities for on mailing lists, Usenet, and IRC. Now any job in the world has an online forum. Even the night clerk at the gas station has Not Always Right. Teaching has long been a solitary profession. Despite working in a crowded classroom, teachers are isolated; they rarely have colleagues observing or participating directly in their work. This has such an impact that teacher education sometimes includes training in meditation or reflection, to compensate for lack of external feedback. So I'm really curious what happens when teachers start to work together remotely the way programmers do. You will be assimilated Boehm's essay reminded me of a vague sci-fi-like idea I've been kicking around: the first group minds will evolve from the intersection of Mechanical Turk, virtual assistants, social networking, and augmented reality. Starting around the 1990s, it was possible to instantly "know" any fact that was published online. Since then, we've increased the amount of content online, our tools for searching it, and ways of connecting to the network. Today we have instant access to almost any published knowledge, anywhere. The number of people on the net has grown too, and the number of ways to find and talk to them. Most of us can contact dozens of friends at any given moment, plus friends-of-friends, co-workers, fellow members of communites like Hacker News or MetaFilter, and also complete strangers. Along with raw facts, we now have access to vast amounts of human judgement, experience, and skill. One result of this is the "virtual assistant," who provides a service that was once available only to high-powered executives. The new personal assistant can work remotely (often overseas), spread costs by serving many masters, and leverage the internet superpowers listed above. Today their services are targeted at small business owners and the Tim Ferriss crowd, but I'm sure someone soon will start marketing virtual personal assistance to all sorts of other creative workers, teachers, even stay-at-home parents. So, how long before I can simply touch a button to let a remote assistant see what I'm seeing in real-time and help me make transportation plans, translate foreign signs and speech, look up emails related to whatever I'm doing or thinking, or even advise me on what to say? Some of these queries will go to my circle of friends, others to the general public, and some to a personal assistant who is paid well to keep up with my specific needs. And that assistant of course will sub-contract out portions of each job as needed to computer programs, legions of cheap anonymous Turkers, or to his or her own network of assistants. At that point, I'm augmenting my own perception, memory, and judgement with a whole network of brains that I carry around ready to engage with any situation I meet. If nothing else, I hope someone writes a good sci-fi thriller story in which a rogue virtual assistant subtly manipulates the actions of unknowing clients, leading them to some unseen end.

This moment has finally arrived! Last Saturday (27-th) on #debconf-team decision was made, DebConf11 is coming to Bosnia and Herzegovina! Our team and myself were working on this whole candidature for last ~9 months, and even though we put incredibly amounts on energy, hard work, enthusiasm and everything else that goes along with it, suspense and uncertainty were there until the very last minute! One of our local team members (trip0d s) wife almost gave a birth to their child during the decision process that lasted full 4 hours As a remainder we were competing with Ecuador and Germany to win this bid, whole process was excruciating and very emotionally distressful in every possible aspect for every team member; at one point Germany took a slight lead ahead of Bosnian team, while in the end by points Bosnia was in slight lead by 0.25 points, and this is exactly what touched me the most about this whole bid/decision/process. This is not a great advantage or anything for that matter, but what happened is that in decision process Debian debconf team and its developers picked Bosnia and Herzegovina as a place where they want to have DebConf11! Our main competitors from M nchen, Germany showed a real fair play and at the end even yielded to our side; really to both of you, Michael Banck (azeem) and Andreas Barth (aba) it was a pleasure and honor to compete with you guys! See you in NYC for proper handshake and possibly a hug? Also I d like to thank Jimmy Kaplowitz (Hydroxide), Moray Allan (moray) who had chairs and who did absolutely incredible job I guess I ll just have to thank the whole debconf orga team for all their amazing work ( can t name names individually because I ll definitely forget someone!) This bid really reunited whole Bosnia and Herzegovina, this whole process also united all of Balkans and whole of Ex Yugoslavia, which makes me especially happy since today (March 1st) we are celebrating the day we officially separated from Yugoslavia. Now this just one small step forward, since the real work is ahead of us and we re starting it all as soon as tomorrow since there s really a lot that needs to be done. Again thank you all, we ll give our best for this to be a DebConf you ll remember (as a great one of course!), in the meantime see you in New York City! Adnan Hodzic aka AbsintheSyringe team leader on behalf of whole debconf11-team. DebConf11 Banja Luka wiki Debconf11 decision log (#debconf-team log)

Sorry, I didn't had the time to update RC Bug statistics last week, and will probably also not be able this week, as I'll be quite busy, as CeBIT is about to start tomorrow, and I haven't written a script to create the statistics, yet. While we are talking about CeBIT, you might already know, that Debian will again be present there. This as partner of Univention, a German company using Debian as base for its own distribution. I would like to thank them very much for their short hand acceptance of us at their booth. If you intend to visit us (Hall 2, stand B36) and still have not ticket, feel free to drop me an E-Mail. We got some free tickets and I'll try to send you the link (you'll need to register at the CeBIT website and print your ticket yourself).

A while ago, I was asked to recompile Tinyproxy to enable transparent proxying support, which was not being compiled in etch's Debian package. As it tends to happen, once I got the source and looked into doing a quick rebuild with --enable-transparent-proxy, I noticed the package was in such a bad shape, that I couldn't just leave it like that, so I found myself doing a few more changes, which mostly involved updating the packaging so it didn't suck a lot, and splitting the Debian patches so things could be sent upstream or dropped when new versions appeared. However, even if Ed had asked me to go ahead and take over the package, this was meant to be a one-day effort, and soon I had forgotten about Tinyproxy, except for the ocassional bug mail getting through the PTS. It also didn't help that Tinyproxy had been pretty much dead upstream for years. So lately, a few bug reports were reporting a gasp new major Tinyproxy release, after 7 years of basically nothing. OMG, what do I see, there's a Git repo! And an upstream Bugzilla! Somehow, feeling I owed Ed a reply to his unanswered request, I went ahead and tagged tinyproxy 1.6.3-3.2 in collab-maint, and started working on the new version. Adding myself to Uploaders, and getting rid of the make no unnecessary changes vetto, I rewrote most of the packaging. And for a change, I looked for and found a #tinyproxy channel on IRC and told muks and obnox that the days of Tinyproxy's stay in the Debian/Ubuntu limbo were over.

They were happy to get a few bugs and patches forwareded upstream, and asked me why all of this hadn't happened before. Pitty is that a few longstanding issues were well known in Debian but not so obvious for the new upstream maintainers, and are present in 1.8.0. Hopefully all will be dealt with in 1.8.1 or the next major version. The lesson is: if you work on an apparently abandoned package, after cleaning the mess in your NMU, try to spend 15 more minutes trying to contact upstream (if available), pointing them at the patch tracker and our list of bugs: chances are many are still useful. Also, contact the Debian maintainer, and if they ask you to take over, at least post a RFA so someone else can. If you're a Tinyproxy user, I'd be happy to hear if the current package in Debian unstable works for you. If you were having weird issues with 1.6.x, chances are 1.8 will fix them. The package can be installed on stable with no extra dependencies, so if you're feeling adventurous, go ahead and upgrade.

Diagnosis A few weeks ago I was referred to a specialist for the treatment of Carpal Tunnel Syndrome. I first noticed the symptoms in early January, it started happening at night with a partial numbness in the fingers of my left hand. I didn t think much of it at first as it s the expected symptom of sleeping in a position that reduces the blood flow. But when it kept happening with my left hand and never happening with my right and then started getting worse (including happening during the day) I sought medical advice. The doctor asked me to bend my hand down (as if trying to touch my left elbow with the fingers of my left hand). Within about 10 seconds this caused numbness this result from bending one s wrist is a major symptom of CTS. Treatment On Thursday I saw a specialist about this, she agreed with the GP s diagnosis and made a wrist brace for me. She started by cutting off a length of a tube of elastic woven material (similar to a sock) and then cutting a thumb hole, that became the lining. Then to make the hard part she put a sheet of plastic in an electric saucepan (which had water simmering) until it started to melt and then used a spatula to fish it out. The melting temperature of the plastic wasn t that high (it was soft at about 50C when she put it on my arm), it wasn t at all sticky when it was partially melted, and it didn t seem to conduct heat well. After wearing the wrist brace non-stop for a few days I have noticed an improvement already. Hopefully I will make a full recovery in a matter of a month or so, I will probably have to wear a wrist brace when sleeping for the rest of my life, but that s no big deal it s more comfortable to sleep with a wrist brace than a partially numb hand. I ve also been prescribed a set of exercises to help remove scar tissue from the nerves. I haven t done them much yet. In terms of being annoying, the wrist-brace has 3mm diameter holes in a square grid pattern with a 25mm spacing. This doesn t let much air through and in warm weather my arm gets sweaty and starts to itch. I m thinking of drilling some extra holes to alleviate this the part which makes my arm itch doesn t need much mechanical strength. The only task which has been really impeded has been making peanut butter sandwiches, maybe it was making sandwiches not typing that caused CTS? ;) In any case I m not giving up typing but I would consider giving up peanut butter sandwiches. I really hope to avoid the surgical option, it doesn t seem pleasant at all. Other One final thing to note is that Repetitive Strain Injury (RSI) is entirely different. RSI is a non-specific pain associated with repetitive tasks while CTS is a specific problem in one or two nerves where they go through the wrist. RSI apparently tends to reduce the effective strength of the afflicted limb, while milder cases of CTS (such as mine) cause no decrease in strength of course a severe case of CTS results in muscle atrophy due to reduced nerve signals, but I shouldn t ever get that. Many people think that RSI and CTS are essentially the same thing I used to think that until a few weeks ago when I read the Wikipedia pages in preparation to seeing a doctor about it. I want to obtain some of the plastic that was used to make my wrist brace, it could be really handy to have something that convenient for making boxes, containers, and supports for various things among other things it doesn t appear to generate static. The low melting temperature will prevent certain computer uses (the hot air that comes out of a cooling system for a high-end CPU would probably melt it), but it could probably be used to make the case for an Opteron system with careful design. I m guessing that the cost of the plastic is a very small portion of the $150 I paid to the specialist so it shouldn t be that expensive and I m sure it would be even cheaper if it wasn t bought from a medical supply store. If I ever get time to do some work on an Arduino system or something similar then I will definitely try to get some of this plastic for the case. Also the Wikipedia page has a picture of what appears to be a mass-produced wrist brace. I think that it might be improved by having the picture of the custom one that I wear added to the page. I unconditionally license the picture for free use by Wikipedia and others under the CC by attribution license. So if anyone thinks that a picture of my hand would improve Wikipedia then they can make the change.

• [1] http://en.wikipedia.org/wiki/Carpal_tunnel_syndrome

Review: Coders at Work, by Peter Seibel

Publisher:	Apress
Copyright:	2009
ISBN:	1-4302-1948-3
Format:	Trade paperback
Pages:	601

Coders at Work is a collection of edited interviews by Peter Seibel (probably best known previously for his book Practical Common Lisp) of an eclectic and excellent collection of fifteen programmers. It opens with an interview with Jamie Zawinski (one of the original Netscape developers) and closes with Donald Knuth. In between, the interview subjects range in programmer generations from Fran Allen (who started at IBM in 1957) and Bernie Cosell (one of the original ARPANET developers) to Brad Fitzpatrick (LiveJournal founder and original developer). Techniques and preferences also range widely, including two people involved in JavaScript development and standardization (Brendan Eich and Douglas Crockford), a functional programming language designer and developer (Simon Peyton Jones), language designers and standardizers such as Guy Steele, and people like Dan Ingalls who have a different experimental approach to programming than the normal application development focus. All of the interviewees are asked roughly the same basic questions, but each discussion goes in different directions. Seibel does an excellent job letting the interview subjects shape the discussion. Two things immediately stood out for me about this book. First, it's huge, and that's not padding. There are just over 600 pages of content here, much of it fascinating. The discussions Seibel has are broad-ranging, covering topics from the best way to learn programming to history and anecdotes of the field. There's some discussion of technique, but primarily at the level of basic approaches and mindset. One typical question is how each programmer organizes their approach to reading code that isn't familiar with them. Each interviewee is also asked for book recommendations, for their debugging techniques, for their opinions on proving code correct, and how they design code. The participants are so different in their backgrounds and approaches that these conversations go in fifteen different directions. This is one of the most compelling and engrossing non-fiction books I've read. Second, the selection of interview subjects, while full of well-known names in the field, is not the usual suspects. While I'm interested in the opinions of people like Larry Wall and Guido van Rossum, I've already heard quite a lot about how they think about programming. That's material that Coders at Work doesn't need to cover, and it doesn't. Many of the interview subjects here are people I'd heard of only vaguely or not at all prior to this book, often because they work in an area of programming that I'm not yet personally familiar with. Those who I had heard of, such as L. Peter Deutsch, I often knew in only one context (Ghostscript in that case) and was unfamiliar with the rest of their work. This gives the book a great exploratory feel and a lot of originality. There is so much good material here that it's hard to give a capsule review. This is a book I'm highly likely to re-read, taking more detailed notes. There's entertaining snarking from Jamie Zawinski and Brendan Eich, fascinating history of the field (including in gender balance) from Fran Allen, and an intriguing interview with Joe Armstrong (creator of Erlang), who seems to have a far different attitude towards languages and libraries than the other interviewees. Every interview is full of gems, bits of insight that I now want to research or play with. A couple of examples come to mind, just to provide a feel of the sort of insights I took out of the book. In the interview with Joshua Bloch, who does a lot of work on library APIs, he mentions that empathy is one of the most important skills for designing an API. You have to be able to put yourself in the shoes of the programmer who's going to use the API and understand how it will feel to them. This came up in the context of a discussion about different types of programmers, and how programmers can be good at different things; the one who can do low-level deep optimization may not have that sense of empathy. Another example: Bernie Cosell talked about how he did debugging, and how he got a reputation for being a fantastic debugger who was able to fix just about anything. He confessed that he often reached a portion of the code that he didn't understand, that seemed too complex and tricky for what it was attempting to accomplish, and rather than trace through it and try to understand it, he just rewrote it. And after rewriting, the bug was often gone. It wasn't really debugging, but at the same time it's close to the more recent concept of refactoring. Several of the interview subjects commented on a subjective feeling of complexity and how when it gets too high that's a warning sign that code may need to be rethought and rewritten. A third example: I was fascinated by the number of interviewees who said that they used printf, assert, and eyeballs to debug rather than using any more advanced debugging tools. The former Lisp developers would often bemoan the primitiveness of tools like gdb, but many of them found that print statements and thinking hard about the code were usually all that's needed. (There was also a lot of discussion about test suites and test-driven development.) The general consensus was that concurrency problems were the hardest to debug; they made up a disproportional number of the responses to Seibel's question about the hardest bug the programmer ever had to track down. I could go on giving similar examples at great length, but apart from the specific bits of wisdom, the strongest impact this book made on me was emotional. Coders at Work is full of people who love programming and love software, and that enthusiasm, both in general and for specific tools and ideas, comes through very clearly. I found it inspiring. I realized while reading this book, and I suspect I'm not alone among programmers in this, that I largely stopped learning how to program a few years back and have been reusing skills that I already have. Reading Coders at Work gave me a strong push towards finding ways to start learning, experimenting, and trying new techniques again. It also filled me with enthusiasm for the process of programming, which immediately helped my productivity on my own coding projects. This is obviously a book whose primary target audience is practicing programmers, and while it doesn't go too far into language theory, I was relying on remembered terms and structure from my master's degree for a few of the interviews. I think it's approachable for anyone who has a working background in programming and a few languages or a CS degree, but it might be a stretch for someone new to the field. But even someone without any programming knowledge at all would get a lot out of the anecdotes and snapshots of the history of software development. Coders at Work is also full of jumping-off points for some additional research on Google or additional reading in other recommended books. I only have one complaint, which I have to mention in passing: for such a large book full of interesting ideas and book recommendations, the index is wholly inadequate. I tried looking up five or six things in it, including the source of some of the book recommendations that are collected in an appendix, and I struck out every time. It's very hard to find something again in 600 pages, and more attention paid to the index would have been greatly appreciated. But, despite that, for people within the target audience, I cannot recommend this book too highly. Not only was it full of useful information, at the level of programming above the code details that's often the hardest to talk about, but it's consistently entertaining and emotionally invigorating and inspiring. It made the rounds of tech blogs when it was first released, to nearly universal approval, and I can only echo that. If you're a practicing programmer, I don't think you'll regret spending a few weeks reading and thinking about this book. Rating: 10 out of 10

Time for a little end-of-the-month looking back. (Looking back o-ver my shoul-der ) What about X11-based graphical installer? After the one-week rush early this month, a summary of my findings was posted on debian-boot@, including udebs, patches, and source packages, labelled as v1. People seemed to like the idea, and I received a bunch of comments to fix or improve various things. It took some time to implement everything in a satisfying (at least to me) manner, but I reached a point where I was confident enough to publish a v2 set of udebs, patches, and source packages. That was also announced on debian-boot@, and then re-announced once I ve been able to rebuild the image with speakup enabled again. Hopefully, that ll be (more or less) the final plan, and d-i folks should either give us a green or red light based on that v2 set. Some details will have to be ironed out (some items were mentioned in both v1 and v2 summaries), but they shouldn t prevent us from starting adding the needed udebs; or at least not too long. Speaking of X11, xserver-xorg-video-intel is buggy as hell! Basically, yes, and that s known. Many bugs were due to kernel issues, and regressions got fixed in the series of 2.6.32.y stable updates. Usually, upgrading to at least 2.6.32-3-$arch (from linux-2.6 s revision 2.6.32-9) helps, as well as running latest libdrm, xserver-xorg-core, and mesa from sid. Trying with some 2.6.33-ish kernels from experimental would be nice as well. You re of course very welcome to keep us posted through the bugs you opened already, closing them if appropriate. And before reporting more bugs, please make sure you re running recent versions of all those components. That should help people walking the list of remaining bugs to deal with them more efficiently. A very annoying bug which can still be experienced with an up-to-date sid environment is described in freedesktop s #26723.

Debconf11 This evening, the final decision on which city will host Debconf11 next year will be taken. For the last half year, mostly Andreas Barth, Jan-Marek Glogowski and I have been working hard to make the Munich bid as good as possible. One thing we wanted to make clear from the beginning was that we would go for a conference in the city center - not some conference center in some nearby village or in an industrial area far away from where the city life happens. It was not easy, since the german-wide decision, we had to reshuffle venue plans a couple of times. In the end, thanks to Jan-Marek, we managed to get an excellent venue offer. Our bid consits mostly of:

• Venue: Computer Science building (recently built) of Munich University for Applied Science, we can get as much as we need, for free. The only thing we would have to pay for is additional security personell during the night.
• Network: Leibniz Rechenzentrum is the operator of the Munich Research Network (MWN), the venue is connected with at least 1 GBits fibre optics, and the MWN is connected to X-Win at the same speed. This will be free as well.
• Food: We can either take up the offer from the Studentenwerk, the organisation operating the university restaurants. Of course, the quality is not like in a Michelin-star restaurant, but I have eaten there for several years during my studies and it is on par with previous Debconf offerings. Alternatively, we could look into food catering.
• Accomodation: We tend to go for hostels, similar to Edinburgh, probably 4-6 bed dorms. Munich is pretty expensive for lodging, so this is something we decided early on to keep the costs reasonable. Again, I think this is in line with previous Debconfs. Of course, hotels at a broad price range are available.

The biggest strong points about Munich are, in my opintion:

• Our local team has lots of experience with Debian and Debconfs, as well as organizing conferences
• We have government support via the LiMux-project, and the city mayor of Munich, Christian Ude, has agreed to be the patron of the conference
• Munich is very easy to get to, both for european (via train or car) or american/asian attendees (via plane). The airport is one of the biggest in europe and has direct connections to e.g. Atlanta, New York, Boston, San Fransisco, Los Angeles, Sao Paulo and Tokio.
• Network connection via LRZ/MWN/X-WIN should be superb, especially to Debian machines hosted at euro

It the end, it seems Banja Luka seems to have the stronger bid, especially due to their 150000 EUR governemnt sponsorship. We will see who wins, I believe we did the best we could.

If you want to help the Debian/GNOME team, now is the time. For two days, we are going to triage as many bugs as possible. I have prepared a little wiki page that explains what you need to help and how to start. Of course, the team members will remain available on IRC to give advice.

Until two years or so ago I used VMware Workstation intensively for development and testing of Debian Installer, using one of the licenses generously made available to the D-I team by VMware. It was much faster than Qemu and thus very welcome. But due to increasing problems keeping it working with new kernels on a desktop system running unstable, I switched to VirtualBox (the OSE version), which has the huge advantage of being packaged for Debian and thus automatically follows the Debian kernel packages. That advantage has disappeared somewhat as I'm currently compiling my own kernels I'm currently running 2.6.33 on a Lenny desktop. So far I've been able without too much trouble to find patches for the VirtualBox modules to keep them compatible with new upstream kernels. This week I had reason to try VMware again. The Server edition this time as that has free licenses. The Server concept, where you connect to the management system and virtual machines via a web browser, is quite nice. It means I could install it on a server and keep my laptop nice and responsive. To keep VMware separate from the rest of the system and not mix it with software installed cleanly from Debian packages, I decided to install it in /opt. And that works beautifully. There are only a few bits installed in /etc, but that's OK. I have /etc managed by etckeeper anyway [1]. More challenging was building WMware modules to match my kernel. VMware wants you to run their vmware-config.pl script every time you switch kernels and build the kernel modules on the system where it runs (which requires the kernel headers). I wanted to build the modules as part of my kernel build process, on a totally different machine. The same as I already do for VirtualBox. I save the custom modules in a tarball that has the same uname and package version as the kernel package I build and have a simple script that installs them correctly. I succeeded by hacking the Makefiles (deleting most of their content) and then integrating them in my kernel build wrapper script. The module source provided by VMware built fine with a Debian 2.6.26 kernel, but not with the 2.6.32.9 kernel on my server (of course). But luckily others had already run into the same problems and solved them, so with some searching I found the required patches (first a full updated source for 2.6.29, then patches needed for .31 and for .32). Isn't open source just wonderful? So with that the VMware server started beautifully (well, the init script needed to be told that module names have changed from *.o to *.ko), but I could not connect to it from my laptop using SSL. Connecting without SSL (using an instance of iceweasel running on the server but started remotely from my laptop using X forwarding SSH) worked fine. That turned out to be a known issue too. After applying all the suggested workarounds in my iceweasel configuration (disable TLS 1.0; set cache size to zero; explicitly disable use of proxy for the server) I can now connect reliably to the VMware Server management system. Phew. [1] I had to exclude a fair number of VMware files for etckeeper as they are updated by VMware itself and thus really belong in /var. Example are DCHP status files...

After a whole bunch of drastic changes, lots of bugfixes, rewriting and refactoring, I released DAViCal 0.9.8 on Christmas day last year. I didn't release it very publicly, because I knew it sucked significantly. In an increasingly fast turnaround I've subsequently released 0.9.8.1 to a somewhat wider audience while I was at the recent Calendaring and Scheduling Consortium meeting in Costa Mesa at the beginning of the month. Earlier this week I released 0.9.8.2 to the more interested of the DAViCal userbase. So finally, yesterday, I released DAViCal 0.9.8.3 to fix the few significant problems that were left with that, and this is the release that I'm telling everyone about, because I believe it should be a good stable platform to people who want to upgrade their production DAViCal servers, or who have been hanging back from using DAViCal until the platform was a little more stable.
<!--break-->
This release marks some significant departures from previous DAViCal. I've decided to walk away from some of the more ancient legacy software I tried to work with in the past (PHP4 & PostgreSQL 7.x), to move to support the most ancient-but-not-superseded legacy Linux release I know of, which is CentOS / RHEL, so DAViCal now has a minimum requirement of PHP 5.1 & PostgreSQL 8.1. The biggest changes to DAViCal are under the covers. It is server software, after all, so the largest changes often are not visible on the surface. What has changed is that the architecture for constructing responses as been refactored into a core object which is used to access any DAV resource in the system. This greatly simplifies the general coding and reduces a fair bit of code duplication which had been happening. Another long overdue change is to get rid of the old arcane & obtuse permissions model, replacing it with something which will be radically faster in installations with more than a few hundred users, as well as being more consistent, easier for people to control, and directly in alignment with the DAV ACL specification. Some of the work here was assisted by NZ Registry Services who gave me a Macbook to help with my compatibility testing. Not all of the changes are under the covers though. The new DAViCal also has a thoroughly revised administrative interface, and over the last couple of releases I've gone through the system trying to uncover all the places which were not properly localisable, too, so if you see DAViCal displaying strings in a language you didn't configure it for, it should be a fixable thing. I'd like to particularly thank Masahiro Mikami for turning around some Japanese translations very quickly which enabled me to quickly and visually see what was not properly translatable. There's still more work to do (there's always more work to do) but a fully translated DAViCal should, I hope, be quite usable by non-English speakers now. The new DAViCal also supports some rather significant extra functionality beyond the CalDAV standard, in particular we can thank Rob 'Cave' Ostensen for providing an implementation of pub/sub event change notifications. This version also supports draft 2 of the proposed WebDAV synchronisation standard - that's still under development, but we expect to track pretty close to released versions of that. Of course with all of this work there are some areas that didn't get changed. I didn't manage to finish an implementation of the scheduling extensions draft, much as I would have liked, but that is going to become very much a focus in the coming couple of months, and I'll be calling it "1.0" when things settle down after we get that done. Other things I will be working on include a ticketing system for providing targeted, controlled access to a specific collection or event, and making a start on CardDAV support for addressbook storage. DAViCal seems to be fitting a need for people, and I know there are several thousand installations around the world, even if I'm not sure where they all are. I know some people are running DAViCal on their 8-way server, where I've no doubt it gurgles along pretty happily, and that there are some people running it on their OpenWRT installation, with some tiny amount of resources - just enough for a family calendar. Traffic on the wiki has increased to several hundred thousand hits per month, perhaps three times what it was a year ago, and I hope that I can continue to provide a valuable and useful piece of infrastructure for that little calendaring corner of your organisation. What heartens me the most in this ongoing experience is the nascent community that appears to be forming around my software, with people writing 'tip sheets' and helping to answer questions on the IRC channel and mailing list. These small contributions made by many people - people whom I have never met, for the most part - are enabling me to put more time into feature development and expansion, and that's what I really love.

This afternoon, a box arrived from Advanced Circuits, containing 108 fully assembled TeleDongle boards! This is not only the first "intended for sale" build of hardware from the Altus Metrum family of projects, it's also the first time that I've ever sent out one of my board designs for someone else to assemble. I therefore approached the turn-on and test of the first board out of the box with more than a little trepidation... fortunately, for no reason! I'm immensely pleased to report that TeleDongle serial number 100 turned on and works entirely as expected! I celebrated by packaging it in a cool little Hammond translucent blue plastic box with a USB cable, yielding the first prototype of a fully packaged TeleDongle board such as we anticipate selling for use receiving data from rockets carrying TeleMetrum boards. We also intend to sell these boards as-is (flashed with default firmware and measured oscillator cal value) to folks who'd like a robust wireless link for their next microcontroller project, whether rocket-related or not. I will, of course, post something here when we're ready to start taking orders. Now we just need the weather to cooperate long enough to log more test flights of TeleMetrum. The new version looks great so far, but I want a few more flights before I'll be confident enough to place an order with our assembler for a run of those too... Stay tuned!

In an attempt to force an exec to totally stall so I could attach gdb to a process that does a setuid transition without freaking it out (i.e. can t launch sudo gdb ), I briefly played with process priority, scheduling, and CPU affinity (pinning a process to a CPU). So far, the best attempt at stalling the process was to set CPU affinity, set its scheduling policy (IDLE), drop the priority value fully (19), and then run a CPU hog with the same CPU affinity with a very high priority (-20). Staller: sudo schedtool -a 0 -N -n -20 -e /tmp/spin-cpu
Stallee: schedtool -a 0 -D -n 19 -e /usr/bin/sudo -s The hope was to then run sudo gdb /usr/bin/sudo $(pidof sudo) , but it seems that this still isn t enough to make the exec of sudo totally stall while the spin-cpu process is running it certainly executes more slowly, but I want it to stop. I have this feeling like I m missing something obvious about how to accomplish this gdb session sanely. I wonder if I can get gdb to switch targets across a child exec, i.e. run gdb as root on a program that fully drops privs, but then execs sudo. Guess it s time to go read the gdb manual some more

This is what I set up for backups recently using a cheap USB-enclosure which can house 2 SATA disks and shows them as 2 USB mass-storage devices to my system (using only one USB cable). Without any further introduction, here goes the HOWTO: First, create one big partition on each of the two disks (/dev/sdc and /dev/sdd in my case) of the exact same size. The cfdisk details are omitted here.

  $ cfdisk /dev/sdc
  $ cfdisk /dev/sdd

Then, create a new RAID array using the mdadm utility:

  $ mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdc1 /dev/sdd1

The array is named md0, consists of the two devices (--raid-devices=2) /dev/sdc1 and /dev/sdd1, and it's a RAID-1 array, i.e. data is simply mirrored on both disks so if one of them fails you don't lose data (--level=1). After this has been done the array will be synchronized so that both disks contain the same data (this process will take a long time). You can watch the current status via:

  $ cat /proc/mdstat
  Personalities : [raid1]
  md0 : active raid1 sdd1[1] sdc1[0]
        1465135869 blocks super 1.1 [2/2] [UU]
        [>....................]  resync =  0.0% (70016/1465135869) finish=2440.6min speed=10002K/sec
  unused devices: 

Some more info is also available from mdadm:

  $ mdadm --detail --scan
  ARRAY /dev/md0 metadata=1.01 name=foobar:0 UUID=1234578:1234578:1234578:1234578
  $ mdadm --detail /dev/md0
  /dev/md0:
          Version : 1.01
    Creation Time : Sat Feb  6 23:58:51 2010
       Raid Level : raid1
       Array Size : 1465135869 (1397.26 GiB 1500.30 GB)
    Used Dev Size : 1465135869 (1397.26 GiB 1500.30 GB)
     Raid Devices : 2
    Total Devices : 2
      Persistence : Superblock is persistent
      Update Time : Sun Feb  7 00:03:21 2010
            State : active, resyncing
   Active Devices : 2
  Working Devices : 2
   Failed Devices : 0
    Spare Devices : 0
   Rebuild Status : 0% complete
             Name : foobar:0  (local to host foobar)
             UUID : 1234578:1234578:1234578:1234578
           Events : 1
      Number   Major   Minor   RaidDevice State
         0       8       33        0      active sync   /dev/sdc1
         1       8       49        1      active sync   /dev/sdd1

Next, you'll want to create a big partition on the RAID device (cfdisk details omitted)...

  $ cfdisk /dev/md0

...and then encrypt all the (future) data on the device using dm-crypt+LUKS and cryptsetup:

  $ cryptsetup --verbose --verify-passphrase luksFormat /dev/md0p1
  Enter your desired pasphrase here (twice)
  $ cryptsetup luksOpen /dev/md0p1 myraid

After opening the encrypted container with cryptsetup luksOpen you can create a filesystem on it (ext3 in my case):

  $ mkfs.ext3 -j -m 0 /dev/mapper/myraid

That's about it. In future you can access the RAID data by using the steps below. Starting the RAID and mouting the drive:

  $ mdadm --assemble /dev/md0 /dev/sdc1 /dev/sdd1
  $ cryptsetup luksOpen /dev/md0p1 myraid
  $ mount -t ext3 /dev/mapper/myraid /mnt

Shutting down the RAID:

  $ umount /mnt
  $ cryptsetup luksClose myraid
  $ mdadm --stop /dev/md0

That's all. Performance is shitty due to all the data being shoved out over one USB cable (and USB itself being too slow for these amounts of data), but I don't care too much about that as this setup is meant for backups, not performance-critical stuff.

Almost all of wiki contents got updated, so please take your time to review it all, once again n was more of a symbolic meaning, since in meantime we solved our bids weakest links and pretty much got it mature and at the stage we were aiming it to be. We ll still make some minor changes to it until the final decision date (in 47 hours) but this is it really So without further ado, let me introduce you to our n wiki Since besides changing pretty much the whole wiki we have also added (important) new pages for: Banja Luka and Republika Srpska We have added a new pages to bring Banja Luka and Republika Srpska closer to every potential visitor. Full Government Support Today we have received the most important information when it comes to our bid. Today government council sitting was done, where one of the topics was full financial support in case Banja Luka is host to DebConf11. Proposition was accepted! To remind you, we will get free venue building wheter it s Government Building or Banski Dvori , besides that we re getting them to cover basically all of the costs needed for the conference, and besides that we re getting 5 additional members to our local team (highly capable and educated govt. officials) which even includes city Mayor. Early tomorrow we ll get scan/fax of this memorandum from Chief of Cabinet along with the local team names which will all together be added to this very wiki page. Local Team We have almost assembled our local team/supporters team whose members were wisely and thoroughly selected. Since before anything this is Balkans Debconf, and a new breakthrough to a region that has ~55 million inhabitants, we have made connections all over Balkans, especially from Serbia and Belgrade. This page might might suffer the biggest changes in next few hours, especially since we still need to add people on behalf of ETF (Faculty of Electrical Engineering) and Goverment itself. Accommodation
We have made a separate page for accommodation as well, since we have gathered a whole bunch of new information that just required us to make a new page. Internet We have made a major breakthrough in Network connectivity and technicalities as well! SARNET Academic and Research Network of Republic of Srpska has offered us with 1GB link free as in beer! Please see their Letter of Support/Memorandum, besides that we have Mtel and BHTelecom as our backup options. Besides all that, as I previously noted we made changes throughout wiki page, we have added new contents to fun and free time, as well as to the arrival. Tomorrow with last pages to our local team + govt. support memorandum being added to our wiki we are ready for the DebConf11 final decision! Remainder, decision is being made in 47 hours on #debconf-team on irc.debian.org; please come and support us for being host to DebConf11! Bosnia and Herzegovina FTW! http://wiki.debconf.org/wiki/DebConf11/BanjaLuka