You should probably ignore this post. I'm just venting. I'll be better after a nice cup of tea. Things that are causing me to fume about the fact Gnome Shell just hit Debian/Testing:

• Spacefun came back. Even on GDM3. Just fucking die already.
• I had to reboot to get bluetooth working again.
• /desktop/gnome/shell/windows/workspaces_only_on_primary set by default? SRSLY?
• It failed to carry over my previous monitor settings.
• I'm pretty sure I don't have a latent desire for a machine running OS X, whatever the GNOME devs might think.
• How many mouse clicks to get to the list of applications?
• Er, why have you changed my default apps? (Why is clicking a link in a terminal opening Epiphany rather than a new tab in Iceweasel?)

I update my testing boxes (work + home laptops) almost every day. It rarely breaks, and certainly when it does I accept that's what I get for doing rolling upgrades. I can't remember the last time I did an upgrade that actually made me angry. Also I suspect this thing is going to have a complete fit on my binary nVidia/hacked up DisplayLink configuration at work (the DisplayLink side refuses to do 3D for starters). Perhaps better not to upgrade there until I have a sufficient block of free time. Maybe it's time to go back to evilwm. I only stopped because I wanted a dock for wifi/bluetooth etc applets on my laptop that didn't get hidden when I fullscreened things. Implementing _NET_WM_STRUT might make that doable... (I'm sure some of this is just dealing with the change but it's a bit bloody difficult to deal with a complete change in user interface that hasn't even managed to carry across settings from the old one.)

It s seeming increasingly likely that reports regarding the future of Banshee, Tomboy, and the rest of the Mono stack in the default Ubuntu desktop install are accurate. Ubuntu 12.04 will likely be the first Ubuntu release since 5.10 not to ship with any Mono apps in the default install ending a run of 12 releases over 6 years. The decision seems to have come about during the default apps session at the Ubuntu Developer Summit just ended in Orlando, Florida. Prior to heavy vandalism, the only reasons cited for the change in the UDS session log are Banshee not well maintained and porting music store to GTK3 is blocked on banshee ported to GTK3 . Other reasons mentioned but not in the session logs are complaints that it doesn t work on ARM. I m using a lot of conjecture in this first paragraph because the news about the decision appeared on the blogosphere before anywhere else. The first many Banshee or Tomboy developers read about it was reading a flurry of activity on the Tweetosphere from the anti-Mono activists declaring victory. So first, a word on the cited reasoning. Banshee works fine on ARM, since Mono works fine on ARM. Xamarin, the company behind most upstream Mono work, earns their income almost entirely from ARM versions of Mono, running on the varied ARM implementations found in smartphones. Every major Banshee release is personally tested on my Genesi EfikaMX, an ARM system with a Freescale i.mx51 processor. I ve also demonstrated Banshee running in an Ubuntu chroot on my HP Touchpad, an ARM-based tablet. What is known is that Banshee has some problems running on Texas Instruments OMAP4 processors the target ARM platform for Canonical s ARM work. None of the Banshee upstream developers, Mono upstream developers, or Mono Ubuntu team has ever been able to reproduce the cited problems, since problems specific to an exact ARM chip are impossible to reproduce without the requisite hardware and none of us owns an ARM system matching Canonical s target. That Banshee is still a GTK+2 app is true. A port to GTK+3 is almost complete, but blocking on a single technical bug deep within GTK# s guts, which could be fixed by someone with sufficient knowledge of GTK+ semantics. Nobody with the required GTK+ knowledge has stepped forward with a fix at this point in time. As for the final point, that Banshee is not well maintained, this seems like a directed personal insult against the active and responsive Banshee maintainer, Chow Loong Jin, and upstream bug triager David Nielsen, in addition to the immeasurable hours contributed free of charge for the benefit of Ubuntu users by various other members of related Mono app and library teams, including myself. I need to stress at this point that my annoyance with this decision has nothing to do with the actual app changes. Keeping Tomboy and gbrainy, at a cost of about 25 meg of unsquashed disk space, is a hard argument to make compared with those two plus Banshee for 40 meg. Dropping gbrainy and Tomboy, and switching to Rhythmbox, will save about 30 meg of unsquashed space, all told.I m unconvinced that Rhythmbox is a technically superior app to Banshee several features which were gained by the first app swap will be lost again but that s another long tedious argument to be had. No, what has me deeply angered is the shambolic way the changes were made and announced. Significant accommodations were made by Banshee upstream in order to make life easier for Canonical to integrate Banshee into their OS. For one thing, that s why the Ubuntu One Music Store support is a core Banshee feature, not part of the third-party community extensions package. If Banshee was being considered for replacement due to unresolved technical issues, then perhaps it would have been polite to, I don t know, inform upstream that it was on the cards? Or, if Canonical felt that problems specific to their own itches required scratching, then is it completely beyond the realm of possibility to imagine they might have spent developer resources on bug fixing their OS and sending those fixes upstream? Or even and call me crazy providing access for upstream to specialized hardware such as a $174 Pandaboard to empower upstream to isolate and fix unreproducible bugs specific to Canonical s target hardware? And here s where it gets more astonishing for me Canonical paid money to ship one of the community-based packagers responsible for the stack, Iain Lane, to Orlando for UDS, and didn t think it was worth bothering to perhaps inform him hey, the stuff you work on is in danger of being axed from the default install, maybe you should go to this session . So I m not cross that the stuff I work on has been removed from the default install. I intend to continue working on it as I have for the last 4 years, through my work in Debian. No, why I m cross that I heard about it from fucking Boycott Novell. Regardless of your opinions regarding Banshee or its stack, if you read the above and don t see it as an abysmal failure of community engagement by a company whose community manager wrote a book on the damn topic, then there s something seriously wrong with your understanding of how community labour should be seen as a resource. Maybe someone at Canonical should try reading Jono s book. It s not a first-time offence, and this mail from a PiTiVi developer regarding changes in 11.10 makes for useful further reading. [edit] There is some worthwhile discussion going on on the ubuntu-desktop mailing list covering the technical issues surrounding the decision, I would suggest it s a good place for ongoing technical discussion.

Friday David Pr vot reminded me about the statistics for release critical bugs I used to publish during the squeeze release cycle, and asked if I could enable them again. After tweaking the script generating the statistics a bit (mainly a s/squeeze/wheezy/g) the stats will be again published weekly, every Friday at 13:05 CET. The first report is already available, and it seems it is about time, that we got the Wheezy Bug Squashing Party Marathon started! So, see you at the first BSP in Hildesheim.

This is a follow-up on a previous post: I used a bit of a rainy Sunday to read some docs and write some Python, and I now have a script that converts events from a Guitar Hero World Tour drums controller to MIDI. A brief explanation of how it works: in its standard configuration, the drums controller has five pads and a pedal, and it uses a Wiimote to communicate the events (what pad was hit with what force, or what button was pressed/released, or the position of the mini-stick) to the Wii itself. This communication happens over Bluetooth and not over a dedicated cable or protocol, so it is possible to remove the Wii and use a standard computer with Bluetooth (built-in or via a dongle) instead, and the computer will receive messages. There's some decoding to do, but fortunately people have reverse-engineered the frames, and come up with the libcwiid library and its Python binding, which hides the complexity of the decoding and just delivers structured data to the programs that use it. Then we analyze this data and extract the relevant info from it (with some juggling of bits): "the X pad was hit with force Y". From there, it's a simple matter of mapping the pads to a MIDI note and the force to a MIDI velocity, and of sending the appropriate MIDI message to the target, for instance with the libportmidi library. What you do with the MIDI output is your call: I use it to add more pads to my electronic drum kit, but it could equally be used to drive a software synthetizer, or an external sound module. Or a light-show machine. Or fireworks. Or a model railway. Or whatever. Here's the current version of the wiigh2midi.py script (for updated versions, see the Bazaar repository).

#! /usr/bin/python
import cwiid, time, asyncore, pypm
class Wiimidi:
    wiimote = None
    midiout = None
    lastaction = time.time()
    wii2color =   27: 'kick',
                  25: 'red',
                  17: 'yellow',
                  15: 'blue',
                  14: 'orange',
                  18: 'green'  
    color2midi =   'kick': 36, # Bass drum
                   'red': 38, # Snare drum
                   'blue': 48, # High tom
                   'green': 43, # Low tom
                   'yellow': 42, # Closed hi-hat
                   'orange': 52, # Crash cymbal
                    
    def connect_wiimote(self):
        print "Press 1+2 on the Wiimote..."
        try:
            self.wiimote = cwiid.Wiimote()
        except:
            self.wiimote = None
            return None
        print "Connected."
        self.lastaction = time.time()
        self.wiimote.rumble=1
        time.sleep(.2)
        self.wiimote.rumble=0
        return self.wiimote
    def disconnect_wiimote(self):
        if self.wiimote is not None:
            print "Closing connection to the Wiimote."
            self.wiimote.close()
            self.wiimote = None
        return
    def connect_midi(self):
        for i in range(pypm.CountDevices()):
            interf,name,inp,outp,opened = pypm.GetDeviceInfo(i)
            if outp == 1:
                if name == 'UM-1G MIDI 1':
                    self.midiout = pypm.Output(i, 0)
                    return
        for i in range(pypm.CountDevices()):
            interf,name,inp,outp,opened = pypm.GetDeviceInfo(i)
            if outp == 1:
                print i, name," ",
                print
        dev = int(raw_input("Type output number: "))
        self.midiout = pypm.Output(dev, 0)
    def wiimote_callback(self, messages, timestamp):
        self.lastaction = time.time()
        m = messages[0][1]
        # rx = m['r_stick'][0]
        ry = m['r_stick'][1]
        l = m['l']
        # r = m['r']
        which = ( (l << 1) & 16) + (ry >> 1)
        softness = l & 7
        if softness == 7 or which == 0:
            return
        # print "rx=%d\t ry=%d\t l=%d\t r=%d\t rest=%d" % (rx,ry,l,r,rest)
        # print "which = %d, softness = %d" % (which, softness)
        strength = 7-softness
        color = self.wii2color[which]
        midi_vel = 16*strength
        midi_note = self.color2midi[color]
        self.midiout.WriteShort(0x9a,midi_note,midi_vel)
        self.midiout.WriteShort(0x9a,midi_note,0)
        # print "%s %d -> %d %d" % (color, strength, midi_note, midi_vel)
    def main(self):
        self.connect_midi()
        while True:
            if self.wiimote is None:
                self.connect_wiimote()
                if self.wiimote:
                    # Tell Wiimote to display rock sign
                    self.wiimote.led = cwiid.LED1_ON   cwiid.LED4_ON
                    # We only care for the extension data
                    self.wiimote.rpt_mode = cwiid.RPT_EXT
                    self.wiimote.enable(cwiid.FLAG_MESG_IFC   cwiid.FLAG_REPEAT_BTN)
                    self.wiimote.mesg_callback = self.wiimote_callback
                    self.lastaction = time.time()
                else:
                    print "Retrying... "
                    print
            asyncore.loop(timeout=0, count=1)
            if self.lastaction < time.time() - 3600:
                print "An hour passed since last action..."
                self.disconnect_wiimote()
            time.sleep(0.05)
        print "Exited safely."
# Instantiate and run
inst = Wiimidi()
inst.main()

There are a few obvious improvements to be made: first, handling guitar controllers in addition to drums. Second, handling the buttons could provide extra "pads", to trigger sound effects for instance (thunder, lasers, voices ), or to initiate program changes, or to change the mappings of the pads. Maybe storing the mutable parts (default MIDI adapter, pad-to-note mapping) in a configuration file. Maybe add a user interface to ease the configuration. Patches welcome, otherwise maybe I'll do that myself on another rainy Sunday. Notes and references (in other words, the giants on whose shoulders this program stands):

• As mentioned, this script uses the pyPortMidi binding, available in Debian Wheezy as python-pypm (and easily backported to Squeeze).
• It also uses the Python bindings to CWiid, available in Debian as python-cwiid.
• I based the pad-to-MIDI mapping on the relevant part of the General MIDI specification.
• The bit-mangling operations used to map cwiid messages to plain data were worked out by comparing the tables from the Wiibrew wiki on the classic controller and the drums controller.
• The skeleton of the script was initially based on MythPyWii, although not much of it still remains.

More cowbell!

Ugh, in the last year and a half I've only posted once. With the move to Ireland, starting a new job, and then using too much Google+, I forgot about this blog thing. So, to start with something easy, I'll tell you about some films I watched recently. This weekend I had a marathon of films, after sometime without watching any, I watched two at home and two at my favourite cinema in Dublin: the IFI, which I recommend to anyone living here. First, on Friday, I watched Brazil, the 1985 classic from Terry Gilliam. It was a long overdue obligation to watch it, and some discussions with a friend about cinema made me finally do it. It was an amazing film. Among the many memorable scenes, and cinephile winks, I liked the one copying the famous Odessa steps sequence. The problems related to its US release reminded me a bit of the problems with the edition of Touch of evil, although in the case of Brazil, what the big studio did to the film was to butcher it. On Saturday I continued on the Gilliam streak and re-watched 12 Monkeys, which I had forgotten completely. Another great film, with a clearly bigger budget, it does not rely on the money but in the plot, art, and acting to be memorable. Also, I love the main theme, a tune from Astor Piazzolla called "Suite Punta del Este". Just after finishing the film, I read that some people from the local Couch Surfing group were meeting at the IFI to see one of the many features of the Polish film festival that took place this weekend. So I went and saw A short film about killing, a powerful and shocking movie about the death penalty. Considered by many to be one of the most horrifying depictions of a killing (two, in fact), it didn't shock me as much as some other films had done, maybe it was because of the cinema overdose... Anyway, it was another must-see. IMDB asserts that the Polish government suspended the death penalty in Poland for five years after the release of this film, but I could not find sources to confirm this. This morning I woke up pretty early, which is completely uncommon for me on a Sunday. So I decided to use the tickets offered by the IFI for a pre-screening that I had assumed I would not use, since I had to be in the cinema at 11! This time it was an Irish documentary about Bernadette Devlin, called Bernadette: Notes on a political journey. It was really interesting, even if I had never heard about this important figure of Ulster politics in the sixties. Sadly, because of my ignorance on the topic (and some northern accents that I have trouble understanding), I missed many parts of the film. In any case, it has increased my appetite to know more about the Troubles, which had started when I visited the Republican neighbourhood of Belfast, specially Falls road. Tags: Life, Planet Debian

I am currently sitting in the train to Goslar, where the German Conference on Cheminformatics will take place. As part of the Free Software Session, I will give a session on DebiChem. This is the first I attend this conference and I am looking forward to meet Noel O'Boyle and hopefully others from the community.

In light of this, I have packaged and uploaded RDKit and Cinfony over the last weeks and also updated the Debichem task pages, introducing a Cheminformatics Task at the same time. I feel we still need at least tasks for Chemical Education (to expose e.g. Kalzium more prominently), and possibly Protein Docking and Crystallography. So if you have experience/opinions in these fields (or want to propose other fields), drop me a mail or contact us at debichem-devel@lists.alioth.debian.org.

I must admit that I ve never been a big fan of the dash as /bin/sh change. I have three main problems with the switch: POSIX compliance as an argument Complying to standards is a really good thing. But when everybody is ignoring the standard because they want the comfort of newer features, maybe it s a sign that the standard should be updated to include those newer features. Most of the bashims used everywhere in scripts were signifiant improvements, like the ability to write:
cp short1/path1,short2/path2 /very/long/common/path/to/a/file
instead of:
cp short1/path1/very/long/common/path/to/a/file short2/path2/very/long/common/path/to/a/file The option to improve bash was not fully explored We started with the premise that bash is bloated, slow, and cannot be improved. Maybe you can help me with that, but I could only find a few simplistic benchmarks comparing dash and bash, and I could not find any analysis of why bash is slow, and why it cannot be improved.
One of the obvious problems is that bash is also an interactive shell, and is linked to ncurses and terminfo, which increases the startup time. But have we investigated the possibility to have a /bin/bash-non-interactive binary that would not be linked to ncurses? The change was brought to users While it is OK for Debian (or Ubuntu, in that case, since that change was done in Ubuntu first) to force its developers to use POSIX-compliant scripts, the switch could have been made only to Debian-created scripts (by switching them from a /bin/sh shebang to a /bin/dash shebang, for example). I have trouble justifying that this change was forced on users as well. Next: linker changes and we are doing it again. A set of linker changes (see also the Ubuntu page) was already done in Ubuntu, and is very likely to be done in Debian as well. This switch requires deep changes in some buildsystems (it requires ordering of libraries and forbids indirect dependencies), and is rather painful (it was reverted before the Ubuntu 11.04 release because it was not possible to fix all the packages during the natty release cycle, but is done in the 11.10 release). Of course, there are justifications for this change. But I m not sure that it s worth all the trouble created for users.

It's about time that Rapha l is interviewed in the "People behind Debian" series he initiated on his blog. Indeed, when he interviews people, Rapha l asks about other people they could suggest for next interviews. So, during mine, I suggested him to be a next "victim". As he couldn't interview himself, I volunteered for this. As you'll see below, Rapha l (who's a friend of mine as I'm a friend of his) likes to speak and that shows in the length of his answers :-) but you always know more about Debian when reading his blog posts, books, mails, etc. I personnally think that he is among the best promoters of the project for years and it was a pleasure for me to conduct this interview. My questions are in bold, the rest is by Rapha l. Who are you? Hi, Rapha l Hertzog, I'm a 32 years old French Debian developer who is married and who has a 2-year old son. I'm running my own company (Freexian) since 2005, I started it 3 years after the end of my computer science studies. I'm also a very proud author of the Cahier de l'Admin Debian, a French book about Debian. You often wrote about your attempts to make your living partly, if not completely, out of your Debian work. Can you describe the way you're trying to do this? My first try has been with Freexian. I always advertised this company as being specialized in Debian GNU/Linux. While Freexian is successful enough to provide me a decent income, I'm not really satisfied with the result because very few of my contracts are about improving Debian. I use Debian daily for the benefit of my customers, writing new customer specific (embedded) software, deploying a service on Debian servers, etc. But except for the occasional bugfix, all this work does not improve Debian (the only exception has been the dpkg multiarch implementation work sponsored by Linaro). The positive side is that I don't need to fill my entire schedule to earn enough money to live. So I'm regularly taking some days off work to be able to contribute to Debian. This is a freedom that I enjoy... My French book has also been a bestseller and depending on the years the royalties represented between 1 and 2 months of supplementary time that I can spend on Debian (that is between 2000 and 4000 EUR of income). Now since last year, I decided to actively work towards my goal of making a living out of my Debian work. I want to build on what has been most successful for me up to now, that is my book. My strategy has been to build an audience around my blog: with a direct contact with my readers I have the opportunity to sell e-books, and without any intermediary taking the biggest part of the price, I don't need a very large audience to be successful. I have also been experiencing micro-donations with Flattr, people who are enjoying my articles on my blog can use it to give a few cents for each article they find useful. With a large enough userbase, this could fund free documentation and would avoid the need for commercial e-books but we're not there currently and I don't know if it will ever reach the critical mass. Last but not least, I'm soliciting donations for my Debian work on the sidebar of my blog, and I have the chance to a have a few (regular) donators. You're a proud father since last year. How do you manage your commitment to the project with your family life? There are few things that I put above Debian in my life, but my family certainly is. I try to handle most of my Debian duties during work hours so that I can spend time with my family on evenings and during week-ends but in truth I never really disconnect from Debian. It happens quite often that I say to my wife I'll come in a few minutes, let me finish this and then I end up responding to a Debian mail, or an IRC query and take 30 minutes instead of the 5 expected ones. I try hard to avoid this but it's difficult. Luckily for me, my wife is very supportive of my Debian involvement and knows me well... By the way my wife is using Debian on her computer, and my son has already played with DoudouLinux (a Debian derivative!). Have you already been accused of self-promotion in your writings? If that would ever happen, what would you answer to that? Yes, more than once. I am proud of what I do for Debian, I enjoy sharing the result of my work. Because of this, some people believe that I'm selfish and egocentric. And this has somewhat increased since I have been soliciting donations: for me it's important to be transparent towards donators so that they see what I really do for Debian. But some people have the feeling that I'm getting undeserved attention and that I bring everything towards my own person. On the other side, as an author, I'm a public figure who is definitely seeking some attention... I don't have any miraculous answer, we are a large and diverse community, it's next to impossible to please everybody. I listen to all the concerns that people bring forward, I take them into account as much as possible, in particular when I believe they are reasonable/well justified, or when they come from people that I highly respect. But sometimes I have to plainly ignore them too... in particular when they are trying to impose their own political view on a topic that's not directly related to the only value that we all share: the social contract. Contributing to Debian is a challenge, we all have to make efforts to put aside our differences and to concentrate on the work that brings us closer to the best free software operating system ever built. You recently launched a campaign to free out the soon-to-be-published "Debian Administrator Handbook", an English version of your well-known book about Debian in French. Can you tell us more about this project? My French book has been very successful at helping people to get started with Debian, and like I already explained, it was also effective to fund a part of my Debian work. So I wanted to make it available world-wide by publishing an English translation of it. I tried to find an English-speaking editor willing to take on the challenge but I found none interested. Not put off by a setback, Roland (my co-author) and I decided to negotiate with our French editor Eyrolles to recuperate the necessary rights to translate the book into English. Handling everything ourselves represents a lot of work, but it also means that we have the freedom required to decide of the license of the resulting book. We would love to see it under a license compatible with the Debian Free Software Guidelines. But at the same time we firmly believe that we deserve a reasonable monetary compensation for the work on the book, so we conditioned its liberation to a predefined amount of money (25 K ) in what we call the "liberation fund". And since we wanted to be sure that we would have the required means to complete the translation, we used a crowfunding platform to seek support of people interested by the book. With such a platform you're only debited if the minimal requested amount is reached. Anyone can participate, pre-order the book and/or put some money in the liberation fund. As of today, we already reached the minimal funding goal (15 K ) so the book translation will happen. But the liberation target has not yet been reached so we don't know yet if the book will be free from the start... you can follow the progress right on the fundraising page or on the website dedicated to the book. PS: If you want to contribute to this project and also make a donation to Debian at the same time, you should check out this page. You're one of the main developers of dpkg, a critical tool for Debian systems. Can you tell us more about the current development challenges it is facing? What will be the new dpkg features for wheezy? The current challenges are not really technical. dpkg is a relatively mature piece of software and it will continue to work for the foreseeable future without needing much maintenance work. The real challenge is trying to setup a healthy developement community around it so that we can keep tackling new interesting problems (there are many listed in the roadmap and in the 225 wishlist bugs). There is a real problem of leadership and communication in the current team. We used to be three, and we're only two nowadays. Guillem is the legitimate leader since he's involved in dpkg's developement since early 2006 while I joined only in late 2007. But in the last 4 years, we did not manage to recruit anyone else on the team. Some persons tried to contribute significant new features (like Sean Finney with a rework of the way we handle configuration files) but they gave up frustrated after a while because we did not manage to review their work (and discuss the design) in any reasonable timeframe. Another famous case is Ian Jackson with his trigger work. His work got merged, but so late that in the mean time he blew up while trying to hijack the maintenance of dpkg. For a long time I was concentrating my work on the Perl part of dpkg (aka dpkg-dev mainly), so I did not feel qualified to review and merge work related to the C part and I was just a worried observator of this situation. I tried to improve it by setting up some basic review infrastructure, it should have brought some lisibility to the status of each change left to be reviewed... but it has not been used and it changed nothing. Over the years, I became much more interested in the C part. My first big contribution in C has been the rewrite of update-alternatives (from Perl to C). I made other small changes in between, but at the start of this year I had this great opportunity to work on the multiarch implementation (FYI, multiarch is the possibility to mix packages from several architectures on a single system). This really forced me to jump into the C codebase and learn a lot about how dpkg is implemented. Thanks to this I have been able to tackle other small projects (like the improved triggers). This would be all great if my multiarch work was already merged, but it's not. It's a large work, I do not mind waiting a bit in particular since Guillem is a highly skilled C programmer. His sharp analysis of new designs are invaluable, when he reviews code he always finds something to improve. I learnt a lot just by reviewing the code he wrote over the years. That said I have been waiting since April without almost no updates from him. With the release team asking us to hurry up, the situation is getting somewhat strained as I really want to see multiarch in Wheezy and I do not really want to short-circuit Guillem. Hum, I may have drifted a bit from your original question... what great new features can people expect? Well multiarch is supposed to be the big new feature, apart from that there aren't many things that matter to the end users. But there are already quite a few changes that are of interest to package maintainers (like hardened build flags, source package improvements, improved triggers, ). What's the biggest problem of Debian? Manicheism and a tendency to quickly polarize the discussions. In reality, there are very few situations where everything is all good or all bad. Ever since I have read The 7 Habits of Highly Effective People I try hard to put into practice the habits of interdependence . Instead of having only my point of view in mind, I try to understand the motivations from the other party ( Seek First to Understand, Then to be Understood ) in order to be able to put forward solutions acceptable to both parties ( Think Win-Win ). I highly recommend this book to anyone. And I invite everybody to at least try to follow those simple advices. Is there someone in Debian you admire for their contributions? There are many and I can't give an exhaustive list... here are some that I would like to highlight (in no particular order):

• Niels Thykier for the work he puts into Lintian, and his recent work on a britney test-suite (the software that creates testing out of unstable);
• Joachim Breitner for his britney reimplementation using a SAT solver;
• Adam D. Barrat for his work on britney2;
• All the release team members who take care of an endless stream of transitions;
• Christoph Berg for his continuous work over the years on various QA infrastructure (DDPO, Mole, );
• Enrico Zini for the way he helped reform the New Member process without any big disruption;
• Russ Allbery for his Debian Policy work and for being a model in terms of how we should interact on Debian mailing lists;
• Stefano Zacchiroli for being the most active leader that I have ever seen, and for the way he tries to steer important discussions to a constructive conclusion.
• etc.

Most of those people are working on improving Debian's infrastructure so that we can all be more effective and do an even better work. This kind of work is not always very visible but it's crucial to Debian's future. Thank you to Rapha l for the time spent answering my questions. I hope you enjoyed reading his answers as I did. And, anyway, it was fun to just play the game "the other way".

So, there is some history of organisations doing a poor job at managing security bugs. We saw the This is not really a security hole jokes just to avoid having bad statistics in the front page. We saw the OMFG you must update to the latest version RIGHT NOW and no I m not telling why panic. We still frequently see security fixes hidden in unrelated public commits, just to make them harder to backport for distributors. But really, there is absolutely no match for that. Kudos for setting a new standard in the worse way of dealing with security issues, guys. Update: one of the developers has started insulting a pair of professional IT security experts who came and tried to educate him. Awesome reading, don t forget the popcorn.

I have been a long-time user of the Galeon web browser, which, while powerful for its time, is getting a bit long in the teeth and has been abandoned for a long time. As a result I need to find something new. As Galeon uses the Mozilla engine I figure switching to Iceweasel/Firefox will be the least amount of pain since they share similar formats for lots of the user configuration and data (with the exception of history). Switching to Firefox also gives me access to a lot of configurability and a vast sea of extensions all written in RDF, JavaScript and zoooool (ahem, XUL). Another plus was that I was already using Firebug for the occasional web development project. Looking at the Mozilla addons site is like entering someone's shed. There will be the few beautiful unfinished projects still being worked on, one polished finished scuplture gathering dust but still admirable, things with power plugs from a bygone era, some things that have a coin slot on them, some cryptic machines with no visible screws or manuals, some spiders and their cobwebs and a few rats and mice chewing through things. A place where you can find some excellent, well documented, useful and Free Software extensions alongside lots of crud. Luckily for me the good stuff that I wanted to use was already in Debian or the friendly Debian Mozilla extension maintainers team was willing to package them for me. In my quest for freedom from Galeon I first noticed that there is no up button in Iceweasel. Bummer, I use that a lot so I went searching for extensions. I soon found one extension, but it hadn't kept up with the ever-changing Mozilla APIs so it fell by the wayside. Thanks to the leavers of breadcrumbs I picked up the trail to a new shiny and working extension. Lo-and-behold I found Uppity, which was all about going up and as it turns out, much better at that than Galeon. Thanks to MozExt team, thats solved, next! The next glaring problem was the lack of Galeon-style smart bookmarks. Before you ask, yes, Firefox smart keyword bookmarks are not the same thing. This was rediculously hard to search for due to the wording used by both projects being same same but different. Some folks switched to Epiphany to get the extra search boxes on their toolbars. Like this guy I was not interested in that, mainly due to the addons I would be missing out on. I tried a few different tacks, even searching for a way to have multiple search boxes in the Firefox toolbars. I soon gave up on finding an extension that would do this like Galeon does so I figured its time to roll up the sleeves and learn some zzzoooool. I already know a little bit about JavaScript and CSS so... First slap a dash of a tutorial about adding toolbar buttons, add a slither of adding extensions without installing them, stare down some Mozilla reference manuals, thrown in a pinch of favicons, give up on a wild goose chase or two, add a big fat blob of zoooool and sautee in fugly hacks. Soon enough you will have something hardcoded that works like Galeon smart bookmarks but looks even better. I may eventually turn this into a proper and functionally equivalent extension for Galeon-stlye smart bookmarks but for now it will remain a useful hack. If you want to get your hands dirty with zzzoooooool and try this out after modifying it to use your personal search URLs, please feel free to contact me. For now the only remaining issue I can see is that the forward/back buttons in Iceweasel don't have the explict menu buttons. This is a minor issue for me so now it is time for me to figure out how to migrate my data and config¹ before permanently switching away from Galeon. Wish me luck! 1. Of course the data and config are fugly, but that is a something for another, much broader and more complicated hack

Wow, a lot (of travel) has happened in the last three months. Zoe has been to Chicago, Langkawi, Brisbane, and is now back in Mountain View. I'm actually feeling really guilty about our carbon footprint for this year. She spent the last about 3.5 weeks in Brisbane with Sarah after the wedding in Langkawi, until I flew there last weekend for my sister's wedding. Losing and finding Smudge helped pass the time, as did having Liam stay with me while he was visiting from Zurich. I could have done without the former, but really appreciated the timing of the latter. There was quite a noticeable vocabulary difference when I finally saw Zoe again. I can't keep up with all the words she can say now, and she's starting to grasp concepts as well. For example, she opened a small cardboard box, and declared it "empty". Apparently we say "uh oh" a lot, as this is one of her favourite things to blurt out whenever anything happens, ranging from my sister's bridal train dragging on the ground at her wedding, to vomiting all over herself in the back of the car. She's definitely not going to be a girly girl. When the flight from Brisbane landed in Los Angeles she yelled out a big "WHOA!" and then "Again!" while furiously doing the baby sign language for "more". Fortunately we were able to oblige for the flight from LAX to San Jose, and she again enjoyed the landing (she got to sit in her own seat for this one) and did a loud "Wow!" and "Again!" I'm looking forward to taking her on her first roller coaster ride. Her canine teeth still haven't come through yet, but I think they've just started to make an appearance. We're still trying to de-jetlag her at the moment, so it's unclear if the wake-ups throughout the night are because of jetlag or teeth issues (or a combination of both). She handled all of the travel fairly well, although she's now too long for a aeroplane bassinet. She didn't get a lot of sleep on the 12.5 hour flight from Brisbane to Los Angeles (which meant we got none), but she was pretty well behaved for the bulk of it. She's good enough on her legs now that she can just tear up and down the aisles without incident, so we made countless laps of the plane to keep her occupied. The return flight was on Halloween, and the cabin crew had gotten into the spirit with temporary face tattoos, some cabin decorations and some "costumes". The trip back home was actually epic in that it was littered with minor annoyances, but I'll save that for a separate blog post. This Christmas should be a fun one, as she'll be old enough to be a bit more interactive about the whole thing. She may also freak out sitting on Santa's knee, so we may not get quite as nice a photo as we got last year.

When George Papandreou announced its will to submit the European help program to the approbation of the Greek people, I don t know whether he wanted to scare people, but man, he really achieved something. From Wall Street to the Bundestag, through the lys e Palace, they are all in a state of advanced panic. There s a joke that s been circulating since: for next Hallowe en, disguise yourself as a referendum. Yes, these guys are afraid. Afraid of the people. They are afraid because it is now clear that their interests are not the same as the interests of the people. And what do you do when you are afraid? Well, you find yourself some way out, often by lying. And indeed, Mrs Merkel and Mr Sarkozy have been repeating over and over something that has been then repeated over and over by most so-called journalists: that Greeks can only choose between two endings:

1. they pay their debts to banks and rich people, and stay in the Euro zone;
2. they don t pay their debts to banks and rich people, and find themselves another currency.

That s it: Mrs Merkel and Mr Sarkozy are outrageous liars. There is another option for Greek people:

3. they don t pay their debts to banks and rich people, and they stay in the Euro zone.

It s as simple as that: nothing in European treaties can force a country to leave the Euro zone. And nothing in these treaties can force a country to honor their bonds. Greece is a sovereign state and, as such, can choose not to honor its sovereign debt. And choose to stay in the Euro zone: why would they want to go out? What does it have to do with the currency those bonds have been emitted in? If California were to cease payment of its public debt (something not likely to happen at all, hmm?), would it have to abandon the Dollar? But here is a thing that has been forbidden for a long time in European treaties: for a country to help financially another one to pay its debts. This rule was introduced by Jacques Delors (a man who knows what being European means) precisely in order to avoid the contagion we are facing currently because of stupid help plans all across Europe. Yes: the whole idea of Merkozy s grand plan to save Euro while helping Greece (a weird kind of help, starving people, really) is illegal. So in addition to being liars, Mrs Merkel and Mr Sarkozy are delinquents. So let Greece cease payment of its debt. A few banks will sink: so what? This will create less unemployment than letting our whole economy sink. European States will guarantee citizens savings up to 30 k , that s one of the other clever European rules (some countries guarantee more). Other people, rich people only, will lose their savings. Will that prevent you from sleeping? Not me. But that could prevent from sleeping a number of friends of Mrs Merkel s and Mr Sarkozy s. And wouldn t that be a good reason for lying and violating European treaties?

See also parts 1, 2, and 3. I am a person that enjoys food that s different from what s at home, and Rhodes didn t disappoint. Terah and I used to live close to an excellent Greek restaurant in Indianapolis, so we were already familiar in some way with the food. But there isn t any Greek restaurant at all in the Wichita area, so we missed it. Our favorite restaurant on Rhodes was Kalypso of Lindos. Everything there was just excellent, starting with the saganaki, one of my favorite Greek appetizers. I had yogurt with honey there for dessert both times we visited, a surprisingly tasty desert. Like many restaurants in Lindos, Kalypso had the option of eating on the rooftop, or at ground level. We ate on the roof, which had a nice view of the Lindos Acropolis. Being outdoors, there were sometimes cats around. This kitten enjoyed playing games with my shoestrings for awhile. Kalypso is at a 17th century captain s house. Here s a view of it from the rooftop: We, of course, had the chance to eat at quite a few different places during our visit, and I d go on way too long if I mentioned them all. Terah particularly enjoyed the gelaterie.gr ice cream shop in the square in Rhodes. We liked our lunch at Maria s Taverna in Lindos and enjoyed chatting with the staff there. I recently talked about shopping in Mexico, and perhaps learned a thing or two from that. I won t say we never buy them, but in general we don t buy souvenirs like t-shirts, plastic things made in China, etc. We prefer to buy local. Those items tend to be higher quality, more interesting, and we like to support the local economy. We also don t have lots of room for things, so we try to choose carefully. So it was something of a surprise to Terah, and perhaps even to me, when I suggested we go shopping one day. Terah typically enjoys shopping a lot more than I do. Anyhow, off we went to Lindos. One of the first things that had caught our eye in Lindos was the shop selling glass. But it wasn t just any glass; it appeared to be made with some sort of layered process, and has a distinctly three-dimensional feel to it. As you move around, it looks like the background shifts. We wound up with this item, which was made in Athens: By the time we visited Lindos specifically for shopping, we had a good feel for when the busy times of day were, so we could avoid them. It gave us the opportunity to visit with people and when they weren t busy, many shopkeepers liked to chat. I enjoy hearing people s stories and we heard several. One ceramics shop the Musa Shop -caught Terah s eye. They had such incredible and beautiful pieces outside that we just had to go in. We wound up with two pieces from there, both in shades of blue: Both remind me of the Aegean Sea and the deep blue sky of Rhodes. And then, as we were walking along, I pointed inside a shop and said to Terah, Hey, those look different. We went in, and eventually wound up buying these: The appearance, and even feel, of them is unlike anything I d seen. Quite interesting. And seeing those particular items in the Lakis Place shop led to making some new friends I ll write about it in the next post.

What to get the files older than today? Run

find /path/ -type f -daystart -mtime +0

it will return only the files older than today, no matter the time the command is executed (by default, -mtime counts multiples of 24 hours from now). Kinda nice when you want to archive yesterday log files.

I care a lot about free network services. Recently, I have been given lots of reasons to be happy with the progress the free software community has made in developing services that live up to my standards. I have personally switched from a few proprietary network services to alternative systems that respect my autonomy and have been very happy both with the freedom I have gained and with the no-longer-rudimentary feature sets that the free tools offer. Although there is plenty left to do, here are four tools I'm using now instead of the proprietary tools that many people use, or that I used to use myself:

• StatusNet/identi.ca for microblogging (instead of Twitter): I have had my account since the almost the very beginning and am very happy with the improvements in the recent 1.0 rollout.
• Diaspora for social networking (instead of Facebook): Diaspora has made important strides forward recently and has become both quite usable and quite useful. Not having used Facebook, I've not managed to totally figure out where the system fits into my life, but I do periodically post updates that are more personal and less polished than the ones on my blog. I still have not set up my own pod but look forward to work that the Diaspora team is putting into making that process easier.
• NewsBlur for feed reading/sharing (instead of Google Reader): NewsBlur can be thought of as a replacement for Google Reader and is, in my opinion, much better even before one considers issues of autonomy. You can install the code yourself or pay the author a small amount to host it for you (he will do it for free if you are following under 64 feeds).
• Scuttle for social bookmarking (instead of Delicious): In the wake of Yahoo's sale and shutdown of Delicious, there is a renewed interest in free tools for social bookmarking. Scuttle, a rather mature project, seems to have been one of several beneficiaries. My Scuttle installation is at links.mako.cc.

In trying to switch away from proprietary services, I have found that there still a lack of good information comparing the different systems out there and giving folks advice on who might be able to help with things like setup or hosting. I really value hearing from other people about what they use and what they find useful but finding this information online still seems to be a struggle. The autonomo.us wiki seems like the natural place to host or summarize this discussion and to collect and share information useful for those of us slouching (or running) toward autonomy in our use of network services. I invite folks to get involved in improving that already useful resource. For example, this week, I spent a few hours researching free social bookmarking tools and produced a major update to the (already useful) social bookmarking page on the autonomo.us wiki. Of course, I can imagine lots of ways to improve that page and to collect similar information on other classes of network services. Please join me in that effort!

My son is being encouraged to lie. It's a fairly regular occurrence around here, and I'm sure you've seen it yourself. It's that checkbox on the website you're visiting where you say "Yes, I am over X years of age".

There are many system administration and configuration management tools available, I've mentioned them in the past and we're probably all familiar with our pet favourites. The "biggies" include CFEngine, Puppet, Chef, BFG2. The "minis" are largely in-house tools, or abuses of existing software such as fabric. My own personal solution manages my home network, and three dedicated servers I pay for in various ways. Currently I've been setting up some configuration "stuff" for a friend and I've elected to manage some of the setup with this system of my own, and I guess I need to decide what I'm going to do going forward. slaughter is well maintained, largely by virtue of not doing too much. The things it does are genuinely useful and entirely sufficient to handle a lot of the common tasks - and because the server-side requirement is a HTTP server, and the only client-side requirement is CRON it is trivial to deploy. In the past I've thought of three alternatives that would make it more complex:

• Stop using HTTP and have a mini-daemon to both serve and schedule.
• Stop using HTTP and use rsync instead.
• Rewrite it in Javascript. (Yes, really).

Each approaches have their appeal. I like the idea of only executing GPG-signed policies, and that would be trivial if there was a real server in place. It could also use SSL because that's all you need for security (ha!). On the other hand using rsync allows me to trivially implement the only missing primitive I actually miss at times - the ability to recursively download and install a remote directory tree. (I solve this problem by downloading a .tar file and unpacking it. Not good. Doesn't cope with template expansion and is fiddlier than I like). In the lifetime of the project I think I've had 20-50 feature requests or comments, which suggests it might actually be used by 50-100 people. (Ha! Optimism) In the meantime I'll keep a careful eye on the number of people who download the tarball & the binary packages... ObQuote: "I have vermin to kill. " - Kill Bill

[Latest version of these instructions can be found at the SFML Wiki] CMake allows your project to be built in various environments, including command-line make, Code::Blocks project files, Eclipse project files, etc. It's used in SFML 2.0. In this tutorial we'll write a simple CMake configuration file with centralized version numbering, and see how to integrate SFML in it. The source files First, create a cmake_modules directory and copy FindSFML.cmake in it. FindXXXX is automatically searched by CMake's find_package command. Then create a main.cpp, for instance:

#include "config.h"
#include <iostream>
#include <SFML/Window.hpp>
using namespace std;
int main(int argc, char* argv[])  
  cout << "Version " << myproject_VERSION_MAJOR << "." << myproject_VERSION_MINOR << endl;
  sf::Window screen(sf::VideoMode(800, 600), "myproject");
  bool running = true;
  while (running)  
    screen.Display();
   
 

We use a config.h file that is built by CMake, let's also create a config.h.in file:

#define myproject_VERSION_MAJOR @myproject_VERSION_MAJOR@
#define myproject_VERSION_MINOR @myproject_VERSION_MINOR@

And place your project license (such as the GNU GPL) in a file named COPYING. CMake configuration Let's describe our project configuration in the CMakeLists.txt file:

cmake_minimum_required(VERSION 2.6)
project(myproject)
# Set version information in a config.h file
set(myproject_VERSION_MAJOR 1)
set(myproject_VERSION_MINOR 0)
configure_file(
  "$ PROJECT_SOURCE_DIR /config.h.in"
  "$ PROJECT_BINARY_DIR /config.h"
  )
include_directories("$ PROJECT_BINARY_DIR ")
# Define sources and executable
set(EXECUTABLE_NAME "myproject")
add_executable($ EXECUTABLE_NAME  main.cpp)
# Detect and add SFML
set(CMAKE_MODULE_PATH "$ CMAKE_SOURCE_DIR /cmake_modules" $ CMAKE_MODULE_PATH )
find_package(SFML 1.6 REQUIRED system window graphics network audio)
target_link_libraries($ EXECUTABLE_NAME  $ SFML_LIBRARIES )
# Install target
install(TARGETS $ EXECUTABLE_NAME  DESTINATION bin)
# CPack packaging
include(InstallRequiredSystemLibraries)
set(CPACK_RESOURCE_FILE_LICENSE "$ CMAKE_SOURCE_DIR /COPYING")
set(CPACK_PACKAGE_VERSION_MAJOR "$ myproject_VERSION_MAJOR ")
set(CPACK_PACKAGE_VERSION_MINOR "$ myproject_VERSION_MINOR ")
include(CPack)

The interesting part is:

# Detect and add SFML
set(CMAKE_MODULE_PATH "$ CMAKE_SOURCE_DIR /cmake_modules" $ CMAKE_MODULE_PATH )
find_package(SFML 1.6 REQUIRED system window graphics network audio)
target_link_libraries($ EXECUTABLE_NAME  $ SFML_LIBRARIES )

• First we specify where we stored the FindSFML.cmake module.
• Then we request CMake to look for it in the system, and search for the specified modules (here I specified them all).
• Last, we tell CMake to link our executable with the SFML libraries that it just found.

Compilation To build with Make and the GCC compiler on the command-line:

cd build/  # a separate directory so we can easily remove all the CMake work files
cmake ..  # generate Makefile's
make

To create Code::Blocks project files:

cmake .. -G "CodeBlocks - Unix Makefiles"

and open project.cbp with Code::Blocks. Installation CMake supports the classic:

make install

It also supports DESTDIR, useful in packaging:

make install DESTDIR= pwd /myworkdir

You can also define CMAKE_INSTALL_PREFIX when invoking cmake to change the default install path (/usr/local under Unix). DESTDIR would still override this setting. Packaging You then can use cpack to make a project release:

# Binary package:
cpack -C CPackConfig.cmake
# Source package:
cpack -C CPackSourceConfig.cmake

You will get a nice myproject-1.0.tar.gz, among others. Further information

• CMake has built-in help, for instance:

$ cmake --help-variable CMAKE_SOURCE_DIR
cmake version 2.8.5
  CMAKE_SOURCE_DIR
       The path to the top level of the source tree.
       This is the full path to the top level of the current CMake source
       tree.  For an in-source build, this would be the same as
       CMAKE_BINARY_DIR.

• Reference for v2.8
• CMake Tutorial

As you will know, every file on a unixoid system has some meta-data like owner, group and permission bits. This is of course also true for files part of some Debian package. And it is not very surprising that different files should have different permissions. Or even different owners or groups. Which file has which settings is of course for the package maintainer to decide and Debian would not be Debian if there were not ways for the user to give their own preferences and have them preserved. This post is thus about how those settings end up in the package and what is to be observed when doing it. As you will also have heard, a .deb file is simply a tar archive stored as part of an ar archive, as you can verify by unpacking a package manually:

$ ar t reprepro_4.8.1-1_amd64.deb
debian-binary
control.tar.gz
data.tar.gz
$ ar p reprepro_4.8.1-1_amd64.deb data.tar.gz   gunzip   tar -tvvf -
drwxr-xr-x root/root         0 2011-10-10 12:05 ./
drwxr-xr-x root/root         0 2011-10-10 12:05 ./etc/
drwxr-xr-x root/root         0 2011-10-10 12:05 ./etc/bash_completion.d/
-rw-r--r-- root/root     19823 2011-10-10 12:05 ./etc/bash_completion.d/reprepro
drwxr-xr-x root/root         0 2011-10-10 12:05 ./usr/
drwxr-xr-x root/root         0 2011-10-10 12:05 ./usr/share/
--More--

(For unpacking stuff from scripts, you should of course use dpkg-deb --fsys-tarfile instead of ar gunzip. Above example is about the format, not a recipe to unpack files). This already explains how the information is usually encoded in the package: A tar file contains that information for each contained file and dpkg is simply using that information. (As tar stores numeric owner and group information, that limits group and owner information to users and groups with fixed numbers, i.e. 0-99. Other cases will be covered later.) The question for the maintainer is now: Where is the information which file has which owner/group/permissions in the .tar inside the .deb, and the answer is simple: It's taken from the files to be put into the .deb. This means that package tools could simply be implemented first by simply calling tar and there is no imminent need to write you own tar generator. It also means that the maintainer has full control and does not have to learn new descriptive languages or tools to change permissions, but can simply put the usually shell commands into debian/rules. There are some disadvantages, though: A normal user cannot change ownership of files and one has to make sure all files have proper permissions and owners. This means that dpkg-deb -b (or the usually used wrapper dh_builddeb) must be run in some context where you could change the file ownership to root first. This means you either need to be root, or at least to fake being root by using fakeroot. (While this could be considered some ugly workaround, it also means upstream's make install is run believing to be root, which also avoids some -- for a packager -- quite annoying automatisms in upstream build scripts assuming a package is not installed system wide if not installed as root). Another problem are random build host characteristics changing how files are created in the directory later given to dpkg-deb -b. For example an umask which might make all files non-world-readable by default. The usual workaround is to first fix up all those permissions. Most packages use dh_fixperms for this, which also sets executable bits according to some simple rules and has some more special cases so that the overall majority of packages does not need to look at permissions at all. So using some debhelper setup, every special permissions and all owner/group information for owner groups with fixed numbers only needs to be set using the normal command line tools between dh_fixperms and dh_builddeb. Everything else happens automatically. Note that games is a group with fixed gid. So it is not necessary (and usually a bug) to change group-ownership of files withing the package to group games in maintainer scripts (postinst,...). If a user wants to change permissions or ownership of a file, dpkg allows this using the dpkg-statoverride command. This command essentially manages a list of files to get special treatment and ownership and permission information they should get. This way a user can specify that files should have different permissions and this setting is applied if a new version of this file is installed by dpkg. Being a user setting especially means, that packages (that means their maintainer scripts) should not usually use dpkg-statoverride. There are two exceptions, though: Different permissions based on interaction with the user (e.g. asking question with debconf) and dynamically allocated users/groups with dynamic id. In both cases one should note that settings to dpkg-statoverride are settings of the user, so the same care should be given as to files in /etc, especially one should never override something the user has set in there. (I can think of no example where calling dpkg-statoverride --add without dpkg-statoverride --list in some maintainer script is not a serious bug: Either you override user settings or you are using debconf as a registry. Moral To recap, your package is doing something wrong if:

• Your maintainer scripts unconditionally change permissions of files within the package (Those should either be set within the package or you miss user configuration in dpkg-statoverride).
• Your maintainer scripts call dpkg-statoverride --add without having checked first whether the user already has done so with different values.

Many people around me switched to Chrome or Chromium. I also used it for a bit, but I was a bit disappointed about the extensions available. To show why, here's a list of the extensions I've currently installed:

• Adblock Plus: I guess everyone knows this. It sits quitely in the background and removes quite a bunch of eye-distracting stuff from web pages. You see the web differently and are always confused when viewing pages on your smartphone.
• British English Dictionary: Pretty self-explaining. Firefox has an integrated spell checker and that one needs a dictionary.
• BugMeNot: You can right-click on a login field and let it insert BugMeNot data automatically. I don't use it often enough to remember that it's there.
• Certificate Patrol: SSL's X.509 trust model is weak, to say the least. This extension implements the "save on first visit" trust model and warns you if the certificate or the CA of a URL changes.
• Download Statusbar: If you're used from, say, Chromium to see your download progress above the status bar, this extension will give you that. I don't like the separate window, especially with Awesome as my window manager.
• Firebug: Most people know this, too. Very useful when you do web development. You can see the effects of CSS as you type, for instance.
• Flashblock: YouTube has its HTML5 trial, so you don't need Flash for it. Sadly I had to give in recently (for live streaming sites like the German Parliament, go figure) and have it installed for "emergency" cases. But really nobody needs Flash advertisements or other silly Flash animations, so Flashblock will conveniently refuse to load the Flash plugin unless you tell it to.
• German Dictionary: As above.
• Google Translator for Firefox: Translates marked sections on a web page in place. It lets Google guess the source language, so you really only mark the area, click the button and be done.
• Greasemonkey: Modifies web pages in place to make them more sane, using little scripts. I use two currently:
• Better Outlook Web Access (OWA): For odd reasons I'm forced to use OWA 2007 at a company of Windows and Mac users. This makes it a little bit more bearable, by allowing you to save your password and by adding a message preview pane. You really don't want to use OWA Light 2007 without this.
• Tagesschau.de - video tag: A simple script that lets you watch videos on tagesschau.de without resorting to Flash. They ship Theora videos alongside H.264, which is supported by Firefox out of the box.
• Lazarus: Form Recovery: This already saved me many, many times. Sometimes I hit the stupid Thinkpad page back/page forward keys, or the browser crashes or I'm torn away from a page in another way. This extension keeps your form content mostly save, so that you don't need to start from scratch. A must have.
• Live HTTP headers: curl -D usually works. But sometimes you need authentication and cookies and stuff, hence doing it in the browser makes sort of sense.
• Modify Headers: I don't really use it anymore. There was this legend that YouTube lets you watch videos that are blocked in your country (Hello, GEMA, I'm looking at you!) if you provide a X-Forwarded-For header with an IP from another country. Never worked for me.
• Mozilla Archive Format: If you need to archive a web page or want to collect a bunch of pages for offline reading, this is the way to go. You can conveniently select either single pages or several tabs to be stored.
• Perspectives: I'm paranoid, so here's the second SSL certificate check. Perspectives uses a bunch of network notaries hosted on PlanetLab to check if everyone sees the same certificate. Together with Certificate Patrol that means if that you save a self-signed certificate on first visit if the notaries all agree that it's the currently installed one.
• PwdHash: Password re-use on different web sites is bad. There are sites where I'm not very concerned about the strength of my password, but where I don't want to leak my main ones. PwdHash uses the domain name and the password I give as components to a hash function. So if I'm at a computer without access to my saved passwords, I can easily reconstruct the hash. If need be, I can use the JavaScript on the developer's web site to do that.
• RequestPolicy: It's currently installed but I don't think it will stick around much longer. Too many sites are using embedded cross-site requests, which this extension will allow you to review. As an example every Blogger site that's on a custom domain (like my blog) will trigger it. Instead half of your web will have red flags everywhere full of blocked requests. Not that helpful. Interestingly enough it also polices Flash's outgoing web requests. Which breaks even more often than normal web pages.
• Secure Login: This gives you a button (or a keyboard shortcut) that allows you to choose from several logins and then goes on and posts those credentials securely to the page in question, bypassing any JavaScript that might want to see them. You also get auto-login bookmarks for those sites which don't allow you to remain logged-in across browser sessions. (Like OWA.)

If Firefox on Android were quicker to start and faster overall, I might even use it there. But as-is it's not very useful. Sadly this also means that I can't use Firefox Sync on my phone and as I don't use Chrome on my desktop I also can't use Chrome to Phone. So I usually go and build a QR code on my laptop and read that with Android's Barcode Scanner.

Of course I'm actually using Iceweasel and I'm very grateful for Mike Hommey's efforts to track the release channel on mozilla.debian.net.