I've spent the last few days in Spain, representing Debian-IN at a meeting on Internationalization sponsored by the government of the province of Extremadura.
It has been very productive and informative. Debian should be proud of the attention we pay to internationalization (for the Indian languages at least we are ahead of any other distro and even Microsoft IMO.) If we keep up the effort we can truly deserve to be called the Universal OS.

Today, as it was widely anticipated, the Superior Tribunal of the Judicial Power of the Federation (TEPJF) declared Felipe Calder n, of the currently right-wing governing PAN party, elected as president for the 2006-2012 period.
My regular readers will know that my political views are against his party's, and that I completely oppose him - Of course, being consequent, in June I started, together with some friends, FeCal.org.mx, a site destined to show the incongruencies and incoherences in the official version - and that evolved to a site I am quite fond of, having good and deep analysis of the political situation. Of course, it is time now to redesign and think forward for this site, now that FeCal is no longer a candidate - but lets leave it aside for now.
Today, we are mourning. We are not mourning an electoral loss - Wherever there is democracy, there are losers, and it might be right that we lost this time. Furthermore, in political systems such as ours, it is practically guaranteed that the majority of the citizens will lose (this means, it is terribly hard for any candidate to get over 50% of the votes - If Calder n wins with almost 35% of the votes, or if L pez Obrador wins by a similar amount, we will anyway have 65% of losers). But what we are mourning goes far beyond that: We lost faith in our electoral institutions, which we were so proud of a couple of years ago. They proved not to be serious, not to be adequate for a hard decision. Why am I saying this? Lets analyze a bit.
First of all, the Federal Electoral Institute (IFE)'s main function is to organize the federal elections, and to make sure they are run with neutrality. Since the early months of the formal competition (as the campaigns themselves started way too early and we Mexicans are sick of the eternal electoral climate), the IFE has not acted in time to stop a dirty campaign, made not only by the PAN party but by the nation's President himself and by groups that, being privately owned, are said to be outside the reach of the IFE's regulatory spectrum. The IFE's general council should have been built with representants of all of the main political forces, but only PRI and PAN (which means, center-right and right wing) were represented.
Secondly, over the last six years, President Fox seems to have made constant efforts not only to prove us all he is a complete fool and inept as a statesman (examples abound, there is no rush to prove Vicente Fox just cannot be trusted to run a country), but that his fight for democracy was nothing but a race for personal power. He took every oportunity he could to promote his party - while the Mexican law requires him to remain neutral during the electoral period. There are many proven examples of irregularities and corruption inside his cabinet (most notably those carried out by Josefina V zquez Mota, who was in charge of all of the federal programs to fight poverty, and was the coordinator of Calderon's campaign) leading to inject resources into the campaign. Yes, this should have been stopped by IFE as soon as they were detected - But it was not. And, thank you Mr. Fox, by doing this you severely undermined the respect there should be for the Presidential figure.
Now, IFE's role ends shortly after the elections. After that, it is TEPJF's role to qualify the elections - To ratify they complied to the required equity, legality and certainty. Many of us had more trust in TEPJF than in IFE, mainly because of the series of personal and group connections that came up between IFE and the power groups. Most of us were quite vocal on the voto por voto, casilla por casilla front - Demanding from TEPJF to request to recount all of the votes. Having only 0.58% distance between the top candidates, with lots of statistical anomalities, with tons of reports of illegal tampering of the ballots, having a wide recount would surely make many among us believe and accept the results - Of course, the PAN repeated ad nauseam that the ballots had been counted and we should not go again over the same excercise, quoting all kinds of arguments that came from a too narrow interpretation of the law. And, in the end, too narrow was the response of TEPJF - Only 9% of the booths were reinspected, and not all of them were recounted. In fact, one week ago, they decided to discard over 300 appeals (this means, 300 requests for trial on a specific booth or on a whole district), without yet disclosing which appeals were they, on what basis were they discarded, what geographical areas did they impact, or anything. They nullified about 235,000 votes - And this number is quite scary, as it practically matches the official difference between the two lead candidates (244,000 votes before this partial recount, 233,000 after it). We can now state for certain that the difference between the candidates is smaller than the error margin.
Today, with a very important portion of the country in doubt on whether their decision was legal and correct, TEPJF ratified Felipe Calder n as the elected president. This would be good news. I would like to accept Felipe as my president - Sadly, I cannot, just because all of the TEPJF's principles were violated:

• Equity: The process didn't progress with equity. Illegal publicity was repeated over and over. Just as one example, the Presidency has had the equivalent of 24h a day of ads in the national electronic media for over six months - And IFE acknowledged it was used in a way that promoted the vote for their candidate. The final message was very subtly changed, many people were left unsatisfied, and... That was it.
  Andr s Manuel L pez Obrador was often protrayed as a puppet of Fidel Castro and Hugo Ch vez, and there are still people who believe he was setting to create a communist regime in Mexico. Of course, this was also a direct result of what is now known as the hatred campaign that the ruling party and an important group of industrials pushed. So, no, we had no equity.
• Legality: Most of this posting has dealt with the ilegalities of the process, they are really not in short supply. The sad and alarming thing is that it was the TEPJF itself which commited the last and most important illegal acts.
• Certainty: In a strongly contested electoral scenario, I perceive this to be the sole most important principle. How many votes were cast for each of the top candidates? We have repeatedly stated that the difference between them is below the statistical error margin for a process where a million people counted the votes. And after last week's results where nearly 240,000 votes were discarded, the difference is objectively and undoubtely smaller than the error margin. Even if no fraud was made, people make mistakes, and it is too na ve to assume not even one out of each 200 votes was incorrectly accounted. And even if no fraud was done, not allowing the society to ensure the results of the process really match the reality is by itself a fraud. We will now probably never know if Felipe Calder n cheated, the same as we still don't know who won in 1988 and by how much. Then, official records say that Carlos Salinas had over 50% of the votes, Cuauht moc C rdenas almost 30% and Manuel Clouthier close to 20% - But both C rdenas and Clouthier were sure they had won. And while C rdenas (founder of the PRD, which now supports L pez Obrador) called off the civic resistence to start creating a strong political movement for future, PAN's Clouthier did exactly what his party criticizes L pez Obrador for. In fact, our president Vicente Fox was the Agriculture Secretary in Clouthier's parallel government. Only that Clouthier had a misterious accident some months later and died - giving way to the dark period of PRI-PAN concertacesiones led by Diego Fern ndez de Ceballos.

So... In short, what comes now? We are exhausted by this long process. As too many people, I just cannot accept the imposition of yet another fraudulent president. I had the hopes that Mexico had changed in the last 18 years - But it has not. We are still in a strong presidentialist regime, and we still don't have hopes of getting a democratic government. If we do have a democraticly elected president, perfect, I will accept it. Of course, criticizing and keeping a close eye on his government, as I don't think the social and economic principles they push, but accepting. But there are too many signs of a fraud, there are too many stinky bits in the decision. The stinkiest of them all, the refusal of their opportunity to shut us up. Is it better to have millions of angry citizens closing important streets and giving Mexico a bad name by writing about our trip back to the stone age than to allow for a legal recount? Is it too much asking giving some certainty to our elections? Is there any doubt we will keep fighting this imposition?

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!

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.

I suddenly realised that I like receiving bug reports. In a recent bout of structured procrastination I fixed more or less all the bugs I could fix in my packages (except ppp. I don't feel like working on ppp right now, does anybody want to help me?) and now this is a quiet period. Obsessively checking the bugs mailbox for new messages is a clear withdrawal symptom. I am addicted to bugs for a very simple reason: they are a challenge. I stopped working on mutt because it was not interesting anymore to me and then I adopted ppp and packaged udev because I tough that maintaining them would require solving many interesting problems. It's too bad that solving some needs the collaboration of other developers, but this will be the topic of a different rant. But not all bugs are an interesting challenge. Some are just a total waste of my time, which usually is much more valuable than the time of the submitter. I will show some examples.

• Obscure bugs which I cannot debug and need repeated interactions with the upstream developers trying to debug them. OK, you submitted the bug and I am sorry that I cannot help more than this, but I told you where you can find somebody who cares. Now please do not expect me to forward emails back and forth from the BTS and upstream developers. This is not only very inefficient for you and for the people who are trying to help you, but also wastes my precious time.
• Features to be forwarded to the upstream maintainer. I am a Debian developer, not your personal assistant. Forwarding your feature request, which probably will never be implement because it is crazy, useless or just needs more work than it is available wastes my precious time. And then I will waste even more every time I will be distracted by seeing it in the BTS, and curse you for continuing to waste my time.
• Trivial upstream bugs like spelling errors. It is highly improbable that I will consider them important enough to be worth fixing with a patch in the Debian packaging, so what about you do not waste my precious time and just report them to the upstream maintainers?
• Requests for useless changes to the packaging. If it is useless and you do not even care enough to implement it, what makes you believe that I will? (Yes, I will decide what is useful.)
• Multiple reports about the package being totally broken. If an important package is obviously broken (often broken as in "the system will not boot") then probably somebody else will have already submitted a bug report. It is your duty to check for open bugs before reporting a new one, and merging or closing duplicate bugs wastes my precious time.
• Bogus reports showing that you did not RTFM.
• Bogus reports showing that you have no grasp of how the package works. Especially if I explained the issue in the README.Debian file.
• Unreproducible reports where every clue points to a PEBKAC and the reporter still does not promptly follow my instructions for trying to confirm the bug.

So, if you can follow these simple rules I will probably not flame you to ashes the next time you will report a bug on one of my packages.

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.

I'm glad people have reacted in a largely positive manner to the steering committee idea. It's not really original, but I'm perfectly happy with stealing ideas from other people. I'm going to clarify a few basic ideas here and then address criticism.

The biggest difference between Debian and someone like Canonical or Redhat is that we don't pay employees to do things. We could go that route, but a defining feature of Debian is that it has a bottom-up structure, rather than top-down. I think this makes us unique and we need to do our best to preserve it. I imagine the steering committee to be an extension of this model.

First, the committee would be not be elected by the developers, but would instead be delegated by the DPL. Developers could challenge this delegation in the same manner as any DPL decision. The committee would be very similar to the technical committee in terms of size.

Second, its scope of power would be similar in that it would only relate to the distribution itself, rather than the way the Debian project itself was organized. Its powers would be limited to approving specific improvements within the distribution. These improvements would have to be submitted for approval by the committee, preferably in some sort of specification format similar to the one Ubuntu uses. The committee would then vote on the issue (most likely following the same rules as the technical committee). If they approve it, anyone is free to work on that specific improvement even if it touches on packages they don't maintain. This allows motivated developers to freely work on cross-distro improvements without worry. The committee would ideally be relatively quick to reply to submitted proposals, allowing fairly rapid developments to occur (to facilitate this, proposals must be well thought out).

Further, like the release team, the steering committee would also be responsible for actively working on goals that are set. This would ensure that something actually does get done. These features would give us a group with a limited scope of powers to implement large-scale improvements to the distribution without forcing anyone to do work they don't want to do. In addition, motivated people would have the authority to make large-scale improvements (like consistent theming for example) across many packages they don't maintain. People working on these improvements would be expected to try and cooperate with the normal maintainers as well as possible, so as to prevent problems. Maintainers who have issues can appeal to the technical committee, whose role would remain reactive to solve conflicts as they arise.

Ok, now for the critique from ij, which is a good one. I think the problem with what you suggest is that the DPL simply isn't going to be capable of acting like a good dictator without working full time on Debian for several years. The job is just too big. Allowing them to remain DPL for more than a year is something I don't think many DPL's would opt for anyway, it's just too draining.

The other existing structure is the technical committee, which is a better candidate for taking on this sort of role. The key to the tech-ctte though is that its job is to handle technical disputes. We could expand its role to allow it to set policies and direction, but then who do you appeal to if you don't agree with them? The developer body can override the tech-ctte (with a 2:1 majority) but that adds additional democratic overhead. GR's are draining, and providing another layer for technical decision making allows us to avoid them. Further, I'd like the steering committee and tech committee to have different modes of working. I imagine the steering committee to be more agile, taking a leading role in setting out a vision for the mass of developers to follow and take inspiration from. The tech committee, on the other hand, should be more defensive, carefully deciding on the most difficult issues. Basically the steering committee will looking towards the future, the tech committee will be looking towards the present.

It’s been over a year now since my last proper upload to Debian, and nine months since I announced my intent to put aside working on Debian for a while. With Matthew Garrett’s resignation from Debian, several people have compared it to my own “resignation” from Debian. It has got my thinking about whether I currently intend to ever end my “Sabbatical” and return as an active Debian Developer. I think that the end of my love-affair with Debian started at Debconf last year where several developers treated those of us who also worked on Ubuntu quite rudely. Someone was attacked for wearing an Ubuntu t-shirt at the conference, while someone else was applauded for wearing a “Fuck Ubuntu” t-shirt. That’s where I realised that maybe I didn’t have as much in common with these people as I thought I did. I still don’t understand why Debian singles Ubuntu out for this kind of treatment, we’re still the only derviative distribution that makes all of our patches to Debian available, yet Ubuntu is claimed to not do anything at all. Another example is that Ubuntu is being asked to change the Maintainer field of every package, something no other derivative is being asked to do or has ever been asked to do. Martin Krafft has had some interesting things to say about this strange relationship in the past. If that was the start of my falling out with Debian, I think that Debian considering removing documentation and firmware from the distribution, especially the documentation, was another point I started wondering whether I shared anything in common with the project anymore. Call me strange, but I think that one of the fundamental purposes of a Linux distribution is to be useful to its users. If nobody can use the distribution because it doesn’t support their hardware, and even if it did, all the documentation has been stripped out; I started to wonder what it’s aims are. It became increasingly apparent that the only users Debian was considering a priority were its own developer. And the third thing is simply a matter of Fun. Fun for me, at the moment at least, has been to build a system that fits together extremely nicely with each component doing the right thing. For Ubuntu this has meant being a driving force for it being Linux 2.6 only, with reliance on udev for hardware, etc. Upstart is just a continuation of these goals, getting a system which all “just works”, even if it means throwing out a few things people were previously fond of. All of these things would have been impossible to do in Debian itself. Getting upstart installable required changes to twelve different packages, including sysvinit itself; at a worst case, this would have required the agreement of twelve different maintainers in Debian. It’s often exhausting just persuading one of the reason for the change, persuading a dozen would have been a herculian effort. Perhaps Matthew is right, what Debian lacks is a single leadership. There’s nobody in Debian I could have gone to for approval over the changes I wanted to make, whose decision developers cannot overrule. Ubuntu has such people (the Technical Board and sabdfl), which gives the project an obvious direction instead of a couple of hundred people all pulling in different directions. In a way, I don’t feel that I’ve left Debian. I feel like I was happily going along, only to realise the mob had gone in a different direction and with no easy way of rejoining the group.

I’m writing this in Windows Live Writer. It’s pretty incredible—setup was easy, and there’s a mode for editing the entry such that it looks exactly as it will look after it’s posted (i.e., with the right font, layout, etc.), though without all the page adornments (header graphic, sidebars, etc.). There is a preview mode for that though—if you could edit in the preview mode, now that would be incredible (better still, if you could edit the page directly, inline, presuming you had the appropriate credentials—a truly writable web!). It’s too bad this is Windows only—I have a Windows box in my office, but it’s a desktop machine, so I don’t have it when I travel (I wonder if it will run under Wine?). I’d also love to see this integrated with Firefox, something like Performancing, where you can select some text, then right click “Blog This”. There is an IE toolbar, but that doesn’t help me. In addition to being a nice tool, this does give a glimpse into Microsoft’s strategy for the web: Desktop/thick client apps as an extension to web/thin client apps, providing all the advantages of web apps but better UI, better performance, and offline support. So far, I like what I see.

I had the pleasure this morning of attending a baby naming ceremony. Aside from being at the thoroughly crazy hour of 07h30, it was a very cool experience.

The Shaar Zion Synagogue is in Hampstead, about 8km from our appt. I was running a touch late because I worked for about an hour before setting off and got caught in conversation. It turned out this was a good idea, since Mount Royal is between there and my place, and I was otherwise planning on biking.

In the search for the entrance I met one of the relatives, who explained how to put one of the skull caps on and we found the sanctuary together. I think as part of the comparative religions bits in YRUU I might've visited a temple before, but I couldn't remember what the customs were. I found a place to sit that was out of the way about the time that they called everyone to worship. They asked people to turn to a page in a book that I didn't have, so I ran out and got one. I was glad I did: The group of teenagers in the row ahead of me didn't and looked mostly bored. The service was sung/chanted/spoken in Hebrew, but the book had both and Hebrew and English texts in it.


The service was quite unlike what I'm used to, and tolerated a fair amount of shuffling around, hugs, greetings and children running around. From what I can tell, the service was the standard morning prayers with the baby naming inserted in the middle. Some other time, I'd love to get a guided tour of what I saw so that I could understand what was happening. The whole occasion seemed so rich with tradition, but at the same time wasn't stuffy or boring.

When the service was done, I joined the group in the basement for breakfast. It was vaguely ironic that when I'm shopping, I usually look for Kosher symbols to help me tell if there's hidden dairy in things, but that breakfast consisted of largely non-vegan items (fish, eggs). I got to meet Glen and Sharlene's wonderful families and am very glad I went.

But it does feel like the attack of the baby things has truly started =)

So finally I got my card reader running on Linux. It was not that hard, but the main problem was caused by the proprietary Linux driver I installed. Thanks to Ludovic Rousseau's Generic CCID driver the reader is able to run just fine with only Free Software. It works even with libchipcard2, but a tiny fix to udev was necessary to fix a permission problem (you might need to adapt the vendor and product id to your local card reader, as shown by lsusb):

/etc/udev/rules.d/smart_card.rules:
BUS=="usb", SYSFS idVendor =="04e6", SYSFS idProduct =="5116", GROUP="chipcard", MODE="0664"

With this tiny fix chipcardd2 correctly opens the card as a non-privileged user. My thanks also go to Thomas Viehmann, who provides an HBCI branch of Gnucash on Alioth. Apart from the application crashing a bit too often, the HBCI part works fine with my card and PIN. The only problem left is the sudden disconnect of the reader when it's not used for a few minutes. Only a restart of chipcardd2 and gnucash resolves the problem temporarily. All my homebanking activities are now properly signed, and the retrieval of transactions works just fine. To credit my bank a bit, I am a customer of 1822direkt, a subsidiary of the Frankfurter Sparkasse, since a few weeks. They provided me with a free checking account, together with a free(!) HBCI card. Transactions are mailed just-in-time (checked for hourly during working hours) PGP-encrypted. (Yes, they are running PGP5i on OS/2. I needed to create a RSA key using PHP5i/Unix without a passphrase. The public key output of PGP5i had to be sent to the bank, and after an import of the resulting public and private key into my GPG instance I was able to read the statements correctly. The mail interface did not cope with GPG-generated keys.)

Yay for Bank Holiday weekends. It's been a busy one, in no particular order we:

• Saw Snakes On A Plane, which was good. It managed to be tongue-in-cheek without being silly, and Samuel L Jackson didn't disappoint at all. Great fun film.
• Saw Pirates Of The Caribbean 2, which wasn't bad. As ever it proves the rule that the sequel is never as good as the original, was a little too long, and the abrupt ending setting the stage for the third film was a little annoying. I didn't think it was bad though, but you really needed to have seen the first film.
• Had a swift pint (or two) with Allen before the cinema. He's been travelling around with work a lot recently (Manchester, Sheffield, Delhi) so catching him is quite tricky these days.
• Went out to dinner with Caroline to De Luca. Very good Italian, highly recommended.
• Cooked a roast chicken and so on for Pete and Jayne, before they go back to uni. This summer has flown by and we didn't really see them much, so it was good to spend half the day with them. I also failed to poison anyone with roast chicken, which is always good.

NP: [THN014] Zu Hause² LP, Digitalverein

upstart is a replacement for the init daemon, the process spawned by the kernel that is responsible for starting, supervising and stopping all other processes on the system. The existing daemon is based on the one found in UNIX System V, and is thus known as sysvinit. It separates jobs into different “run levels” and can either run a job when particular run levels are entered (e.g. /etc/init.d/rc 2) or continually during a particular run level (e.g. /sbin/getty). The /etc/init.d/rc script is also based on the System V one (and is in the sysv-rc package), it simply executes the stop then start scripts found in /etc/rcN.d (where N is the run level) in numerical order. Why change it? Running a fixed set of scripts, one after the other, in a particular order has served us reasonably well until now. However as Linux has got better and better at dealing with modern computing (arguably Linux’s removable device support is better than Windows’ now) this approach has begun to have problems. The old approach works as long as you can guarantee when in the boot sequence things are available, so you can place your init script after that point and know that it will work. Typical ordering requirements are:

• Hard drive devices must have been discovered, initialised and partitions detected before we try and mount from /etc/fstab.

• Network devices must have been discovered and initialised before we try and start networking.

This worked ten years ago, why doesn’t it work now? The simple answer is that our computer has become far more flexible:

• Drives can be plugged in and removed at any point, e.g. USB drives.

• Storage buses allow more than a fixed number of drives, so they must be scanned for; this operation frequently does not block.

• To reduce power consumption, the drive may not actually be spun up until the bus scan so will not appear for an even longer time.

• Network devices can be plugged in and removed at any point.

• Firmware may need to be loaded after the device has been detected, but before it is usable by the system.

• Mounting a partition in /etc/fstab may require tools in /usr which is a network filesystem that cannot be mounted until after networking has been brought up.

We’ve been able to hack the existing system to make much of this possible, however the result is chock-full of race conditions and bugs. It was time to design a new system that can cope with all of these things without any problems. What we needed was an init system that could dynamically order the start up sequence based on the configuration and hardware found as it went along. Design of upstart upstart is an event-based init daemon; events generated by the system cause jobs to be started and running jobs to be stopped. Events can include things such as:

• the system has started,

• the root filesystem is now writable,

• a block device has been added to the system,

• a filesystem has been mounted,

• at a certain time or repeated time period,

• another job has begun running or has finished,

• a file on the disk has been modified,

• there are files in a queue directory,

• a network device has been detected,

• the default route has been added or removed.

In fact, any process on the system may send events to the init daemon over its control socket (subject to security restrictions, of course) so there is no limit. Each job has a life-cycle which is shown in the graph below: The two states shown in red (“waiting” and “running”) are rest states, normally we expect the job to remain in these states until an event comes in, at which point we need to take actual to get the job into the next state. The other states are temporary states; these allow a job to run shell script to prepare for the job itself to be run (“starting”) and clean up afterwards (“stopping”). For services that should be respawned if they terminate before an event that stops them is received, they may run shell script before the process is started again (“respawning”). Jobs leave a state because the process associated with them terminates (or gets killed) and move to the next appropriate state, following the green arrow if the job is to be started or the red arrow if it is to be stopped. When a script returns a non-zero exit status, or is killed, the job will always be stoped. When the main process terminates and the job should not be respawned, the job will also always be stopped. As already covered, events generated by the init daemon or received from other processes cause jobs to be started or stopped; also manual requests to start or stop a job may be received. The communication between the init daemon and other processes is bi-directional, so the status of jobs may be queries and even changes of state to all jobs be received. How does it differ from launchd? launchd is the replacement init system used in MacOS X developed as an “Open Source” project by Apple. For much of its life so far, the licence has actually been entirely non-free and thus it has only become recently interesting with the licence change. Much of the goal of both systems appears initially to be the same; they both start jobs based on system events, however the launchd system severly limits the events to only the following:

• system startup,

• file modified or placed in queue directory,

• particular time (cron replacement),

• connection on a particular port (inetd replacement).

Therefore it does not actually allow us to directly solve the problems we currently have; we couldn’t mount filesystems once the “filesystem checked” event has been recived, we couldn’t check filesystems when the block device is added and we certainly couldn’t start daemons once the complete filesystem (as described by /etc/fstab) is available and writable. The launchd model expects the job to “sit and wait” if it is unable to start, rather than provide a mechanism for the job to only be started when it doesn’t need to wait. Jobs that need /usr to be mounted would need to spin in a loop waiting for /usr to be available before continuing (or use a file in a tmpfs to indicate it’s available, and use that modification as the event). This is not especially surprising given that Apple have a high degree of control over both their hardware and the actual underlying operating system; they don’t need to deal with the wide array of different configurations that we have in the Linux world. Had the licence been sufficiently free at the point we began development of our own system, we would probably have extended launchd rather than implement our own. At the point Apple changed the licence, our own system was already more suitable for our purposes. How does it differ from initng? Initng by Jimmy Wennlund is another replacement init daemon intended to replace the sysvinit system used by Linux. It is a dependency-based system, where upstart is an event-based system. The notion of a dependency-based system is interesting to talk about at this point. Jobs declare dependencies on other jobs that need to happen before the job itself can be started. Starting the job causes its dependencies to be started first, and their dependencies, and so on. When jobs are stopped, if running jobs have no dependencies, they themselves can be stopped. It’s a neat solution to the problem of ordering a fixed boot sequence and the problem of keeping the number of running processes to a minimum needed. However this means that you need to have goals in mind when you boot the system, you need to have decided that you want gdm to be started in order for it, and its dependencies, to be started. Initng uses run levels to ensure this happens, where a run level is a list of goal jobs that should be running in that run level. It’s also not clear how the dependencies interact with the different types of job, a dependency on Apache would need the daemon to be running where a dependency on “checkroot” would need the script to have finished running. Upstart handles this by using different events (“apache running” vs. “checkroot stopping”). Again while interesting, Initng does not solve the problems that we wanted to solve. It can reorder a fixed set of jobs, but cannot dynamically determine the set of jobs needed for that particular boot. A typical example would be that if the only dependency on the job that configures networking is the mount network filesystems job, then should that job fail or notbe a goal (e.g. because there are no network filesystems to be mounted) the result is that network devices themselves will not be configured. You could make everything a goal, and just use the dependencies to determine the order, however this is less efficient than just ordering the existing sysv-rc scripts (which
can be done at install time). Another example is that often you simply don’t know whether something is a dependency or not without reading other configuration, for example the mount network filesystems may be a dependency of everything under /usr or may just be a dependency of anything allowing the user to login if it just mounts /home. The difference in model can be summed up as “initng starts with a list of goals and works out how to get there, upstart starts with nothing and finds out where it gets to.” How does it differ from Solaris SMF? SMF is another approach to replacing init developed by Sun for the Solaris operating system. Like initng it’s a dependency-based system, so see above for the differences between those systems and upstart. SMF’s main focus is serive management; making sure that once services are running, they stay running, and allowing the system administrator to query and modify the states of jobs on the system. Upstart provides the same set of functionality in this regard, services are respawned when they fail and system administrators can at any time query the state of running services and adjust the state to their liking. Will it replace cron, inetd, etc? The goal of upstart is to replace those daemons, so that there is only one place (/etc/event.d) where system administrators need to configure when and how jobs should be run. In fact, the goal is that upstart should also replace the “run event scripts” functionality of any daemon on the system. Daemons such as acpid, apmd and Network Manager would send events to init instead of running scripts themselves with their own perculiar configuration and semantics. A system administrator who only wanted a particular daemon to be run while the computer was on AC power would simply need to edit /etc/event.d/daemon and change “on startup” to “on ac power”. What about compatibility? There’s a lot of systems administrators out there who have learned how Linux works already and will not want to learn again immediately, there’s also a large number of books that cover the existing software and won’t cover upstart for at least a couple of years. For this reason, compatibility is very important. upstart will continue to run the existing scripts for the forseeable future so that packages will not need to be updated until the author wants. Compatibility command-line tools that behave like their existing equivalents will also be implemented, a system administrator would never need to know that crontab -e is actually changing upstart jobs. Does it use D-BUS?

“To D-BUS people, every problem seems like a D-BUS problem.”
—Erik Troan

The UNIX philosophy is that something should do just one job, and do it very well. upstart’s one job is starting, supervising and stopping other jobs; D-BUS’s one job is passing messages between other jobs. D-BUS does provide a mechanism for services to be activated when the first message is sent to them, thereby starting other jobs. Some people have taken this idea and extended it to suggest that all a replacement init system need do is register jobs with D-BUS and turn booting into a simple matter of message parsing. This seems wrong to me, D-BUS would need to be extended to supervise these services, provide means for them to be restarted and stopped; as well as deal with being process #1 which means cleaning up after children whose parent’s have died, etc. It seems far simpler to arrange for D-BUS to send an event to init when it needs a service to be started, and focus on being a very good message passing system. The IPC mechanism used by upstart is not currently D-BUS because of various problems, however it’s always been expected that even if init itself doesn’t communicate with D-BUS directly, there would be a D-BUS proxy that would ensure messages about all init jobs and events would be given to D-BUS and D-BUS clients could send messages to init to query and change the state of jobs. What is the implementation plan? Because this is process #1 we are changing, we want to make sure that we get it right. Therefore instead of releasing a fully-featured daemon and configuration to the world, we’re developing it in the following stages:

1. Principal development; at the end of this stage the daemon has been implemented and can manage jobs as described.
2. Replacement of /sbin/init while running the existing sysv-rc scripts. This is the shake-down test of the daemon, can it perform the same job as the existing sysvinit daemon without any regressions?
3. /etc/rcS.d scripts replaced by upstart jobs. These consitute the majority of tasks for booting the system into at least single-user mode, and contain many of the current ordering problems and race conditions. If the daemon solves the problems here, it will be a success.
4. Other daemon’s scripts replaced by upstart jobs on a package-by-package basis; this will be an ongoing effort during which upstart will continue running the existing sysv-rc scripts as well as its own jobs. During this time the event system may be tweaked to ensure it truly solves the problems we need.
5. Replcement of cron, atd, anacron and inetd. This will happen alongside the above and result in a single place to configure system jobs.
6. Modification of other daemons and processes to send events to init instead of trying to run things themselves.

The current plan is that we will be at least part of the way into stage #3 by the time edgy is released, with that release shipping with upstart as the init daemon and the most critical rcS scripts being run by it to correct the major problems For edgy+1 we hope to have completed stage #5 and be at least part of the way into the implementation of stage #6. From the start of development of edgy+2, no new packages will be accepted unless they provide upstart jobs instead of init scripts and init scripts will be considered deprecated. What state is it in now? The init daemon has been written and is able to manage jobs as described above, receiving events on the control socket to start and stop them. This has now been uploaded to the Ubuntu universe component in the upstart package for testing before it becomes the init daemon. We welcome any experienced users who want to help test this; install the package and follow the instructions in /usr/share/doc/upstart/README.Debian to add a boot option that will use upstart instead of init. If your system boots and shut downs normally (other than a slightly more verbose boot without usplash running) then it is working correctly. Other types of events will be added as required during development and testing. Currently only a basic client tool (initctl) has been written, compatibility tools such as shutdown will be written over the next week or two before it replaces our sysvinit package.

As I mentioned in my first post the amount of effort I'm prepared to invest in posting to a small group of people is limited. I don't think that I am the only person with this opinion.<br /><br />I also believe that the number of people who refuse to post to open lists is quite small, and that on many lists they aren't the people who contribute much. I believe that they are outweighed in both number and contributions by the people who want open lists and who are unwilling to spend a large effort on posting to a closed list.<br /><br />When posting to an open list you have to be concerned about your online reputation. Some lists are closed because of having NSFW content that people don't want known by their colleagues and managers, I guess that this makes sense for some lists.<br /><br />IMHO the only good reason for closed lists is for discussion of truly sensitive information. This ranges from security problems in software that have not yet been fixed to medical and psychiatric problems. There are many lists which should not be publicly archived, but for general discussion of computers there is no such motivation.<br /><br />For a list with a primarily technical focus on answering basic questions secrecy does no good, it merely protects people who want to post off-topic messages and create pointless arguments about issues that they don't understand.<br /><br />My solution to some of these problems is to use this blog to comment on such things. I expect that my solution will also be adopted by other people on some of the closed lists that I use.<br /><br />Also it has occurred to me that blogging about issues may improve the quality of list discussion. If instead of responding to a message in point-form you write an article about the general issue then it may reduce the level of personal dispute. I think it would be difficult to have a flame-war by blog.<br /><br />Finally while on the topic I have to mention that I don't believe in anonymous posting to technical forums. Any content that is worth having should come with someone's name attached. IRC nicks etc are OK, but the person writing the content should be identifiable.

In a mailing list to which I subscribe there is currently a discussion on US politics with the inevitable discussion of <span style="font-weight: bold;">wasted votes</span>. As I don't want to waste my writing on this topic on a closed list I'm posting to my blog.<br /><br />There is ongoing discussion on the topic of <span style="font-style: italic;">wasted votes</span>. As a matter of principle, if a vote is considered to be wasted, then that should be considered a failure of the electoral system.<br /><br />Having representatives for regions makes some sense in that a regional representative will have more interest in the region than a central government with no attachment to the region. I expect that representatives of regions were initially used because it was not feasible for people to vote for people that weren't geographically local. Now there is no real requirement for geographical locality (only a very small fraction of the voters get to meet the person they are voting for anyway) but having a representative for a region still makes sense.<br /><br />The requirement for a regional representative means that if you live in a region mostly filled with people who disagree with you then your vote won't change much. For example I live in a strong Labor region so the REAL fight for the lower house seat (both state and federal) occurs in the Labor party room.<br /><br />My vote for the senate counts as that is done on a state-wide basis. So of the two votes entered in one election one of them can be considered to not be <span style="font-style: italic;">wasted</span>.<span style="font-weight: bold;"></span><br /><br />For the US system, the electoral college was developed in a time when it was impossible for the majority of voters to assess the presidential candidates, and it solved the requirements of those times reasonably well. Today it is quite easy to add up all the votes and use either a simple majority or the "Australian ballot".<br /><br />Currently there is some controversy over the actions of Senator Joe Lieberman who lost the support of his party and then immediately declared that he would stand as an independent candidate. I believe that this illustrates a failure of the electoral system. It should be possible to have multiple candidates from each party on the list. In the Australian system it is possible to do that, but as they are in random order on the voting cards no-one would be sure of which candidate of the winning party would get the seat unless there were actual reasons for preferring one candidate over another (which sadly often isn't the case). This is good for voters (the minority of voters who care enough about internal party policies to prefer one party candidate over another should make the decision) but not good for the candidates who want a better chance of winning without actually demonstrating that they can represent their voters better than other candidates.<br /><br />The Australian government system has nothing equivalent to the US presidential election. The prime minister is voted in by the members of parliament. So there is little chance of getting multiple candidates from one party contesting one position. For the US presidential election I think that the best thing to do would be to have an "Australian ballot" and permit multiple candidates from each party. For example you could have Bush and Cheney running as candidates for president with each promising to make the other their VP if they get elected. With the Australian ballot it wouldn't matter if you put Bush and Cheney as the last two votes on your ticket, the order you use for them will still matter.<br /><br />I think that with the US presidential and state governor elections there is enough knowledge of the candidates among the voters to make it worth-while for each of the major parties to run multiple candidates.<br /><br />One of many advantages of having multiple candidates is that you might have real debates. If the main candidates from the two big parties have a set of strict rules for their debate that prevents any surprise then the people who are the less likely candidates from those parties (and who therefore have less to lose) could go for a no-holds-barred debate with a selection of random members of the public asking questions.<br /><br />Of course none of this is likely to happen. Any serious change would have the potential to adversely affect at least one of the major parties, and any improvement would necessarily have a negative impact on most of the current politicians. Votes ARE being wasted, and most politicians seem to like it that way.

Two small bits: bzr.debian.org and git.d.o now exist both in the DNS and in costa's Apache2 config, so please use them instead of arch.debian.org if you want to do Bzr or Git. Also, work has truly begun on setting up the new host for Alioth. Rapha l has started setting up Xen hosts on wagner.d.o, and I've started reviving my CVS-to-Bazaar gateway for the Gforge code to help us keep our Alioth-specific changes versioned. Along with the move to a faster, bigger box (single box too, so no more account synchronisation delays), we'll take the opportunity to upgrade to Gforge 4.5. We'll keep you posted about that.