In a recent post I mentioned that my scalp is adorned with 14 titanium staples. While some may think that I have them because an odd accident incurred during my recent move, I have them because I live in mole-ville and some of them were causing a small disturbance in the hood. Living here means I have a lot of moles on my body and well, these little masses of brown pigment, while they can be somewhat attractive, and unproblematic, can be unruly creatures that can change on short notice and cause a lot of problems. Now I usually don’t blog about personal things like my moles, but I thought it is worth writing about this as a public service announcement… So if there are any other readers who live in a crowded mole-ville, this is little reminder to check up on your moles, sooner than later. I have never had a problem with my moles and there is no history of problems in my family but I do have more than the average number of them. In fact, anyone who has met me knows this because they are all over my face, and there is one distinct one, under my left eye that is shaped like a tear, and often mistaken for dirt, more graciously as a tattoo, and most oddly as that black stuff that football players smear under their eyes. About a year ago, after one of my friends was diagnosed with melanoma (thankfully he is ok), I started checking my moles more frequently and did a full check at the dermatologist. All was ok and when I went to another dermatologist in February, all looked good. Then this summer, as I was running my hands through my hair, I felt a mole and started obsessing over it. I was pretty sure I did not have it a year ago as it was not on my chart and if was, it was probably flat and since I could feel it, it had changed, which is not a good sign… I was traveling most of the summer and it was first in South Africa where I had it checked in a fancy dermatological office in Durban. They dermatologist took a close look and said, looks fine but have it removed because you can’t track it. That made me feel a lot better so I enjoyed the rest of my time there and then as soon as I got back I saw a RN at a dermatology office in NJ (it is near to impossible to get a derm appointment without a month’s wait in the US but since they had RNs, I could see someone quick.. More on this in a second). This person also confirmed what the dermatologists in SA had said but also decided to remove it because I could not track it. A week later a pathology report came back that showed it was dysplastic and that the cells were changing, and thus considered abnormal. Some dermatologists consider this as pre-cancerous, some don’t, but it seems to be that there is more likelihood that this type of mole can turn into cancer. So the “treatment” is a full excision where they remove 1cm all around the mole. I got word of the report around the 8th of August and the only time they could fit me in for surgery was the 25th, a day after I was supposed to leave for Edmonton, which changed my moving plans (and explains why I arrived here so late, making getting my stuff complicated given school is in session and parking is tight). I then scheduled an appointment for a a full body check and removed another mole that once biposed was confirmed as dysplastic and though not as abnormal as the other, the recommendation was to also remove the surrounding dermis. Now, when I called the surgical coordinators, they could not fit me in another time slot to expand my appointment for 2 surgeries because they were “full” even though I explained I was moving away from the U.S. They said that it was up to the surgeon to decide whether to operate on the second area and since I was leaving to Canada the NEXT day, he would probably agree but no guarantees.
So of course, I wanted the stuff out because I was not sure how to go about getting the procedure done in Canada. My insurance does kick in the second I sign up and there is no Bull-Sh*t pre-existing clause stuff here but because I could not get an appointment in time, I would probably have to go to a medicenter that performed these operations and not all do. Though I was confident I could get it done eventually, it would take a lot of inquiring and after a 7 day drive and all that follows a big move, I decided it was not the thing I wanted to do. So I got to the office early on the 25th and one of the first things that comes out of my mouth when I saw the nurse was that I was leaving the next day to Canada and I did not know when I could get care there. Of course the first phrase that pops to mind for many Americans when you say Canada and health care is “socialized medicine” which most people in the U.S. associate with bad healthcare and long waits. Now on the one hand, I have to admit I, to some degree, share those fears, which is one of the reasons I wanted the extra dermis removed asap. On the other hand, I think that the claim is a big fat red herring because in fact for many Americans, they *do* have to wait a long time for many procedures (dermatology is classic for this, and even my first procedure took a 3 week wait and if I wanted to schedule the second one, it would have taken 5 weeks) or worse, they have no insurance, which KEEPS many people from going to a doctor in the first place. So American medicine is not necessarily “fast track” and in a dual sense: in the literal sense because HMO healthcare is like socialized medicine with capitalist prices, and because many people without insurance also probably avoid the doctors until they are in bad shape… And even though I have insurance, they would not pre-approve anything as I am in some awful pre-existing clauses because my insurance had lapsed for 2 months this year. And even though I have never had a problem with a mole in my life and did not even see one doctor in the 6 months before I got my insurance (which is when the pre-existing diagnosis would pertain to) and even saw a dermatologist in my HMO network in February who found nothing wrong, the insurance wants to make sure to add as many roadblocks as possible in the hopes of never paying up. Great. Now I am very grateful the nurse at the derm office proceeded to get the doctor to perform the 2nd surgery and he also was more than ok to do it. I wanted to give them big fat hugs after the procedure but you know, you just don’t do that type of move in your blue robe after the surgery. Before the surgery I naturally “hit” the net to gather a lot of information on moles, cancer etc… I join the millions around the world who–for better or for worse–use the Internet to supplement (some I am sure supplant) their doctor’s medical advice. In fact, a key part of my second project on psychiatric survivors looks at how patient communities are building a sphere of amateur but expert medical knowledge exchange. It is an enormous sphere of vibrant peer-to-peer knowledge production but one that many are uncomfortable portraying as such because it involves a lot more risks and ambiguities than exchange knowledge about, you know, how to get your blue tooth working…. But if we bracket the realm of alternative remedies (which admittedly is a HUGE part of this type of exchange), I think in fact, patients are pretty savvy and are engaging in risk-averse behavior by going on the net and illness forums. A lot of what is exchanged are warnings about side-effects, detailed accounts of experiences with procedures, and yet a lot of red flag raising that one’s experience may not match another persons but may be still helpful. It is a lot of information that often may be missed during the exchange with the doctor and derives from what is another type of expert knowledge: one’s bodily experiences with medicine, illness, and other related procedures. But I have to say that when researching melanoma and moles on the Internet, I was somewhat stumped. There is just too much variation out there to make informed judgments and abnormal but non-malignant moles have the same characteristics as melanomas. The Internet, in this case, seemed helpful to provide some baseline information and then just served to freak me out more than necessary so I turned away for the time being. For now I am just adjusting to the staples, which come out in another week. The procedure did not hurt much but the first week after the removal my head was much more sore than I had expected. Not so fun when on a marathon road trip, which is finally over!

I think I have reduced the "SQL pony" problem to something manageable, by identifying the error in my thinking. To recap: I want to store bits of public, semi-public and private data about people in a database, with the private data living on another host for security. The error in my thinking was that referential integrity would be needed in both directions; in my case, it is however sufficient to ensure it in one direction, which is the private data pointing at the rest. This means I can (or should) not delete from the non-private database except when I also have the private database accessible; this is an acceptable restriction as the server is not supposed to delete stuff on its own anyway. So in essence, I just need something that can combine the local (private) and remote databases for me. I think I should probably look at some ODBC stuff here; however writing an SQL query splitter that builds a local and a remote query doesn't sound too hard either.

Rapha l: I mostly agree with your post. Having something closer to a steering committee seems saner than having a single leader for projects such as Debian, due to a single person not able to fully follow everything such a large and diverse mass of people works on. I was among the supporters of Project Cabal^W^Wthe DPL team experiment, and of our 2IC role.
However, you state that a release should determine the time a DPL team (call it committee, cabal or whatnot. I like the title, in fact: "I am an Elected Member of the Whatnot of Debian". Whee!) - I disagree on this one. Like the fact DPL is not chosen for technical but for political work - The DPL (and so should the team) mediates between parties, brings order (controversial, sometimes) to discussions, pushes forward some controversial decisions, reports on the general status of the project - That should be the Whatnot Team work (hmmm... Should I file for trademark on that name?).
In any case... Were we to change our model towards this formal DPL team thingie, I advocate slow changes over strong ones - I prefer a board like this one to be replaced one person at a time, at rates not more frequent than one month, and having them there for a fixed amount of time.
Of course, this would lead to a mess on managing the voting, and each vote being less important for the developers. Besides, we have had DPL elections with as little as two candidates, and topping at seven IIRC - Do we have enough people interested in being responsable for our administrative chores? Would this scheme work? Or would it lead us closer to administrative stagnation? Quoting our not-very-beloved-but-anyways-wise dictator (for the 1876-1910 period) Porfirio D az: "If I want something done, I do it myself. If I want it to take some time, I appoint a delegate to do it. If I don't want it ever done, I form a committee".

When looking at 372148, I found out that my maintainer scripts diagrams had the same bug that Policy currently has. Also, these diagrams used to document a bug in dpkg, regarding the state a package was left when removed or purged; which was fixed long ago, but I had never had the time to update them accordingly. Tonight, finally, I've updated them. And I've also made my test-suite package much more tidy, so that now I can publish it for anyone to grab it, and use it to test which maintainer scripts are called in some particular case. The dia sources, the png images, and the packages I used for the tests are all available here.

So, last week was a bit bumpy since I was sick for a couple of days, and then had a power outage on Friday and Saturday, thus not being able to keep up with my daily RC bug fixing, but I've been catching up since then. I've uploaded patches done by Arjan Oosting, for packages that wouldn't compile with autoconf2.6: #379812 (kde-style-polyester), #379813 (kxmleditor) and #379815 (klog).

I uploaded a patch by Mart n Ferrari for lilo: #374477 (use MAKEDEV instead of mknod at postinst), and another patch by Mart n for courier-authlib #378571 (fixing the permissions of /var/run/courier/authdaemon).

I uploaded a patch by Andreas Jochens for ntlmaps: #379700 (fixing the build-dependency). A patch by Luca Bruno for predict: #379495 (fixing a change of location of forms.h). And a patch by Mike O'Connor for stardict: #379152 (fixing a misuse of size_t that made it fail in 64bit architectures).
Stardict had a problem with rpath that made me get to know the LIBTOOL_IS_A_FOOL hack, and I had to apply that, so that the binaries were not screwed up.

I also uploaded a fixed version of yacas, that included patches from Arjan Oosting (fixing #379261 and #379895) and Braun Gabor (fixing non-RC #295413). However, it's not like the only thing I've done is upload patches done by others. I've also done some patches myself:

• #379275, fixing fillets-ng's FTBFS.
• #379486, fixing a bashism in cbuild.
• #379200, changing PWD for CURDIR so that sudo works for building bluez-utils.
• #377781, fixing monotone so that it builds with the latest gcc, although it took a new upstream release for it to build in hppa.
• #378173, adding some checks for NULL, so that the new libsdl1.2-image does not make programs segfault
• #381248, dropping PAGE_SIZE in favour of sysconf(_SC_PAGESIZE) in libsdl1.2 so that it builds in powerpc

The amount of bugs currently affecting the next release is 247. It's not a secret that we are a bit behind the schedule (we should be at less than 200 bugs by now). But it's also totally possible to get back on track if we work together on fixing the current bugs and we stop uploading unneeded new releases that trigger new transitions.

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.

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.

Courtesy of FindLaw Legal News: WASHINGTON-President George W. Bush said Wednesday that Harriet Miers' religious beliefs figured into her nomination to the Supreme Court as a top-ranking Democrat warned against any "wink and a nod" campaign for confirmation. "People are interested to know why I picked Harriet Miers," Bush told reporters at the White House. "They want to know Harriet Miers' background. They want to know as much as they possibly can before they form opinions. And part of Harriet Miers' life is her religion." Courtesy of the United States Constitution, Article VI: ...all executive and judicial Officers, both of the United States and of the several States, shall be bound by Oath or Affirmation, to support this Constitution; but no religious Test shall ever be required as a Qualification to any Office or public Trust under the United States. Oh, well, just so long as it's a criterion, not a test. I mean, it's only essential, not a qualification or something, right?

Since I got back from the Oldenburg Linux Developers' conference, I've had my attention on our security infrastructure. Despite only being there for one and a half days thanks to a badly delayed trans-Atlantic flight, I found the conversations and collaborative spirit heartening. The bad news is that what I had planned for a writeup got rendered obsolete soon after I returned to the United States. Things have been changing rapidly, but mostly for the better. We've got three machines in the DNS rotation for security.debian.org now, which is superior to the one we had before (you can use the command dig security.debian.org to inspect the DNS record). My thanks go to our security and system administration teams for recovering from the recent overload problem provoked by an xfree86 package security update. Being somewhat familiar with that package, I can understand how its large size combined with Debian's ever-growing userbase starved the security host of bandwidth. Secondly, while I was in Oldenburg, Joey Schulze gave me a lot of insight into what a challenge one particular package is — the thing sucks up at least half of his time, dwarfing all other stable security update efforts. You've probably guessed that this package is the Linux kernel. Due in part to its success, and in part due to OS kernels being inherently attractive exploitation targets, the Linux kernel is getting a significant amount of scrutiny from a security perspective. Taking Red Hat Enterprise Linux as an example, we can see two advisories in the past two weeks: one on 28 September and one on 5 October. The one on 28 September addressed eighteen (18) different vulnerabilities as catalogued by MITRE's CVE project, and the one on 5 October — that's one week later — addressed fourteen (14) vulnerabilities, of which eight (8) were distinct from the previous advisory. (There was some overlap because the earlier advisory was for Red Hat's Linux 2.4.x kernel series, and the latter was for the 2.6.x series.) Those Debian developers who have ever handled a security vulnerability in one of their own packages can likely imagine the labor burden this is. Then reflect that Debian ships and supports a lot more Linux kernel trees than Red Hat does — this only magnifies the problem. The good news is that a team of developers focused on stable kernel security updates has been established. One of its members said to me today that he has seen a "very positive increase in kernel-related security activity". It is too soon to declare this problem resolved, but I perceive no lack of talent or dedication on the part of our developers. I am there to assist them in resolving the organizational and workflow issues so that our users can see the fruits of their energy directly. Similarly, I'm interested to see how the security.debian.org round-robin arrangement holds up after a reasonable period of real-world loads, particularly since I expect kernel package updates to sock the machines about as badly as an X Window System update. These issues are not over and done with, so an announcement declaring these problems vanquished would be premature. At the same time, the developers and users at large need to know whether or not people have their attention on them. I am wary of leaders or managers who declare issues resolved too soon, or proclaim optimism that later turns out to be unfounded, and have sought to avoid this vice. I apologize if I have tacked too far in the opposite direction. I perceive progress in this area. Let me know what you think, what you need to see, and by what metrics you measure progress and accomplishment on the security front. You can reach me at leader@debian.org (the address is already blitzed with so much spam there seems little sense in obfuscating it). (After getting some feedback on this entry, it's my intention to post it with any applicable revisions to the debian-devel-announce mailing list; please take this opportunity to "patch" this "beta", if you're so inclined.)

Short version first: those in Oldenburg who are expecting me to arrive at the Bremen airport on Friday afternoon, don't. Expect me on Saturday at 11:10 instead, assuming there are no further setbacks. I got to the Indy airport today in time for my flight, except my flight was going nowhere fast. "No problem," I thought to myself. "I have nearly a three-hour layover in Newark. They can dicker with this flight for quite some time, or I can get switched over to the flight on the commuter jet that Continental also has going to Newark this evening." Silly me. My flight has a "wing indicator light" problem — that's what the gate agents called it, shrewdly deducing that a pilot otherwise has no way of determining whether the lifting surfaces are still attached to the aircraft — that amazingly takes hours to resolve, and the other flight? Well, Continental's headquarters are in Houston, and apparently some of their employees startlingly decided to evacuate their families out of the expected path of Hurricane Rita instead of showing up to work in Indianapolis to be the flight crew. Or something like that. So instead of getting to switch over to the flight that would get me to Newark safely in time to catch my connecting flight to Paris, the airline shunts all those passengers onto my flight. So we take off about 3 hours and five minutes late, and when I land in Newark, there's nothing left of my flight to Paris but wing tip vortices spiraling out over the hypodermic-syringe-strewn New Jersey coast. Apparently airports both in the U.S. and Europe have a problem with flights leaving or arriving in the middle of the night, so the soonest I can leave for Europe is now 1845 on Friday. This means I'll miss nearly a full day of the conference, which I was only going to be at for 2.5 days anyway. Joy. Oh, and they also close down baggage claim at 11pm (or five minutes before you land, whichever comes first), so my checked bag which couldn't make the same flight I couldn't is now being held hostage somewhere in the bowels of Newark Airport while I sleep at the Howard Johnson's in a room that one dare not view in ultraviolet light. Well, technically, this hotel is joint venture with Holiday Inn, an enterprise which no doubt serves the sole purpose of frustrating class-action liability suits by people who contract scabies in the course of their stay. I don't even know if my beloved dismantled Quadra is in better accommodations, or if my machine, tortoise.deadbeast.net, stuffed into a suitcase and crudely protected with towels and masking tape, has been obliterated with patriotic fervor by the TSA, swinging their hammers to pulverize it. I guess I could be in worse places, like Galveston. Any DDs in New York wanna give me a wake-up call in the morning and meet for lunch? (I'm at +1 973 589 1000 x217.) If not, I was thinking I might try to go see the Statue of Liberty in the late morning. I've been in the NYC area twice before but never went to see it. Air travel sucks. Maybe this is the real reason, unadmitted to myself until now, that Contact resonates with me. I can almost forgive Robert Zemeckis for that brown smear he did with Tom Hanks three years before. Then I remember that other brown smear he did with Tom Hanks three years later. Okay, I won't blame Hurricane Rita or even Continental Airlines. I'll blame Robert Zemeckis instead. :-P I'm okay to go... I'm okay to go...

On Friday afternoon I'll be arriving in Oldenburg, Germany, for the eleventh annual Linux developers' conference. Historically, this conference has had a strong focus on non-x86 ports of the Linux kernel, boot loader development, the GNU toolchain, and so forth. At long last, it looks like this may be my opportunity to get my Macintosh Quadra 840AV out of mothballs and back into commission, thanks to Wouter Verhelst. I should be able to fit it into my luggage if I don't bring many clothes... :-) This year, however, in addition to that, a couple of mini-conferences are being piggybacked onto the Oldenburg meeting. These include the GNU Classpath and Debian Java DevJam and the Debian Security Summit. The Java programming language is a divisive issue in the Free Software community, and has a degree of controversy that sets it apart from the usual language wars. The dominant factor in this controversy stems from what Richard Stallman refers to as the Java trap; with the specifications controlled, and the reference implementation kept unavailable on DFSG-free terms by, an industry consortium dominated by large corporations, a Free Software hacker might fear that using Java will consign them to either having to compromise their principles by using non-free class libraries (for example), or being doomed to chase the taillights of standards that could conceivably be tailored to disadvantage competitors. (Java is not alone in this respect; many people fear that Microsoft's .NET, despite being openly standardized through ISO/IEC, will in actuality be completely controlled by Microsoft.) Despite this peril, Java is attractive to GNU/Linux-using organizations. The Free Standards Group, developers of the Linux Standard Base, has received inquiries about a Free Java standard and implementation from organizations already committed to GNU/Linux. In my job, I've encountered an interest in Java from several customers and prospects. Intriguingly, these institutions are, by and large, very much aware of the Java Trap. They like the language, and are not strong advocates of Free Software, but they too are worried about vendor lock-in. They've seen the success of community-driven development as GNU/Linux moves from strength to strength, claiming territory formerly held by Microsoft and proprietary versions of Unix. Even if I can't persuade a customer to adopt a Free Java stack, I can exhort them to only code against Java standards that have seen a free implementation. That way, their development bets are hedged against any "madman theory" of the controlling vendor. Furthermore, this way they only code to standards that are seeing independent implementations, and they leave their engineers free to switch between varieties of development kit. Engineers like flexibility because it enables them to work more efficiently; sales people, marketing personnel, and strategists like efficient engineers because they make a firm more nimble. That's where the GNU Classpath and Debian Java DevJam comes in. Free Software Java enthusiasts want to see their implementations fully mature, and are working hard to make it so. The Free Software community has the opportunity to make its Java implementation not just an available alternative, but a compelling alternative to the proprietary ones on technical as well as licensing grounds. The recent release of GNU Classpath 0.18 shows just how vigorously this opportunity is being seized. Having mature software is only half the battle, however; that software has to be coherently put together and easy for the user and developer to manipulate. For many of these folks, it's not enough just to have good, Free Java virtual machines (like Kaffe and SableVM), class libraries (GNU Classpath), compilers and interpreters (gcj and gij, respectively, from the GNU Compiler Collection), and application servers (Jakarta Tomcat, JBoss, and JOnAS, among others). They also want these technologies to be mutually integrated and easy to install and use. Good software and good packaging complement each other to drive adoption of the technology, and that's what the DevJam is all about. I'm glad to see that representatives of Debian's Java packaging team will be joining not just upstream authors, but their counterparts at Fedora, Ubuntu, and Gentoo in furtherance of this goal. I've approved a budget of EUR 2000, which Petter Reinholdtsen will administrate, to support the expenses of Debian's participation in the DevJam. We've received 1500 USD in sponsorship of this event from a corporate sponsor that chooses to remain anonymous. The other mini-conference I'll be attending is the Debian Security Summit. We're bringing together the heads of our Stable Security and Testing Security teams — the two Joeys, Joey Schulze and Joey Hess, as well as a bevy of other security-minded people, with the goal of revitalizing and streamlining our security processes. Several members of the Stable Security Team have gone dormant over the past several months (or longer), leaving an increasingly small number people to handle, as of Sarge's release, not one but two stable releases. This is because we do not terminate security support for our previous stable release (in this case, Woody), until some time has passed. We've had other challenges on the security front. We had what amounted to a security support hiatus for about three weeks in June, which caused much consternation. More recently, klecker.debian.org, which provides the security.debian.org has suffered some occasional availability problems, and it hasn't always been clear what's caused them. It's my understanding that we have new hardware in place that can serve in a backup, supplemental, or failover capacity. The general feeling at DebConf 5 was that our security apparatus was in need of attention to make sure it keep pace with the demands being placed on it. I've been in fruitful contact with Joey Schulze, Steve Kemp, and others over the past several weeks, and I look forward to a productive few days.

I've not had much experience with git, but one feature I'm really liking is git-bisect. I often run into cases where a bug exists in one kernel but was fixed in another, and I need to pin the difference down to a single changeset. As an example, I recently discovered that an issue I'm working on in 2.6.8 no longer exists in 2.6.12. So, I went through the manual bisect to narrow the fix down to a changeset between 2.6.10-rc3 & 2.6.10. But that could be any of hundreds of changesets :( I decided it was a good opportunity to try git-bisect. It adjusts my tree to some intermediate state, I build and test. I tell git whether the results of my test were "good" or "bad", and it adjusts my tree once again. Very cool. The only annoying thing about this example is that I had to reverse the meanings of good & bad, because git bisect assumes that you're looking for the patch that fixes a build, not the one that broke it.

I recently blogged about how fixing d-i on cciss was just a matter of backporting a new version of the driver. Well, I was full of shit. Turns out my test case will give a false positive sometimes - oops. Anyway, the real fix requires backporting two fixes. Hopefully we can get this fix into a sarge point release at some point. On that note, I've started usertagging bugs that I think should go into a sarge kernel point release, should we ever do one (Note: the kernel team/stable release manager haven't discussed what is/is not acceptable in a stable kernel update, so this is just a wishlist at this point.) In my opinion, any localized fix that has already gone upstream and can be easily tested should be permitted. I'd really like to put driver updates in that category, but that opinion maybe tainted by my day job. We maintain a branch of the sarge d-i stack that has a side-goal of adding support for new HP hardware. We keep it as close to sarge as possible (backporting drivers to 2.6.8, for example) with the hope of pushing as much as possible into a sarge point release. Thanks to Andrew Patterson it has pretty recent cciss & fusion drivers. If there is interest, I could probably start posting these somewhere public.

I recently found out what these new-fangled podcast things are all about. I was playing with Rhythmbox the other day and noticed it had a built-in podcast feature, and I'd recently noticed that my favorite radio station is now doing podcasts, so I decided to investigate. After a few days of that, I decided that I approved of the concept. I bought a Neuros a year or two ago, and I spend about an hour or so bike commuting with it every day. Adding music to it is slow (USB 1.1), so I normally end up listening to the same music for a week or so. What I really want is to just plug it in at night & have fresh music on there ready to go the next day. But I also want to keep the flash full, so I don't want it to flush the old stuff unless it needs to - so I wanted something kinda like a FIFO. First thing I needed was something to track podcasts for me; rhythmbox is nice, but I need something scriptable. For now I'm using podracer. Its not very configurable, but it does the trick. I prototyped this all in shell using the positron command line interface, but then immediately rewrote it in python using the positron libraries instead. I then added a wrapper for cron to run that makes sure podcasts are up to date, the neuros is mounted (very easy now that udev automatically creates device files that are unique to a device under /dev/disk/by-id/), etc. It should be trivial to split the audio-device specific code into modules - which I'll need to do as soon as I find a physically smaller, logically larger flash player that works well with linux (I was looking at the iRiver T20, but have only read bad things about linux compatability).

I'm currently sitting in Denver International awaiting a flight to Houston where I'll meet up with Taggart for the flight into Mexico. There we'll meet up with some other folks (Ryan Murray, Troy Heber & Junichi Uekawa at least) and take a cab down to Oaxtepec. We've had *tremendous* trouble booking our hotel room (and by we, I mean Troy). In fact, last we heard they were cancelling our reservation. I strongly suspect this is an attempt at bribe soliciation, or maybe they actually just don't want to do business with us? Not quite sure - my employer is sponsoring my travel here, and I haven't noticed a "bribe" category on the expense report.. maybe I can list it under tip? :) Oh well, I suspect the worst case is that we can find asylum for a night on someone's floor until our accomodations get worked out. I'm very much looking forward to arriving at DebConf & seeing everyone, not to mention trying the local cuisine :)

I travelled quite a bit over the break. First leg was home to New Mexico for Christmas. The night I arrived, YD's band Absolute Uncertainties played a short birthday party set. The rest of the week was spent mostly hanging out with my nieces & nephews. They're pretty fun to hang out with, now that most of them can carry on conversations. Then it was off to Las Vegas. But I didn't stop at that one & instead ventured on to the one in Nevada. I drove to Albuquerque, had lunch with Skye & Casey, then met up with YD to fly to Vegas. After nearly missing the flight to fix a flat on the rental, we were on our way. This was YD's first time on an airplane, and he didn't even throw up on me. That's a true friend. A bunch of us stayed at a friend's house. We spent a lot of time in the hot tub, drank a lot of Coors Light, and ate a lot of Del Taco.

Anthony Towns will be Debian’s next project leader. I am not happy with that outcome at all. With just a tiny margin, aj has won over Steve. Steve was not my favorite candidate as well, but he’d be better than aj, who in my opinion stands for the cabal that is running Debian from their positions of power for years now. Only 421 DDs have cast their vote, which is 43.3128% of all possible votes. Voter participation has thus been lower than the historic low Germany’s state Sachsen-Anhalt recently had in its Landtag election. More than half of the DDs do not seem to be interested in who makes Debian’s external policy and who represents the project to the outside. On the other hand, debian-vote sees a number of people who are not currently allowed to vote, but regularly contribute to Debian. It looks like the people who could vote don’t, while people who do good things to Debian are not allowed to vote. Bad. But, IMNSHO, the really bad thing is the new DPL itself. I think he has won the election with saying that he will increase Debian’s speed. On the other hand, he is member of ftpmaster, the team that might be one of the biggest causes for Debian’s slow speed. He is generally regarded to be close to the “Cabal”, which of course does not exist. I don’t see how the speed increase is can be accomplished giving this background. However, the vote can easily be interpreted as a vote of confidence in the Cabal, which in itself is a good thing. It shows that even the voting DD’s are comfortable to be ruled by the secret club of most senior DDs. I don’t have to like it, but I’ll have to live with it. aj is also one of the founders of #debian-tech, an IRC channel which has been created as a “nice” channel for technical discussions. The channel has a very strict code of conduct, and people are being removed from the channel if they do not comply. I am really really really afraid of this “be nice or else” attitude being extended to other Debian communications media during aj’s term. Being robbed of the right to speak one’s mind might adversely affect many people’s motivation to spend time with Debian in the future. In a nutshell: This is a sad day for Debian. But, otoh, every project gets the leadership it deserves. And it looks like Debian didn’t deserve any of the better candidates. jftr, I voted 63571824 Be warned: I have a bad history of mis-judging new DPLs just after their election. A year ago, I was quite happy about Branden being elected, and was convinced that things would change during his first term of DPLship. I really believed that he could remove the Cabal from the power, and that Debian would change to a more co-operative environment. I surely hope that I am as wrong this time as I was a year ago. It’ll be more positive this time.

A few months ago, I have reported about getting the winmodem in my hp compaq nc 8000 to work. Aside from the abysmally slow performance, the dependency on out-of-tree, non-free modules has been cause of grief since it has almost constantly forced me to keep an outdated kernel version around just in case that I would need the modem. Fortunately, this is over now since more recent kernel versions (I suspect somewhere in the 2.6.16 era) support my winmodem natively without out-of-tree modules. All I need to get only on a POTS line is sl-modem-daemon, which is reasonably painless.

My notebook’s DHCP setup seems to be a challenge for DHCP servers around the world. Looks like almost no server implements the standard in a decently complete way. My notebook has a wired Fast Ethernet, and a wireless 802.11bg network interface. Of course, both interfaces have their own MAC address. I want the thing to work at least at home, regardless of whether wired or wireless is in use, with preferably the same static IP address, and on the office wired network, again, with the static IP address allocated to me there. Configuring this is considerably harder than I expected. At home, I am using a Linksys WRT54G router with OpenWRT, which has dnsmasq as DHCP server. Unfortunately, dnsmasq does not support the case where multiple MAC addresses are statically assigned to the same IP address: Only the first dhcp-host statement in the configuration file is honored, all others are ignored. So we need to resort to using a dhcp client-identifier. In DHCP request option number 61, the client can send an identifier, which the Server can then use to determine the client’s identity and assign a static IP address. The client identifier, according to RFC2132, is to be treated as an opaque string by the DHCP server. This works fine with dnsmasq, solving the issue at home. But it causes more grief in the office network. My office is the kind of place where a non-Microsoft solution is rarely considered. Thus, our network is fully buzzword compliant and the network infrastructure, including DNS and DHCP servers, is based on Windows Server System. I am the only one using a non-MS operating system in my work environment. When I plugged my notebook into the network this morning, I noticed that I didn’t receive my static IP address but a different one from the dynamic pool. After verifying that the Windows guys didn’t touch the DHCP server in the last days, I began to think what I changed locally and naturally remembered configuring the DHCP client identifier. Removed it for testing, got my normal static IP address, so the client identifier was quickly pinned down as the culprit. After my Windows colleagues decided that it must be a client issue, I began investigating how to configure the Windows DHCP server to honor a client identifier. MS Knowledge Base article #172408, “Custom DHCP Client Identifiers for Windows NT”, is a high hit on Google, but is like three years old and shows that somebody at MS has badly misunderstood the DHCP standard - they think that the Client Identifier is a 4 byte number in little endian order. I couldn’t believe that and investigated further. But it looks like the Windows DHCP server really cannot handle free-form client identifiers at all. I tried coding my free-form identifier in ASCII and entering it as MAC address, big endian, little endian, to no avail. So, I have come to the conclusion that MS has - again - only partly implemented a very important protocol for their network software. “Embrace and extend”, my <censored>, DHCP wasn’t extended at all. Looks like they stopped developing after the first developer box had successfully received an IP address, and shipped the resulting code. Woah. If somebody can tell me how to configure the Windows DHCP server to properly handle a free-form string DHCP client identfier, I’ll be most graceful for that information. I finally resorted to setting the DHCP client identifier of my notebook to the MAC address of the wired ethernet interface, which has at least brought my static IP address at the office back. I hope that the dnsmasq at home will successfully grok this or I am - again - back to square one. All software sucks