The other day, Romain shared his concerns about using Git for team-maintained packaging. His comment system is currently broken, so I wrote an e-mail reply, which I would like to share.

I agree with Romain that the design decision to not support subtree checkouts like SVN is not without problems. As opposed to a single SVN repo with components in subdirectories that you can individually check out, you might end up with a hundred Git repos, and the same change to all then requires one to iterate all 100.

I’d like to make the distinction between trivial changes (e.g. s/© 2008/&-2009/g) and those that might not be (e.g. Standards-Version, or something even more elaborate).

In case of the former, there’s no question, it can be painful to operate across a hundred repos. Tools like mr make that a bit easier, but it’s still far from optimal.

The latter, however — updating Standards-Version and adding the appropriate changelog entry — is not really comparable. Neither would be e.g. changing a file location in 100 different repos. In those cases, every single package needs manual intervention, and if only for quality reasons and testing. In this sense, I actually think that a single SVN checkout with all the subtrees and the possibility to easily commit the result of a recursive action is counter-productive.

On the other hand, I don’t say that I am pleased with the workflow Git (or any other DVCS for that matter) imposes. It’s sometimes quite painful, as Romain says. We are missing higher-level tools that allow for easier and more intuitive bulk operations. I think that they should be implemented outside of the VCS-tool though, true to the Unix principles. SVN integrates it all into a monolithic piece of software, and that often isn’t ideal either (think size and slowness, or backup weight, or chance of corruption, or granular access control, or the impossibility to properly track files across subtrees).

mr is a step in the right direction, and we need more tools along those lines. First, however, I think that people need to figure out how exactly to use DVCS for packaging, such that there is any chance of consolidating workflows across a larger number of packages; if everyone does it their own, slightly unique way, then that goal is inifinitely far. This is the reason I started vcs-pkg.org, and even though we’re still far from anywhere, I am quite pleased with what we’ve done so far.

If you’re at Debcamp or DebConf, maybe you could join the discussion.

Romain also mentioned that distributed VCS don’t allow for the same sort of centralisation as SVN does. I disagree: you can use Git in exactly that way, as a centralised repo from which packages are built. The nice advantage over SVN (one which svk tried to close) is the ability for everyone to easily branch/fork, or work offline.

Once you start down that path, it somehow inherently becomes everyone’s own responsibility to ensure that one’s changes end up in the central repository (where commit hooks might verify the build-ability, ensure that the test suite still passes, or run simple format/consistency checks).

This sort of workflow is very different from the one with a self-appointed benevolent dictator at the top, who (like Linus, or Junio for Git) sometimes forget to include patches due to overflooding. The question is really: Given that you need some sort of centralised release coordination, do you want a human or a repo to be the central entity (and single point of failure)?

I really prefer the repo, since that places the sole responsibility on the leafs, on the contributors, who need to see their code through all the way.

It’s a whole lot more rewarding to commit/push, get a rejection, pull, merge, commit/push, and be done, rather than to send a patch to upstream, wait, reping, notice that it’s not in in the new release, ask, ping, change, reping, get angry, ping, hope, wait, ping, wonder why the heck you are still doing this, write angry email but don’t send it, reping, ask, and finally notice that it’s been accepted after all.

NP: Deep Purple: Made in Japan

What’s this:

1. proof, that Microsoft still rulez the browser market?
2. a pathetic admission that they lost?
3. an advertising about standards-noncompliance?

Poor sods. Let’s give them a hand for trying.

Go Firefox, and the other free browsers out there.

(By way of my awesome girlfriend, and thanks to Adeodato Simó for the screenshot after the clowns appear to have taken the original page down.)

NP: Mono: You Are There

More than three years ago, someone unidentified created Wikipedia page about me. The author appears phony, and I have an inkling of who he is, but I never received confirmation.

When I found out about the article a while later, I was flattered and excited. I couldn’t help but edit it, not knowing then (but well understanding now) that that was considered to be a violation of the Wikipedia policy. I wasn’t really familiar with Wikipedia editing policies at the time, and I disagree with some of them now that I’ve read up a bit, but now I am in the situation of being accused of conflict of interest, when my motivation was to enhance the content.

I won’t deny that I was also proud to have a page on Wikipedia.

A year later, my Debian colleage Josip Rodin stumbled over the article and questioned its notability, and I started to investigate the issue. I’ve talked to Josip and several other people I know about this, and went ahead to change the article in ways to centre its notability around my Debian book, which by then had sold over 20’000 times. That seemed to settle the issue.

Over the course of the next two years, several changes were made to the article, some by myself, but most by other people. Admittedly, the article grew more and more biographical and included more and more information about my involvement in Free software, as well as my research.

In January 2009, a user suggested that my article be merged with the article about my book. A brief discussion ensued, in which I ended up being the “lone dissenter” against two of the content police. My main argument was:

I don’t see a point in merging a person with a book; what is the benefit? It is not like Wikipedia has to save paper, and having separate, interconnected pages rather than single monolithic ones is the spirit of the Web. Notability also comes from my research (which is about to be completed) and work on open-source software.

Again, I can clearly see the conflict of interest, because I obviously view myself as much more important than anything else in the Wikipedia-Universe.

Three weeks later, one of the two policemen called it consensus, because my arguments were considered invalid due to aforementioned conflict of interest.

Around that time, I had the chance to attend LCA in Hobart, where I spoke to several people about the issue, including Angela Beesley, who had in the past worked for the Wikimedia Foundation on editing content and setting policy. I learnt that Wikipedia contributors are split between three camps: Deletionists, inclusionists, and those who don’t care.

Since it was pretty obvious that I was dealing with two people of the deletionist camp, I took this information to the discussion and offered to invite those with whom I had spoken to give their input, and to balance out other instances of conflict of interest in this matter. Nothing came back, and I put the issue on the backburner.

A few days ago, my article was redirected to my book’s article, which I continue to oppose. It seems that the merging policeman is not ready for further discussion, and now I am unsure how to move on.

• I would like to keep the article.
• I do not think merging a person and a book make sense, especially since we’re not saving any paper. I think that such a change diminishes the worth of the online encyclopedia and goes against the spirit of the Web.
• I do not want my name to be redirected to my book’s article; if my article cannot stand, then my name needs to be removed.
• If Wikipedia’s content policy is truly such that my article cannot stand by itself, then I wonder what should happen to many other articles, e.g. in the category of Free software programmers.

I would appreciate if you would email me with any advice.

NP: Tunng: Comments of the Inner Chorus

If you deal with SMTP servers, you probably know swaks, the “Swiss Army Knife for SMTP”. Great tool for anything related to sending mails.

Today, I found its counterpart for receiving mails:

python -m smtpd -n -c DebuggingServer localhost:1025

that binds a no-frills SMTP server to the specified socket which does nothing but talk SMTP to connecting clients and print “received” messages to stdout, e.g.:

---------- MESSAGE FOLLOWS ----------
Date: Fri, 22 May 2009 21:21:40 +0200
To: madduck@madduck.net
From: madduck@lotus.madduck.net
Subject: test Fri, 22 May 2009 21:21:40 +0200
X-Mailer: swaks v20061116.0 jetmore.org/john/code/#swaks
X-Peer: 127.0.0.1

This is a test mailing

------------ END MESSAGE ------------

Sweet, very sweet!

NP: Porcupine Tree: Signify

Take the following URL:

http://my.server.tld/wow/summary/2009/05/21/?style=boxed

and imagine the following Python function:

def summary(request, year, month, day):
    response = HttpResponse()
    // do something
    return response

If you see a relation between the two, then Django is for you. The missing part is a URL mapping, a list of regular expressions, which transforms a URL into a keyword list, and maps it to a function (a HTTP view, as it’s called):

(r'^wow/summary/(?P<year>\d{4})/(?P<month>\d{2})/(?P<day>\d{2})/$',
    mysite.wow.summary, {'additional':'information'})

You do not have to use keyword arguments, positional parameters will work as well, and you can do anything you like within the powers of regular expressions, but the result is always along the same lines:

When someone visits the above URL, Django calls the above summary(…) function (defined in the modules mysite/wow.py) and passes an object encapsulating the request, along with the components from the URL as parameters:

summary(request, 2009, 05, 21, {'additional':'information'})

It then renders the return value. The function can also throw an exception if it need to communicate e.g. a 404 error. Very clean, and there are even generic views if your data doesn’t need any massaging, of if you just want to do standard things like generate PDFs.

This is the core idea of Django, which I’ve gathered from one talk and four hours of invested time. It’s a truly thin layer, and its elegance made me bouncey.

The QUERY STRING of the request will be passed in the request object, along with all the other CGI variables you’re familiar with. Django provides a large number of helpers and shortcuts to save you from having to do the ugly work, including topics such as internationalisation, syndication, authentication, file uploads, and caching.

In addition, Django gives you an object-relational_mapper to map the data into, and manage the data definition within your favourite RDBMS, a templating language designed to fit in with the whole philosophy, and widgets to work with forms.

You do not have to use any of those. You are free to use any other Python module for the task, just as you can use all of the other features of and modules written for Python. This is particularly powerful in the context of the middleware layer.

There’s also a large number of pluggable applications and snippets for re-use.

The only concern I have at this point is whether features like tagging are going to find their way into the framework, because tracking numerous external plugins for a site and keeping them working across versions reminds me of the nightmares I had with Zope and Plone (I stopped working with (and on) those before I had a chance to dive into version 3 of each).

The fact that Django leaves data storage to other tools (in fact, it’s entirely up to you) makes those nightmares seem further distant.

All in all, I am excited to have had a chance to take a brief glance at the software, and I am looking forward to doing more with it. Unfortunately, it looks like it will take quite some time to wade through existing plugins and design the rest of an application that can finally replace the horrific dung-pile that is my homepage.

In Myanmar, Aung San Suu Kyi and 2’000 monks and activists are being detained, as the miltary junta in the country presses new, ridiculous charges against Suu Kyi a few days before the end of her house arrest.

Suu Kyi, recipient of the Nobel Peace Prize and proponent of democracy, is leader of the opposition and the greatest threat to the junta’s grasp on power. Given the inhumane conditions imposed upon the Burmese, and the ruthless slaughter of those who do not play by the military’s rules, it is not hard to imagine that she would win any fair election, as soon as she would get a chance to run.

However, if the junta are successful in pushing charges — Suu Kyi is accused of breaching the house arrest after an American man sneaked into her house uninvitedly — she could be locked up until after the elections in 2010, effectively disarming the threat she poses to the military regime.

She is threatened to be kept in the notorious Insein Prison without medical care. As she is suffering from serious illness, this puts her life at risk.

I do not usually campaign for political topics, but I’ve been to Myanmar and this issue touches me deeply.

The people in Myanmar need our support. Even though the 2007 Burmese anti-government protests seriously weakened the military and brought hope to the lives of millions that have been oppressed for years, the events quickly vanished from the media and allowed the junta to regain control.

We must not let that happen again. It is of utmost importance to show our support and not look away. One way of doing so is by increasing visibility. If you care, please write to your newspapers, publish on your blog, and do everything else you can to raise awareness.

Another way to help the Burmese people is through signing the avaaz.org petition to UN Secretary General Ban Ki-moon. Best to do all of the above!

Unfortunately, avaaz.org force-subscribes everyone who signs a petition to their newsletter, which may well not be what you want. However, please do not let it stop you from signing the petition. You can later unsubscribe from the (infrequent) newsletter.

I have informed the staff members of this concern. If you would like to voice your opinion too, write to info ät avaaz dot org and encourage them to make the newsletter subscription optional. But make sure to also sign the petition, please.

Some might dread the feature of “read notifications” supported by certain MUAs; some call it an “invasion of privacy”; and yet, it can also be useful in certain situations:

When a message is read or seen in a MUA supporting this extension, the programme emits a notification back to the sender saying something along the lines of “your message … was read on …”. This is good to know, especially in times when you cannot wait for the failed-delivery-notification that follows four to five days of unsuccessful (but furious) attempts of some delivery agent, assuming it doesn’t get trashed as spam.

Such a read notification is logically a reply to the original message, isn’t it?

The RFC 680 proposed in April 1975 defines the header References as a way to point to “other correspondence which this message references”. This header, along with In-Reply-To (defined in the same RFC), is commonly used in every-day mail traffic to refer to previously exchanged messages, and enables mail readers to thread separate messages together into coherent conversations (it takes a human to remove the coherence, the technical aspect is infallible).

Cut.

Microsoft was also founded in April 1975, and it took them 20 years to barely manage to squeeze through the Internet door without the proverbial foot in it. They published a browser and several e-mail programmes, and it always appeared as if they tiredlessly tried to be different from the rest, attempting to form a clique of users, a Microsoft league in which to increase their revenue through network effects. Sounds bad, is bad, but yet again, they managed, through unimaginable feats of entrepreneurial genius and ruthless behaviour.

Cut.

In 1982, STD11 declared the aforementioned In-Reply-To and References headers as standards. At that time, Microsoft software didn’t even know what a computer network was.

Cut.

Does it come as a surprise that read notifications sent by Microsoft e-mail programmes, such as Microsoft Outlook do not make use of either of these standard headers to tag read notifications they send?

Instead, Microsoft pushes Thread-Topic and Thread-Index, which are undocumented and thus probably only work in a Microsoft-only context.

How am I supposed to assume anything else than Microsoft actively trying to oppose standards.

Anyone who boycotts standards is hindering progress and should be left behind. It’s good to see that the Internet society seems to follow that trend more and more.

Update: I found a way to extract the data to recreate the In-Reply-To with procmail. I don’t see a way to do the same for the References header. Also, I’ve only verified that this works for message disposition notifications from Outlook 2003, although I expect it to work for other, similarly crippled MUAs too.

Yesterday was my first appearance as a sardine in Zurich’s public transport vehicles, as part of a campaign by the Swiss group for sustainable mobility, umverkehR, which I support:

We handed out flyers and answered questions, and the general reaction was very positive. The fact that we got covered in Switzerland’s most popular newspaper, 20 Minuten will add greatly to the reconnaisance factor, so that in the months to come, us sardines will be immediately recognised, hopefully provoking thought and chat over the roots of the campaign.

Most of us know the sardine as a dead fish perched into a can with many others in a way to minimise space. Human-sized, walking sardines are a great way to increase awareness of the issue of over-crowded public transport. It was fun to see even the Really Serious Newspaper Readers unable to suppress a smile.

Talking to friends about the campaign, I’ve often been met with expressions of how absurd such a campaign is in Switzerland, possibly the country with the best public transport system world-wide. I agree, but that doesn’t mean that we should not keep working on further improving it. If you’ve ever been stuck in a commuter train during rush-hour, standing around in stifling heat and jealously eyed those that managed to grab a seat before you, you’ll probably agree that even in Switzerland, we could be doing it better.

These days, with the financial crisis weighing heavy on everyone’s budgets, and with environmental concerns on the rise, we are witnessing a never-before level of readiness of the public to make sustainable choices. Confronting those people with stuffed trains doesn’t reconfirm those decision. Instead, it will make those people crave their air-conditioned cars and possibly switch back to polluting the air with exhaust and noise, because it surely is more comfortable to sit in your own cool car than it is to be perched in public transport like a sardine.

Thus, umverkehR’s message goes mainly to the politicians: prioritise public transport in your future mobility plans, keep the prices affordable, and help get people off the road in the interest of our environment.

You can see more pictures in the gallery and a short film on Youtube. We have a separate sardine blog, a Facebook account and there’s even a chance for you to win travel coupons: all you have to do is submit an original photo of anything to do with over-crowded public transport by e-mail or MMS to sardine ät umverkehr.ch by October 2009. You can browse all submissions on Flickr.

I hope that we can spread the idea as far as New Zealand and the countries between. There are always chances in any crisis.

NP: Porcupine Tree: Stupid Dream

Switzerland voted today for the introduction of biometric passports, with 50.1% for and 49.9% against, one of the closest votes since 1848 (according to NZZ). While the news don’t fill me with glee — there are too many unanswered questions around the digital passports — one aspect of the decision surprised and even shocked me.

I do not like biometric passports, because I like to know when my data are consumed, and by whom. The German government “assures” that only “authorised” parties can access those data, and published information about the security features of the German biometric passports, but I am unconvinced that those are adequate to protection for the 10 years of validity of the passport.

Furthermore, I could find absolutely no information on who the “authorised” parties are, or which regulations cover who will become authorised in the near future. If that was properly addressed, e.g. by leaving it up to me and only me to decide who gets access, then the digital passport could actually be a good step forward, streamlining border control and making travel easier.

But there is a completely different avenue of concern, no matter who gives permission to whom to consume whose data: how are they used, and where, and how long are they stored, and for what? Again, I cannot find any regulations. Instead, my question to the German Department of the Interior was answered (!) along the lines of it being up to each country to decide themselves over the use and storage of the data.

In this light, it makes little difference that the German procedure for the digital passport does not permit the issuing bureau to store the data, while Switzerland’s strategy is to build a central database of all these personal details (this is what shocked me). It might make you wonder what use the Swiss government is hoping for, and you might feel uncomfortable with your government building up an even tighter database of its people.

But I’d much rather have my data stored in Switzerland than consumed and stored every time I enter another country, because when I compare the style of governance of Switzerland to pretty much anything else out there, I am glad I get to live here (even though I am not Swiss and cannot vote).

Yet, it’s a worrying step in a direction of the “glass human”, of a society in which personal privacy is unknown and everything is part of the system. These are totalitarian visions, and it’s doubtful whether we’ll ever actually get there (so far, I don’t think any state has come up with the information management strategies required to properly store, make use, and read sense out of the massive amounts of information), but the trend is clearly visible.

In the end, however, what worries me the most is how relaxed people treat their personal information these days. Look at the infamous social networking sites, or other Web 2.0 gimmicks and you really start to wonder how headless people can be these days. I cannot immediately paint a scenario where it might be dangerous to push all kinds of information about yourself to the masses, but the mere idea of that is scary in and of itself.

I’d prefer to have the choice with whom to share what data. The biometric passports, despite the advantages they might bring, are one step away from that, because they empower the government to make that choice for you. I don’t consider that progress at all.

Update: NZZ reports that the issue is not closed. In the cantons of Grishuna and Lucerne, people are challenging the vote and a recount or even re-vote seems possible. I will post an update as soon as I know more. Then, I would also like to address some replies I’ve received over the real problems behind the digital passports, because it cannot be just the central data storage — it’s not like your government doesn’t already have all that, and I can’t imagine how your fingerprint could be used against you.

Would all the paranoid crypto-users please stop flooding Planet Debian with GPG output?

And if you just cannot avoid it, please tag those posts meme, because that’s what they are.

If you really think there’s a need for a new key, you’re one step ahead of me, because so far, there’s only a theoretical attack and the valid question of whether this is actually something to worry about in the context of GPG (or in the context of Git, for that matter). There is no practical exploit out there, and I don’t expect one that would endanger your use of GPG any time soon.

Of course, we ought to replace the current crypto infrastructure with a new one before the current one is compromised, but that should really be motivated by careful consideration and planning, not by lemming-like behaviour and the infamous tipping point.

I’ve long been meaning to clean up my key and may also switch to using a new one in the near future. However, I don’t think there is an immediate need and I’ll take time first to investigate the options — RSA is hardly free from problems or an optimal choice. For instance, why would I want to use an RSA key, which is limited in GPG to 4096 bit keys? Do we really want to deal with signatures that are 4-10 times longer than their DSA counterparts? When RSA is broken, will we see a replay of this whole key-replacing frenzy?

Wouldn’t it make more sense to leverage the current situation and work on pushing/improving the DSA algorithm with larger keys, and to strive towards better algorithms in general, e.g. through SHA-3.

If you still need to replace your key, revoke the old one, point at the new one in the revocation reason, and please refrain from abusing feed aggregators from letting the world know. If gpg cannot follow the trust chain after the revocation, please fix it.

In the mean time, it is a good idea to use RIPEMD160 instead of SHA-1 for signing, with the following lines in ~/.gnupg/gpg.conf:

personal-digest-preferences SHA512 SHA384 SHA256 SHA224 RIPEMD160
default-preference-list […] H10 H9 H8 H11 H3 […]

and to set the preferences on your key accordingly:

% gpg --edit-key $KEYID
> setpref […] H10 H9 H8 H11 H3 […]
> save
% gpg --send-key

Then, make sure RIPEMD160 is being used:

% gpg --clearsign -a </dev/null | grep '^Hash:'

I’ll end with a link to a decent write-up on the cryptographic basics of GPG.