podlators is the Perl distribution providing Pod::Man and Pod::Text, along with related modules and supporting scripts. The primary change in this release is the addition of configurable guesswork for Pod::Text, paralleling Pod::Man. I had forgotten that Pod::Text also had complex heuristics for whether to quote C<> text that have the same Perl-specific properties as Pod::Man. This is now configurable via a guesswork option, the same as in Pod::Man, although the only type of guesswork supported is quoting. I also updated the default regexes, which include some fixes from Pod::Man. Thanks to discussion with G. Branden Robinson, I now understand quoting in roff considerably better, which let me fix a few obscure bugs with strange page titles or configured quote characters. Pod::Man now avoids quoting macro arguments when the quoting is unnecessary, which should hopefully produce slightly more readable output. Finally, I had started using a Pod::Simple feature introduced in 3.26 in Pod::Text but forgot to update the dependency, resulting in test failures on some old versions of Perl. (The same tests didn't fail in GitHub CI, which is probably related to how I install dependencies.) That's been fixed in this release. You can get the latest version from CPAN or from the podlators distribution page.

You might not know who Peter is because he s not very visible on Debian mailing lists. He s very active however and in particular on IRC. He was an admin of the OFTC IRC network at the time Debian switched from Freenode to OFTC. Nowadays he s a member of the Debian System Administration team who runs all the debian.org servers. If you went to a Debconf you probably met him since he s always looking for new signatures of his GPG key. He owns the best connected key in the PGP web of trust. He also wrote caff a popular GPG key signing tool. Raphael: Who are you? Peter: I m Peter Palfrader, also known as weasel. I m in my early 30s, born and raised in Innsbruck, Austria and am now living and working in Salzburg, Austria. In my copious free time, other than help running Debian s servers I also help maintaining the Tor project s infrastructure. Away from the computer I enjoy reading fiction (mostly English language Science Fiction and Fantasy), playing board games and going to the movies. Weather permitting, I also occasionally do some cycling. Raphael: How did you start contributing to Debian? Peter: I installed my first Debian the week slink came out. That was Debian 2.1 for the youngsters, in early 1999. The one thing I immediately liked about slink was that Debian s pppd supported RAS authentication which my university s dial-up system required. No way I d go back to SuSE 5.3 when I had working Internet with my Debian box. During that year I started getting involved in the German language Debian channel on IRCnet which got me in contact with some DDs. Christian Kurz (<shorty>) was working on Debian QA at the time and he asked my help in writing a couple of scripts. Some of that work, debcheck, still produces parts of the qa.d.o website, tho the relevance of that nowadays is probably negligible. While trying to learn more Perl earlier, I had written a program to produce syntax highlighted HTML for code snippets in various languages. I didn t really know what I was doing but it kinda worked, and probably still does since I still get mail from users every now and then. I figured that it would be really nice if people could just get my software together with Debian. According to code2html s Debian changelog the initial release of the package was done on a weekday at 2:30 in the morning early in 2000, and if my memory serves me correctly, shorty uploaded it shortly afterwards. I started packaging a couple of other piece of software and in the same year I sent my mail to the debian account managers to register my intent to become a DD. No new developers where being accepted at that time since the DAMs wanted to overhaul the entire process so I wasn t surprised to not get any immediate reply. Of course what the silence also meant was that the mail had been lost, but I only learned of that later when I took all my courage to ask DAM about the status of application a couple months later. Once that was sorted out I was assigned an AM, did the usual dance, and got my account late in November 2000. Raphael: Four years ago, the Debian System Administration team was a real bottleneck for the project and personal conflicts made it almost impossible to find solutions. You were eager to help and at some point you got dropped as a new member in that team. Can you share your story and how you managed the transition in the difficult climate at that time? Peter: Ah, that was quite the surprise for an awful lot of people, me included. Branden Robinson, who was our DPL for the 2005-2006 term, tried to get some new blood added to DSA who were at the time quite divided. He briefly talked to me on IRC some time in summer 2005, telling me I had come recommended for a role on the sysadmin team . In the course of these 15 minutes he outlined some of the issues he thought a new member of DSA would face and asked me if I thought I could help. My reply was cautiously positive, saying that I didn t want to step on anybody s toes but maybe I could be of some assistance. And that was the first and last of it, until some fine November day two years later I got an email from Phil Hands saying I ve just added you to the adm group, and added you to the debian-admin@d.o alias. and welcome on board . *blink* What!? My teammates at the time were James Troup (elmo), Phil Hands (fil), Martin Joey Schulze and Ryan Murray (neuro). The old team, while apparently not on good terms with one another, was however still around to do heavy lifting when required. I still remember when on my first or second day on the team two disks failed in the raid5 of ftp-master.debian.org aka ries. Neuro did the reinstall once new disks had arrived at Brown University. I m sure I d have been way out of my league had this job fallen to me. Fortunately my teammates were all willing and able to help me find whatever pieces of information existed that might help me learn how debian.org does its stuff. Unfortunately a lot of it only existed in various heads, or when lucky, in one of the huge mbox archives of the debian-admin alias or list. Anyway, soon I was able to get my hands dirty with upgrading from sarge to etch, which had been released about half a year earlier. Raphael: I know the DSA team has accomplished a lot over the last few years. Can you share some interesting figures? Peter: Indeed we have accomplished a lot. In my opinion the most important of these accomplishment is that we re actually once again a team nowadays. A team where people talk to one another and where nobody should be a SPoF. Since this year s debconf we are six people in the admin team: Tollef Fog Heen (Mithrandir) and Faidon Liambotis (paravoid) joined the existing members: Luca Filipozzi, Stephen Gran, Martin Zobel-Helas, and myself. Growing a core team, especially one where membership comes with uid0 on all machines, is not easy and that s why I m very glad we managed to actually do this step. I also think the infrastructure and our workflows have matured well over the last four years. We now have essential monitoring as a matter of course: Nagios not only checks whether all daemons that should be running are in fact running, but it also monitors hardware health of disks, fans, etc. where possible. We are alerted of outstanding security updates that need to be installed and of changes made to our systems that weren t then explicitly acked by one of us. We have set up a centralized configuration system, puppet, for some of our configuration that is the same, or at least similar, on all our machines. Most, if not all, pieces of software, scripts and helpers that we use on debian.org infrastructure is in publicly accessible git repositories. We have good communication with other teams in Debian that need our support, like the ftp folks or the buildd people. As for figures, I don t think there s anything spectacular. As of the time of our BoF at this year s DebConf, we take care of approximately 135 systems, about 100 of them being real iron, the other virtual machines (KVM). They are hosted at over 30 different locations, tho we are trying to cut down on that number, but that s a long and difficult process. We don t really collect a lot of other figures like web hits on www.debian.org or downloads from the ftp archive. The web team might do the former and the latter is pretty much impossible due to the distributed nature of our mirrors, as you well know. Raphael: The DSA team has a policy of eating its own dog food, i.e. you re trying to rely only on what s available in Debian. How does that work out and what are the remaining gaps? Peter: Mostly Debian, the OS, just meets our needs. Sure, the update frequency is a bit high, we probably wouldn t mind a longer release cycle. But on the other hand most software is recent enough. And when it s not, that s easy to fix with backports. If they aren t on backports.debian.org already, we ll just put them there (or ask somebody else to prepare a backport for us) and so everybody else benefits from that work too. Some things we need just don t, and probably won t, exist in Debian. These are mainly proprietary hardware health checks like HP s tools for their servers, or various vendors programs to query their raid controller. HP actually makes packages for their stuff which is very nice, but other things we just put into /usr/local, or if we really need it on a number of machines, package ourselves. The push to cripple our installers and kernels by removing firmware was quite annoying, since it made installing from the official media next to impossible in some cases. Support for working around these limitations has improved with squeeze so that s probably ok now. One of the other problems is that especially on embedded platforms most of the buildd work happens on some variation of development boards, usually due to increased memory and hard disk requirements than the intended market audience. This often implies that the kernel shipped with Debian won t be usable on our own debian.org machines. This makes keeping up with security and other kernel fixes way more error prone and time intensive. We keep annoying the right people in Debian to add kernel flavors that actually boot on our machines, and things are getting better, so maybe in the future this will no longer be a problem. Raphael: If you could spend all your time on Debian, what would you work on? Peter: One of the things that I think is a bit annoying for admins that maintain machines all over the globe is mirror selection. I shouldn t have to care where my packages come from, apt-get should just fetch them from a mirror, any mirror, that is close by, fast and recent. I don t need to know which one it was. We have deployed geodns for security.debian.org a while ago, and it seems to work quite well for the coarse granularity we desired for that setup, but geodns is an ugly hack (I think it is a layer violation), it might not scale to hundreds or thousands of mirrors, and it doesn t play well with DNSSEC. What I d really like to see is Debian support apt s mirror method that I think (and I apologize if I m wronging somebody) Michael Vogt implemented recently. The basic idea is that you simply add deb mirror://mirror.debian.org/ or something like that to your sources.list, and apt goes and asks that server for a list of mirrors it should use right now. The client code exists, but I don t know how well tested it is. What is missing is the server part. One that gives clients a mirror, or list of mirrors, that are close to them, current, and carry their architecture. It s probably not a huge amount of work, but at the same time it s also not entirely trivial. If I had more time on my hands this is something that I d try to do. Hopefully somebody will pick it up. Raphael: What motivates you to continue to contribute year after year? Peter: It s fun, mostly. Sure, there are things that need to be done regularly that are boring or become so after a while, but as a sysadmin you tend to do things once or twice and then seek to automate it. DSA s users, i.e. DDs, constantly want to play with new services or approaches to make Debian better and often they need our support or help in their endeavors. So that s a constant flow of interesting challenges. Another reason is that Debian is simply where some of my friends are. Working on Debian with them is interacting with friends. I not only use Debian at debian.org. I use it at work, I use it on my own machines, on the servers of the Tor project. When I was with OFTC Debian is what we put on our machines. Being a part of Debian is one way to ensure what Debian releases is actually usable to me, professionally and with other projects. Raphael: Is there someone in Debian that you admire for their contributions? Peter: That s a hard one. There are certainly people who I respect greatly for their technical or other contributions to Debian, but I don t want to single anybody out in particular. I think we all, everyone who ever contributed to Debian with code, support or a bug report, can be very proud of what we are producing one of the best operating systems out there.

---

Thank you to Peter for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Twitter and Facebook.

No comment Liked this article? Click here. My blog is Flattr-enabled.

Out of curiosity, and because it is Sunday morning and I have a cold and can't get my brain to do anything tricky, I counted the number of candidates in each year's DPL elections.

Year	Count	Names
1999	4	Joseph Carter, Ben Collins, Wichert Akkerman, Richard Braakman
2000	4	Ben Collins, Wichert Akkerman, Joel Klecker, Matthew Vernon
2001	4	Branden Robinson, Anand Kumria, Ben Collins, Bdale Garbee
2002	3	Branden Robinson, Rapha l Hertzog, Bdale Garbee
2003	4	Moshe Zadka, Bdale Garbee, Branden Robinson, Martin Michlmayr
2004	3	Martin Michlmayr, Gergely Nagy, Branden Robinson
2005	6	Matthew Garrett, Andreas Schuldei, Angus Lees, Anthony Towns, Jonathan Walther, Branden Robinson
2006	7	Jeroen van Wolffelaar, Ari Pollak, Steve McIntyre, Anthony Towns, Andreas Schuldei, Jonathan (Ted) Walther, Bill Allombert
2007	8	Wouter Verhelst, Aigars Mahinovs, Gustavo Franco, Sam Hocevar, Steve McIntyre, Rapha l Hertzog, Anthony Towns, Simon Richter
2008	3	Marc Brockschmidt, Rapha l Hertzog, Steve McIntyre
2009	2	Stefano Zacchiroli, Steve McIntyre
2010	4	Stefano Zacchiroli, Wouter Verhelst, Charles Plessy, Margarita Manterola
2011	1	Stefano Zacchiroli (no vote yet)

Winner indicate by boldface. I expect Zack to win over "None Of The Above", so I went ahead and boldfaced him already, even if there has not been a vote for this year. Median number of candidates is 4.

This talk at Manchester Free Software s meeting is covering the question:

From the literally hundreds of GNU/Linux distributions in existence, what makes Debian special?

For our co-op, it s that Debian GNU/Linux, like all GNU/Linux distributions, is the product of a massive cooperative effort (in the words of former Debian project leader Branden Robinson) and that debian is the best balance of a large project and a not-for-profit implementation of those values. It s not perfect, but it s pretty good. Manchester Free Software has put recordings of some past talks online and I hope this one will appear there. I m also looking forward to Richard Smedley s talk on 20th April 2010. If you re interested in the background to debian, go along to Manchester and hear some other views! If you re already using or developing debian, why does it keep you coming back?

The monthly IRC board meeting of Software in the Public Interest will take place later today, as announced by SPI’s secretary last week. While the announcement is back on time (yay!), the agenda isn’t (aww!). I’d be quite interested to learn how SPI is going to try to reduce the risk to its reserves, given the current slow decline of its primary bank which is not one of the first US banks getting bailed out. I think the best way for not-for-profits to avoid risking donations at the moment is to avoid having them in their bank accounts, in line with the Better Business Bureau standard that

“the charity’s unrestricted net assets available for use should not be more than three times the size of the past year’s expenses or three times the size of the current year’s budget, whichever is higher.”

Back in June 2005, SPI’s board of the time (Ian Jackson, John Goerzen, Jimmy Kaplowitz, David Graham, Bruce Perens, Benj. Mako Hill, Branden Robinson) decided to “remain noncompliant” with that standard and I fear that chicken could be coming home to roost now. I hope we don’t lose anything, but AIUI we’ve got nearly $150,000 in play. Update: Unlike its UK analogue, the Federal Deposit Insurance Corporation covers corporation accounts up to $250,000, so SPI is only risking temporary unavailability, not yet a risk of loss. Thanks to bd_ for pointing me to that.

A few years back I asked Branden Robinson for access to the X Strike Force SVN repository in order to improve the X server's autodetection, with the goal of stealing what I could from knoppix. At the time, users were constantly wandering in to #debian saying that they had used knoppix to create an XF86Config-4 and then they used that file on their Debian installations. They were also constantly whining about how Debian wasn't doing as good a job. So I decided to do something about it, and took a look at what knoppix was actually doing so much better than us, and I was surprised to find that they pretty much just wrote a skeleton configuration file and let the X server fill in the details. I had no idea the server was capable of such things. So Branden graciously gave me SVN access and I began comparing the knoppix method to the script called by "dpkg-reconfigure xserver-xfree86" and realized that we probably couldn't adopt the same method because we had tons of checks for portability. So I put the problem on the backburner for few weeks and worked on something else for a while.

Well, somewhere in between then and now I got sucked in to transitioning Debian to X.org (using the aforementioned SVN access) and then working on all the things that went along with maintaining X in Debian, some well and others less so. Between transitioning to Xorg, and then transitioning to a modular Xorg, even with the ability to steal Ubuntu's packages it still took about two full years with me being a rookie and all that. There were tons of people who worked on this with me, but it was just a damn big job. Eventually though, etch released with modular X packages, and we were running at a pretty good pace with upstream, so it was time to revisit the problem of configuration again after the two year detour.

The problem of configuration had been reframed for me by having looked at what knoppix was doing and discussions with upstream. Upstream was starting to come to the conclusion that we shouldn't have a config file at all, and that the server should be smart enough to do everything by itself. It was already partially there, it just needed a push in the right direction. This was a major shift in how I thought of it. Coming from a Debian background, where the answer is to always just regenerate or edit your config file, having the server work things out for you was a totally alien idea. But I have my deepest roots in the Macintosh world, so immediately fell in love with it. The problem was that the server had a whole body of code to use if you had no config file at all, and another, with far less automagic goodness, if you had a config file, even if it was a 0 byte file. The goal became to have the server work really well with a minimal config file, so you could override what you don't like in the defaults and let the server figure things out for itself at boot. The way forward was to translate as much of the logic in our configure script in to the X server itself as possible.

Ubuntu had put in a lot of work in to the configuration setup that we automatically benefitted from, so given that most users were happy with things as they were, I was able to carve away at the problem without disrupting anything. And there was a lot to carve out, as the script that runs the config is an absolute mess that was slated by Branden for a rewrite all those years ago. Early on I picked off the low hanging fruits like the font path and modules. Similarly, Redhat's Adam Jackson had also been working on this problem, and he killed off the ServerLayout section as well as putting in lots of critical fixes all over the place elsewhere. More recently, I've gone and cut explicit modesetting out of the configure script. Hardcoding this information is generally a bad idea in the randr 1.2 world, and most of the drivers will do as good or better job of figuring out the modes than our config script would. This let us jettison using the xresprobe program to ask the monitor for the settings to use. This cut out a lot of the code that we had to deal with, simplifying the configure script and letting us all benefit from upstream's work. This leaves a big gaping hole in user configuration, which is something I'm looking to address in a few weeks, but for now there are workarounds like editing your xorg.conf manually to make things work.

Finally, yesterday I was able to upload a version of the script that no longer uses the discover program to figure out what driver to load. I've patched the server to do this at runtime. If there's no driver listed it simply scans the PCI bus, picks out your primary video card, and loads the first driver that claims to support that PCI ID. This let us jettison the last external dependency that the configure script had, so now we have a relatively small chunk of shell script with no external C code and a simplified setup. At this point we're now shipping a more skeletal config file than knoppix ever did simply because it wasn't possible to ship something like this before and have the server work at all. This is a huge milestone for me because finally, after over three years, the problem I originally set out to work on with X is done. There's still bugs to uncover and fix with all of this, but I'm convinced that what we have now is superior to our old method. Eventually, with any luck, xorg.conf will just fade away for most people. There's a lot to work on before that happens though, but I'm happy to have finally gotten here.

For various reasons, Software in the Public Interest (SPI) owned the domains opensource.org and opensource.net, which have been managed by the Open Source Initiative (OSI) for most of their life. This supported various SPI goals and also gave a possibility of community control of opensource.org/net just in case it was ever needed. OSI does not offer much opportunity for community control, as it is a self-appointing board. (Regular readers may remember that the principles of democratic member control, autonomy and concern for community are important to me.) I was watching as the SPI board voted in favour of giving away the opensource domains, proposal 2006-11-18.dbg.mjs.1 on the agenda. The vote happened without any discussion in the meeting. From memory (I guess logs will appear on the SPI site eventually):- David Graham ("SPI must also be involved in the promotion of and education about open source") proposed and voted for this action that stops SPI being involved in this promotion and education about open source; Michael Schultheiss ("I look forward to SPI's future expansion") (amended and?) voted for this action that reduces SPI; Neil McGovern ("achieve a greater degree of involvement [...] from the community in general") voted for this action that lessens SPI's involvement; Jimmy Kaplowitz ("It is important that it continue holding in trust the money and other legal assets belonging to its member projects [...] fulfill some more of its stated corporate purposes, involving education of the general public about free software and about computers in general") voted for this action that drops these assets and reduces involvement in education of the general public; Bdale Garbee ("would like to close this issue one way or another, once and for all") seemed willing to vote for anything which prevented further discussion - of course, only surrendering the domains could close it once and for all, as this is a one-way trapdoor topic - but had apologised for absence from the meeting; Martin "Joey" Schulze had apologised for absence from the meeting; Josh Berkus (nothing obviously relevant in his platform) abstained - consistent but disappointing; I think Branden Robinson was missing. Ian Jackson ("SPI's role is to provide a stable legal entity which can hold assets") voted against this action so that SPI would keep holding these assets. Bravo! Sources: The quotes above are the board's own promises in their election platforms, as listed on the SPI site in 2003 2006 apart from Bdale Garbee's platform which wasn't at the link given in 2004 so that quote is from the minutes of the previous meeting If some board members are willing to give away assets for no good reason, that strikes at one of SPI's core methods: holding assets for the community. What can we trust about this board? Their platforms are full of fine sentiments, but how do their actions reflect their platforms? This may be a mostly-dormant issue until the next election. If you want any of SPI's assets, just ask. If your request is rejected (as SPI rejected the opensource domain give-away before), just keep asking new sets of voters until they agree.

Following Joey’s lead, here’s some DWN-style comments on some of the stuff I’ve been involved in or heard of over the past week… A future for m68k has been planned on the release list, after being officially dropped as a release architecture in September. The conclusion of the discussion seems to be that we’ll move the existing m68k binaries from etch into a new “testing-m68k” suite that will be primarily managed by m68k porters Wouter Verhelst and Michael Schmitz, and aim to track the real testing as closely as can be managed. In addition the m68k will aim to make installable snapshots from this, with the aim of getting something as close as possible to the etch release on other architectures. A new trademark policy for Debian is finally in development, inspired by the Mozilla folks rightly pointing out that, contrary to what we recommend for Firefox, our own logos aren’t DFSG-free. Branden Robinson has started a wiki page to develop the policy. The current proposal is to retain two trademark policies – an open use policy for the swirl logo, that can be used by anyone to refer to Debian, with the logo released under an MIT-style copyright license, and left as an unregistered trademark; and an official use license for the bottle-and-swirl logo, with the logo being a registered trademark, but still licensed under a DFSG-free copyright license. The hope is that we can come up with at least one example, and hopefully more, of how to have an effective trademark without getting in the way of people who want to build on your work down the line. Keynote address at OpenFest. Though obviously too modest to blog about this himself, Branden Robinson is currently off in Bulgaria, headlining the fourth annual OpenFest, speaking on the topics of Debian Democracy and the Debian Package Management System. New Policy Team. After a few days of controversy following the withdrawal of the policy team delegation, a new policy team has formed consisting of Manoj Srivastava, Russ Allbery, Junichi Uekawa, Andreas Barth and Margarita Manterola. Point release of sarge, 3.1r4. A minor update to Debian stable was released on the 28th October, incorporating a number of previously released security updates. Updated sarge CD images have not been prepared at this time and may not be created until 3.1r5 is released, which is expected in another two months, or simultaneously with the etch release. Debian miniconf at linux.conf.au 2007. While it may technically not be supposed to be announced yet, there’s now a website for the the Debian miniconf at linux.conf.au 2007, to be held in Sydney on January 15th and 16th (with the rest of the conference continuing until the 20th). This year derived distributions are being explicitly encouraged to participate, so competition is likely to be high, and it’s probably a good idea to get your talk ideas sorted out pretty quickly if you want them to be considered!

I was in a multiple-car accident yesterday. I've been having to tell this story a fair amount in person and on IRC, so I thought I'd blog about it. Short version: it was a fender-bender. I'm doing fine, nobody was hurt, Michelle wasn't in the car, and 75% of the cars involved were driven away from the scene — including mine, by me. Want the long version? Well, I'm gonna tell it anyway. I had just pulled to a stop at a traffic light, heading northbound on Keystone Avenue where it intersects 106th Street, in Hamilton County. The line of cars at the light was pretty long, and people love to try hauling ass on the stretch between 96th Street and 106th. Apparently the person behind me was one of them. The line of cars stopped in the left lane (where I was) at the light was pretty long, and much shorter in the right — the cars over there were still moving at a good clip. I looked in my rearview mirror, thinking "if someone's trying to match pace with the cars in the right-hand lane, they're gonna need to brake pretty hard to stop." It was about 1815, so it was starting to get dark. A pair of headlights approach. Fast. Oh boy. I don't stop right up on people's tails, so if I'm hit, hopefully I won't go into the car ahead. I look forward again. Yeah, there's some room here. Screech. I didn't tense up; I felt a strange sense of calm and curiosity, as I'd never been in a car accident before. I bought my car, a Volkswagen Golf, in part because of its fairly good safety ratings. It has lots of air bags, and I always use a seat belt. Plus, in this instance I figured I wouldn't get hit a high speed. "Strange Deja Vu" by Dream Theater, from the Scenes from a Memory CD, was playing. Normally I listen to All Things Considered while commuting home, but I was annoyed because when I got in the car, I heard Nina Totenberg signing off a report, which means I'd just missed some Supreme Court coverage. Damn. Anyway. BONK. I got hit. Ouch. My teeth had chomped together too hard. Maybe they should install rubber mouthpieces in the doors of cars so you can grab them right before a crash. You know, car crashes never sound like the stock sound effects that have been around for about 50 years. I guess that's because they build cars to crumple these days instead of act like steel shrapnel bombs. Damn that Ralph Nader. My wreck doesn't sound cool and stuff. And I get to walk away, well, get back in the car and drive away, instead of my wife collecting on my life insurance policy. But I digress again. A middle-aged woman in a Honda Civic skidded into me, and knocked me into the Buick Park Avenue ahead of me, which in turn tapped the minivan ahead of him. I blinked a bit and tried to reorient myself, and then turned off the CD player. We all got out of our cars. The woman in back was very distressed, and immediately and repeatedly said the thing your insurance card tells you never to say after an accident. Oh well. Being a middle-aged woman, she'd probably have to wreck a school bus full of children — twice — before her premium would go up. Mine, on the other hand — we'll see. Called 911. Reported the incident. Tried to call my wife, but she decided not to answer. I later found out she was gabbing it up with my mom. Isn't it nice when your wife gets along with your mother? I COULD BE BLEEDING OUT ON THE COLD ASPHALT, BUT YOU TWO JUST KEEP ON TALKING. Michelle and I have the same model of cell phone, and we have call waiting with caller ID, so I know she knew it was me. Anyway, I try a couple of times, then give up and leave voice mail. Turns out the guy in front, in the minivan, was a Deputy Prosecutor for Hamilton County. He said something about being experienced in car wrecks, but I don't clearly remember it. Anyway, perhaps in part because he decided he was only "tapped" and didn't need to file an insurance claim, and perhaps in part out of professional courtesy, when the cops showed up, they let him go very quickly, so I didn't get any of his information. Everybody was fine, polite, and decent about the whole thing. The couple ahead of me, whom I got knocked into, didn't have their insurance info on them (or maybe this is a euphemism for "don't have insurance"). But, except for the deputy prosecutor guy, who was outta there, we all traded names, addresses, and phone numbers. I hope the Debian Project doesn't mind that I used my Debian Project Leader business cards for this purpose. These people (and the Carmel Police Department) now have my GPG key fingerprint. Uh oh. Anyway, that's about it. Appointment tomorrow with the insurance agent, to get help filling out INDIANA OPERATOR'S VEHICLE CRASH REPORT, State Form 38656 (R6/7-91) Stock 301 Effective 1-92, which has to be filed with the Indiana State Police within ten business days, or my driver's license will be suspended. Aww, yeah. Gotta move fast, because on Friday I leave for Mérida, Spain, to attend the 2nd Annual Open Source World Conference in Extremadura. Also have an appointment with the claims adjustor tomorrow. Then I'm hoping to just leave my car at the dealership so they can work on it over the week when I'm gone. My wife and my mom, those talkative two from a couple of paragraphs ago, will be coming along with me. My mom's got a jones to visit Spain, and I've had a jones to take my wife to Europe. We'll have a couple of extra days to see what Spain is like — I'll be there from 22 October to 28 October. I hope one day to visit Barcelona and hang out with some proper anarcho-syndicalists.

The Constitution of the Debian Project specifies a decision making process known as "delegation", which the Debian Project Leader can use to spread decision-making authority throughout the Project. Historically, this power has been underused (including by myself), particularly in areas of infrastructural administration. This turns out not to be due to any lack of motivation or desire to do so on the part of past (or present) Project Leaders. I have learned that part of the problem with delegation is that the Constitution's concept of it is poorly understood by some of our developers, particularly those who are not native English speakers and for whom the dry legal language in the document is heavy going. Here, then, is my attempt to put delegation in a nutshell:

1. Any authority not otherwise assigned by the Constitution (e.g., to the individual Developer, Technical Committee or the Secretary) can be exercised by the Project Leader, either directly or through delegates.
   (5.1.1, 5.1.2, 5.1.3, 5.1.4)
2. In the case of "approving or expelling Developers or designating people as Developers who do not maintain packages", this authority must be exercised by a delegate, and not by the Project Leader directly.
   (8.1.2)
3. The Constitution suggests that there may be other powers which the DPL may not directly wield, and which he or she must delegate instead, but apart from the above, none are enumerated in the Constitution.
   (8.1.2)
4. The DPL can make two types of delegations: a particular decision, or an ongoing area of responsibility.
   (5.1.1)
5. If the DPL delegates a particular decision, he or she cannot retake responsibility for the decision personally, but can re-delegate it to someone else.^[1]
   (5.1.1, 8.2)
6. If the DPL delegates an ongoing area of responsibility, he or she can withdraw that delegation.
   (5.1.1)
7. The DPL can add or remove delegates at his or her discretion.
   (8.2)
8. The DPL cannot make someone's status as a delegate dependent on the outcome of a particular decision that they make within their authority as a delegate. That is, the DPL cannot say, e.g., "If you drop non-free from ftp-master.d.o, you no longer get to be a package archive administrator."^[2]
   (8.2)
9. The DPL cannot override the decision of a delegate once the delegate has made it.
   (8.2)
10. The Developers can override the decision of a delegate via a General Resolution with a simple majority.
    (4.1.3)

Let me know if you feel this is an inaccurate characterization of the Constitution; I've done my best, but I'm not infallible. Also, I'd like to hear your thoughts on whether you think delegation is a tool that I should use more. I appreciate your comments. ^[1] One might argue that the prohibition on rescinding delegation of a particular decision is tied the individual(s) to whom it is given, rather than the decision in question. This is important if the person or people to whom the decision is delegated prove unable to make it. This is another variant on the old "what if Linus (Torvalds) gets hit by a bus?" problem. One developer has told me that my interpretation poses a different threat, however: "It looks like you're going to decide this one issue in a way I don't like, so I'll take it away and give the decision to someone who will decide it the way I want to." Why a Leader would do this, or how he or she could expect to get away with it, is not clear to me, but this scenario is not impossible. If this ever proves to be a non-hypothetical problem, I would ask for the Project Secretary's interpretation of the Constitution. ^[2] In practice this is hard to enforce perfectly, especially if the DPL keeps his or her reasons for dismissing a delegate to him- or herself. Personally, I interpret this to mean that if the DPL attempts to sway or threaten a delegate with the loss of their position if he or she does not do the DPL's bidding on a particular issue, that the delegate should bring the DPL's misconduct to the attention of the developers. Originally published 2005-11-15. Updated 2005-11-15 to fix instances of awkward (and in one case, backwards) wording.

I have published the slides to my DebConf 5 presentation, WTFM: Write the Fine Manual. An example manpage (PostScript output) and script for finding executables on your system that are missing manpages are also available.

A few days ago, I issued my third report as Debian Project Leader. I do make corrections to my reports as feedback comes in (for a week or so), so if you read anything that made you blink your eyes a few times on the day I first posted it, you might find it worth a second look.

make World is what you type when you want to do a full build of the X Window System sample implementation. With significant embroidery, it's also the heart of the xfree86 and xorg-x11 source packages' debian/rules files. Today, I got a successful package build of the xorg-x11 SVN trunk. One needs new versions of the render-dev and libxrender-dev packages to do so; the former has been accepted into unstable, and the latter is currently in queue/NEW. There's a bit of housecleaning and QA still to do before uploading to experimental, but the worst of the hurdles are cleared, and that's a mighty good feeling. Hopefully David Nusinow returns from his "forced vacation" soon. :-) There are many things to catch up on on the DPL front (and a few others), and I owe everybody an explanation of why I've been so quiet lately. Strapping on my boots to give xorg-x11 a kick in the ass has been part of it, arena-style bureaucratic combat with the Brazilian Consulate General's office in Chicago was another, and my wife's recent re-hospitalization was the most worrisome. I lost out on my trip to FISL 6.0 in Brazil, but kept my wife, which is, I think, the preferable outcome if I could only have one of the two. (Those of you who are members of SPI can also check out a report from me on recent donations and bank activity.) It's satisfying to make progress on a couple of fronts even when you're fightning an n-front war — it beats the hell out of losing ground. Yup, today was a good day to make World.

It was inevitable, really... With the merger of the uClinux project's code into the official Linux kernel as of version 2.6, and the against-all-odds development of the EMILE boot loader, one might say this day was destined to come (I'd have more details from a mailing list, but unfortunately its archives appear to be broken). Laurent Vivier, I don't care what the Vancouver Prospectus has to say about your work — you rock. :-)

I'm probably the only person who ever thinks like this, but what the heck. I recently found myself thinking (itself a noteworthy occurrence)...I've started a what turns out to be a long-running process at a shell prompt and I don't want to visually monitor it. It didn't occur to me that it would take a long time when I started it, and it would be nice to have audio notification of its completion. The problem is, it's already running. Of course if you knew it was going to take a long time when you started, you could have done something like this: long-running-process && xmms $HOME/music/song.ogg. Let's say you didn't exhibit that much foresight. Traditional Unix process management primitives exposed via the shell come to the rescue.

$ long-running-process

Damn, this is taking a while... <CTRL-Z>

[1]+  Stopped                 long-running-process
$ bg
[1]+ long-running-process &
$ wait %1 && xmms $HOME/music/song.ogg

Voilà; I can go back to occupying myself, and when the music starts up, I know my job is done — and I didn't have to kill it and start it over. Once in a while, that's an important consideration. By the way, if you try to wait on a stopped job, you're helpfully told how lame you are:

-bash: warning: wait_for_job: job 1 is stopped

...and the music starts to play even though your job isn't finished. So don't forget to background it first. :) Futhermore, this usage of wait appears to be standard. In Debian, both bash and ash (a.k.a. dash) support both process IDs and job IDs as operands to wait. zsh probably supports identifying the job by its mother's maiden name as well, but I haven't tried that.

I have issued my second report as Debian Project Leader.

Via FindLaw: Defense lawyers sought leniency for Pfc. Lynndie England at a hearing Tuesday to determine her punishment in the Abu Ghraib prison abuse scandal, with a psychologist testifying that the reservist was oxygen-deprived at birth, speech impaired and had trouble learning to read. The most persuasive indication of her mental incapacity, the defense expert continued, was that England volunteered for the U.S. Army in 2001, after George W. Bush assumed the Presidency.

On 21 August, Don Armstrong, a Debian developer, accepted my offer to serve as my delegate in handling trademark issues vis-à-vis the DCCA. As an employee of a DCCA member company, I found it wise to avoid the perception of a conflict of interest. I should stress that any such perception would merely have been conjectural, however; at no point have I been asked by anyone to put my thumb on the scales, as it were, and deal with the DCCA or any of its member organizations in a preferential way. It is widely understood within the Debian Project that our existing trademark policy, originally formulated in 1998, is too vague, and has not scaled well to suit Debian's much greater degree of success and market penetration (on its own, and in the form of derivatives) seven years later. However, grappling with the issue has proven challenging for Debian's membership. I believe this is mainly because the Free Software hackers that comprise our organization have tended to self-educate to a far greater extent on copyright law, and even patent law, than they have on trademark law. Recently (within the past year or so), Debian gained access via its U.S.-affiliated charitable organization, Software in the Public Interest, Inc. to a pro bono legal counsel who understands the Free Software culture. Debian's difficulty with trademark management is not unique — we have been on the other side of this problem when dealing with the Firefox and AbiWord trademarks, since we customize the codebases of these software projects in our GNU/Linux distribution, but ship them with their names (and logos) intact. It so happens in these cases that the originators of the software (who hold the trademarks) approve of our modifications. One of the essential pillars of software freedom, however, is the user's right to make modifications that the authors or rights-holders in the software may not agree with. Free Software hackers can feel, with some justification, that it is misleading to uphold the freedom of a work on the one hand (by using a copyright license such as the GNU GPL), and take it away with the other (by asserting a trademark on some essential aspect of the work, such as its name). It is true that a work can be renamed, or descriptive text changed, to identify itself as distinct from an "official" version of the work, but this in turn, it is feared, can damage perceptions of the work through at least two mechanisms. Firstly, disclaimers about unofficial status may be unnerving to users who aren't schooled in the vagaries of trademark law, in which — at least in the United States — you are expected to aggressively defend your mark lest you lose a future infringement case you bring against a well-heeled defendant. Users may mistake strident proclamations of unofficial, unendorsed status in a piece of software as a warning that it is unsuitable for use, or has known severe flaws. Secondly, aggressive use of trademarks, or even just the tension observed above between giving with a copyright license and taking away with a trademark license, may lead some distributors to rename a work, obscuring its origins to the casual user. This can happen pre-emptively, before a distributor even knows whether the modifications they have made (or think they might make in the future) have met with any objection from the trademark holders in that work. The "freedom to fork" (i.e., make a derived version unendorsed by the original author) is an essential part of Free Software, and while Free Software hackers' sense of community generally leads them to eschew forking in favor of compromise and consensus, occasionally a fork ends up growing the userbase or improving the overall quality of the Free Software landscape. A hacker may fear that brash trademark assertions by an author constitute mere lip service towards the freedom to modify the work without changing its name, and may be tempted to fork it, leaving the trademark encumbrance behind. Even among those who do not guard their software freedoms quite so jealously, the fear can exist that a simple difference of opinion over some technical programming detail, such as choice of sorting algorithm or graphical toolkit, will escalate to the point where the trademark license on the work (implicit or otherwise) is withdrawn. This is the inverse of the previous situation — instead of a modifier choosing to fork a work, the original author of a work (or, at any rate, the holder of the trademark associated with it), can force the modifier to fork. The dilemma this imposes upon the people creating the modified versions — revert your existing change or be legally compelled to make an additional one — can rub people the wrong way. When forking occurs, for whatever reason, and even in the relatively benign case of "rebranding" to remove legally protected marks, the threat exists that the competitive strength of the corresponding software will be diluted. Imagine if each of four major GNU/Linux distributors rebranded their version of Mozilla Firefox, calling it instead things like "Lizardfox", "Hatfox", "Swirlfox", and "Hearstfox". How many users would deduce that the web browsers in question were all "really" Mozilla Firefox, each one with a fig leaf placed delicately over it so that the legally-minded types at the Mozilla Foundation and the distributors could wink at each other? Even the somewhat savvy GNU/Linux user may be more confused than one might expect, given that other names used for Mozilla's suite of applications include Sunbird and Thunderbird, yet there is an independent Free Software project called Firebird, which was established prior to the Mozilla Foundation's adoption of its product naming scheme. "What's in a name?", you may ask. They're important because they are simple labels we can use to refer to Free Software success stories. There's a lot of Free Software to talk about; the phenomenon of copyleft does much to ensure a competitive culture. It's difficult to achieve an unnatural monopoly in this environment, because anyone who steers a software project in a direction the users don't want to go has to cope with the prospect of seeing a group of those users organize their own community based around a derived version that does what they want. The hypothetical hydra-headed Firefox situation described above, however, is an example of false competition, because the distributors were compelled to distinguish their Web browsers for legal, rather than technical, reasons. In actuality, Mozilla Firefox is a good example of what's right about Free Software, not just because of its licensing but because a web browser is a familiar concept to nearly every computer user today. Free Software's early successes were more esoteric — GNU Make, the GNU Compiler Collection, the GNU C Library, GNU Emacs, and even the Linux kernel are not pieces of software that the general user can easily conceptualize. It is beneficial — to say nothing of convenient — to refer to the leading freely-licensed web browser as "Mozilla Firefox" rather than "a suite of mostly-compatible, similarly-named Web browsers shipped by the various GNU/Linux distributors". Those who seek to foment confusion and FUD about Free Software would doubtless capitalize on such a situation. These issues are challenging but not insuperable. A coherent policy will enable the community to establish a set of common practices, whereas now there are few conventions in the trademark arena. Ultimately, it is my hope that Debian will be able to promulgate a trademark policy that not only satisfies our needs, but serves as a model for others. To establish a successful policy, I suspect we need to build one up from basic concepts, and formulate explicit answers to fundamental questions.

• Why even have a trademark? Let's understand what protections the law affords and determine which, if any, are applicable to our endeavors. In the U.S., trademarks are managed by the federal government (rather than the states), and regulated by Title 15, Chapter 22 of the United States Code. International treaties result in trademark law being roughly similar across most jurisdictions in the developed nations, but there could exist important differences that we should learn about.
• What level of Debian involvement should be necessary for an "outside" organization to use our mark without a fuss from us? Should there be any situations where people essentially have an automatic trademark license, or should we use trademark law as an instrument to encourage (or compel) anyone trading in our name to contact us? We need to consider small-scale garage-based redistributors who simply move physical copies of our official ISO images as well as commercial derivative distributions.
• Is it feasible to apply the copyleft concept to trademarks? That is, is there some way we can turn the restrictive aspects of trademark law into a kind of compact that upholds the freedoms of a sharing community, while penalizing the activities of those who would prey upon that community?

Originally published 2005-09-14.
Updated 2005-10-15 to add licensing in comments.

Thanks to the hard work of Debian's Release Management, Archive Administration, and Security teams, as well as Debian's developers generally, Sarge has now been frozen (don't let the modest title fool you). ;-)