Yesterday, I've unpacked new toy - ColorHug. It came in small packet with CD (which is unfortunately not that useful as it should be), mini USB cable and a letter from Richard Hughes. First attempt to use was of course just connect and make it work :-). The basic access works out of the box:

$ /usr/lib/colorhug-client/colorhug get-firmware-version
1.0.3
$ /usr/lib/colorhug-client/colorhug get-hardware-version
Hardware Version 1
$ /usr/lib/colorhug-client/colorhug get-serial-number
000019

Unfortunately calibration with colord does not yet work out of the box on Debian due to bug 655888. Hopefully it will be fixed soon and it will work nicer. For now you have to rebuild Argyll with Colorhug support (with extra pain caused by Debian package using different build system than upstream). I won't provided binary packages as I pretty much gave up after effort to build clean packages from same sources on i386 and amd64, which always failed on patched autoconf based build system. Side note: I somehow hoped that I won't hit new (in meaning that I don't know them) open source projects which do not use some version control. Unfortunately Argyll CMS is one of such projects... After this update (and restarting GNOME), when connecting ColorHug, the Gnome Color Manager pops up and man can calibrate the screen. The biggest problem is to make ColorHug hold on desired place on screen, if it is not close enough to screen, you will get really bad results. The first result is of course far from being perfect, but colors are definitely better than without calibration or with ICC profile shipped with notebook.

Filed under: Debian English Photography 0 comments Flattr this!

Last year I shared my Debian related goals for 2011 . I tend to put more goals than what I can reasonably complete alone and this year was no exception. Let s have a look.

1. Translate my Debian book into English: PARTLY DONE
   It took more time than expected to prepare and to run the fundraising campaign but it has been successful and the translation is happening right now.
2. Finish multiarch support in dpkg: DONE BUT NOT ENTIRELY MERGED YET
   Yes, multiarch support was already in the pipe last year in January. I completed the development between January and April (it was sponsored by Linaro) and since then it has mostly been waiting on Guillem to review it, tweak it, and integrate it.
3. Make deb files use XZ compression by default: TRIED BUT ABANDONED
   After discussing the issue with Colin Watson and Joey Hess during debconf, I came to the conclusion that it was not really desirable at this point. The objections were that debian-installer was not ready for it and that it adds a new dependency on xz for debootstrap to work on non-Debian systems. I believe that the debian-installer side is no longer a problem since unxz is built in busybox-udeb (since version 1:1.19.3-2). For the other side, there s not much to do except ensuring that xz is portable to all the other OS we care about. DAK has been updated too (see #556407).
4. Be more reactive to review/merge dpkg patches: PARTLY DONE
   I don t think we had any patch that received zero input. We still have a backlog of patches, and the situation is far from ideal but the situation improved.
5. Implement the rolling distribution proposed as part of the CUT project and try to improve the release process: NOT DONE
   We had a BoF during debconf, we discussed it at length on debian-devel, but in the end we did nothing out of it. Except Josselin Mouette who wrote a proof of concept for his idea. For me testing is already what people are expecting from a rolling distribution. It s just a matter of documenting how to effectively use testing, and of some marketing by defining rolling as alias to testing.
6. Work more regularly on the developers-reference: PARTLY DONE
   I did contribute some new material to the document but not as much as I could have hoped. On the other hand, I have been rather reactive to ensure that sane patches got merged. We need more people writing new parts and updating the existing content.
7. Write a 10-lesson course called Smart Package Management : NOT DONE
8. Create an information product (most likely an ebook or an online training) and sell it on my blog: NOT DONE
   This was supposed to happen after the translation of the Debian Administrator s Handbook. Since the translation is not yet over, I did not start to work on this yet.
9. By the end of the year, have at least 1/3 of my time funded by donations and/or earnings of my information products: NOT REACHED
   My target was rather aggressive with 700 each month, and given that I did not manage to complete any information product, I m already very pleased to have achieved a mean amount of 204 of donations each month (min: 91 , max: 364 ). It s more than two times better than in 2010. Thank you! Note that those figures do not take into account the revenues of the fundraising of the Debian Administrator s Handbook since they will be used for its translation.

That makes quite a lot of red (for things that I did not achieve) on the other hand I completed projects that I did not foresee and did not plan. For instance improving dpkg-buildflags and then merging Kees Cook work on hardened build flags was an important step for Debian. This was waiting for so long already

2 comments Liked this article? Click here. My blog is Flattr-enabled.

(This is not quite a Dear lazyweb post. If anything, it's Dear lazyweb, I've done my homework, now what? ) I'm looking for the ultimate distributed filesystem. Something that's simple to use, redundant, fault-tolerant, and still smart enough to avoid the more obvious performance chokepoints. Ideally, it should work for all of the following sets of files:

• Music files. They're currently stored on a plug computer at home and served over DAAP, but DAAP seems to become less and less of a priority for music players (I'll keep the music players suck rant for another post), and it has its inconveniences too. Ideally, the files should be integrated in the filesystem of my work computer, the one that serves as a media player in the living-room, the one I use for playing the backing tracks when I'm practising the drums, and the laptop I use when on the road too.
• Backups. My BackupPC currently runs on the plug computer at home, so backups of my remote servers are in a geographically distinct location; but backups of my home computers are not, and I'd like to change that without having to copy files around by hand. Backups do contain confidential data, so this adds a constraint on the filesystem.
• Bazaar repositories. I do have a script that pushes and pulls stuff across computers for the many repositories I use, but it's still awkward that I need to do that.
• Parts of my home directory, such as my browser preferences and bookmarks, or the database of the Hamster time tracking tool, or the working directories of stuff I do for clients, and so on. Again, each of those can be done with specific means (bookmarks synced to a server, CouchDB-like database, DVCS and regular commits, etc.), but wouldn't it be much simpler if there only was one file to begin with?

The requirements on the ultimate distributed filesystem (which I'll call UDFS for short, otherwise you'll get bored and go look at pictures of kittens) are as follows:

• Availability means redundancy: some of the storage nodes will be on dedicated servers in datacenters, others at home; I can imagine setting up the firewall so that the home computers are reachable from outside, but sometimes network links go down, and the home computers are far from being on 100% of the time.
• Availability/redundancy also means automated replication and rebalancing: if a node is added to the grid (or switched on), it should automatically get its share of the files so as to contribute to availability if another node goes down at a later time.
• Confidentiality: at the very least, network communications must be encrypted and authenticated; ideally, individual storage nodes wouldn't need to be able to access the stored data. If I store bits of my backups on a friend's server, I don't want to have to trust them not to look at the data; also, my friend may actually want to be unable to look at my data (to provide for deniability in case someone else wants to look at it).
• Performance: native disk performance may not be realistically reachable, but the system must be smart enough (or configurable enough) to store files on both sides of the ADSL link, for instance, so not all accesses need to go through the bottleneck.
• Integration with the system: I want a filesystem, not a storage system. All applications know how to navigate a mounted filesystem; very few will interface with an specific application designed to store and fetch chunks of data.
• Scalability would be nice, although my personal needs are still well below the terabyte range and I can't see myself using more than a dozen nodes or so.

Quite a few constraints, eh? I have a feeling they are not mutually incompatible though, so I had a look at several candidates. I started with Wikipedia, and I followed the links to Tahoe-LAFS, XtreemFS and Ceph. The following is my evaluation of these candidates based on much reading of docs and websites and wikis, some questioning on IRC, and very little testing.

• Availability/redundancy 1: all three candidates work on the net, and they all provide for data replication. XtreemFS seems to operate on a fall-back mode while the other two are more distributed (meaning there's no canonical node hosting any particular file). Tahoe uses erasure codes (files can be split across N shares, k of which are enough to reconstruct the whole file; the N/k ratio controls the amount of redundancy); it seems to require the introducer node to be always up, which introduces a single point of failure, but this node can be replaced with no loss of data if it fails (this just requires reconfiguring the storage nodes, which can probably be automated). Ceph can work with any number of meta-data servers, so redundancy is assured there (data itself can be replicated in a configurable way too).
• Availability/redundancy 2: either I'm a fool and I didn't find out about that, or none of the three candidates provides for automated rebalancing. Apparently Tahoe provides a way to repair files without enough redundancy, but that needs to be run manually on each file, rather than being systematic, and it's a kind of add-on to the system rather than being properly integrated. Ceph only does rebalancing of meta-data. XtreemFS seems to work a bit like RAID1 with spare disks, but details are scarce.
• Confidentiality: Tahoe wins, hands down. Neither network sniffers nor storage nodes can see the contents of the stored files. They can't even find out about their name or the directory structure. XtreemFS encrypts the data on the network (but it is still stored in cleartext on the nodes). Ceph doesn't even try.
• Performance: Ceph wins (or loses less, at any rate): it seems possible to configure a topology for the storage nodes, and to drive the storage location policy according to this topology; so I could define sets of nodes ( my servers in datacenters , my plug computer at home , my desktop and laptop computers , my friends' computers ) and decide that each file should be stored at least once on each set of nodes. Tahoe stores shares of files on a number of storage nodes chosed in kind of a round-robin way; read access uses the same round-robin system, which means that you will probably end up fetching a file at least partially over your slow link even when you could fetch it entirely from the local network. The XtreemFS website doesn't seem to acknowledge the possibility of the network being slow.
• Integration: Ceph and XtreemFS win: they're native filesystems. Tahoe is in the storage and retrieval system category; the FUSE layer is marked as experimental and not recommended, and the SFTP layer (which can be mounted as a filesystem with sshfs) has many documented drawbacks. Maybe a WebDAV frontend, combined with fusedav, would provide a working alternative, but it's not implemented yet.
• Scalability: all three candidates boast about scalability (in data size and in number of nodes). Ceph seems to require some configuration every time a new storage node is added. Tahoe seems much more dynamic: new nodes (storage or clients) just need to be told where the introducer node is, and then they merge into the grid seamlessly by being told about other nodes (a bit like Bittorrent, where clients learn about each other by asking the tracker).

The overall picture seems full of good things scattered across different solutions, but unfortunately none of the existing ones seems to address the whole problem; at least, not my whole problem. It would be good if each focused on one layer and did that layer well, but that seems not to be the case either, so they can't be combined to get the best of all worlds. It may be that I'm missing something, or that I failed to read some docs properly, or that I misunderstood the docs, or that the docs themselves are simply lacking; but my ideal UDFS currently doesn't seem to exist as a turn-key solution. However, the main pieces are available, and implementing the remaining parts may be doable. My humble idea of a way forward would be based on Tahoe-LAFS, with the following three changes:

• A configurable dispatch policy, so that administrators could define their own behaviour. The current Tahoe parts already turn files into a number of blobs that only need to be stored on various nodes, and the function that chooses which nodes seems to be reasonably self-contained, so it could maybe even be made pluggable, and an administrator could implement a storage policy that matches the constraints and the network topology. Ditto for the function that picks which nodes the data is read from (which, as far as I can tell, is the same; splitting could bring some benefits here).
• A working FUSE implementation, either on top of SFTP if the drawbacks can be fixed, on top of WebDAV if that gets implemented, or native to Tahoe if that can be done.
• Automatic rebalancing of data when new nodes are added or turned on, or when an intermittent network link comes up. The current script seems to be an afterthought; if it can be made more automated and more reliable, I'll be happy with that.

Also nice to have would be a way to work with multiple introducer nodes, but that seems to be in the works already. This would be pretty damn close to my UDFS; read/write performance would certainly be far from what can be obtained on native filesystems stored on local disks, but my use cases involve reasonably small files for which instant access is not compulsory, and the filesystem cache would probably absorb most of the access times. In case anyone is looking for ideas of things to do in their spare time, here are rough sketches of other possible UDFS implementations I thought of. These are wild ideas, and I'm not even sure they could be doable in practice:

• eCryptfs on top of Ceph. The file contents are still only accessible to those in possession of the adequate key, and replication/distribution is handled by Ceph. That could probably work; the main drawbacks I can see come from Ceph's administrative overhead and manual configuration.
• LUKS and a standard filesystem, on top of the part of Ceph that manages block devices (RADOS). I'm not sure this could be mounted simultaneously by several nodes, though.
• LUKS on top of Ceph's RADOS, and Lustre or GlusterFS on top of that? Am I even making sense?
• A kind of union filesystem with local caching, on top of Tahoe-LAFS. Say we take unionfs-fuse, and add local caching: if the requested file is already in cache, performance is near native; if not, we still get the advantages of Tahoe. I'm not sure how caching works with WebDAV, but once Tahoe gets a WebDAV frontend it might be a simple matter of adding a Squid cache between that and davfs.
• I even thought of building a filesystem on top of the Bittorrent protocol; redundancy would be obtained by ensuring that there are at least N distributed copies of a file among the peers. I gave up even before reaching the details phase, though, but maybe a variant of the idea could be workable.

Such is the state of my research so far. I would welcome feedback, pointers to things I neglected to read, corrections for things I misread or misunderstood, comments on the ideas and so on. I'll probably post an update if my search goes significantly forward. Update: I've already received two pieces of feedback, including a lengthy one with corrections about Tahoe-LAFS. For the sake of fairness, I'll solicit (and wait for) the same from the other candidates I looked at. I was also pointed at HekaFS, GlusterFS and git-annex, which I'll have to look at in more details. Other suggestions are still welcome, but the more I get, the more the full update will be delayed. Thanks already!

I just uploaded my unofficial wine-unstable packages to dev.carbon-project.org (I skipped 1.3.36 over the holiday period). These new packages come with an important and often-requested change: they use GCC 4.5 to build the binaries, this works around an upstream GCC bug, see WineHQ bug report #22053 for further details. Unfortunately that clashes with the recent multi-archification on Debian and can lead to FTBFS in an automated build environment (like pbuilder would set up). The reason is the missing symlink from /usr/include/asm to /usr/include/DEB_BUILD_MULTIARCH/asm which then leads to GCC not finding e.g. errno.h (see #638418 for further details). That gives you the following options to make your build work again:

• Change the source package back to using the default GCC (ie. 4.6 at the moment).
• Modify your base.tgz for pbuilder and add the symlink manually.
• Modify the build environment "on the fly". You can either do this with a script in your hook directory for pbuilder (see pbuilder(8) on how to do that) or by setting up the symlink manually while pbuilder is installing the dependencies for wine-unstable (the last option is fragile and requires "good timing").

Otherwise you can also use the pre-built binary packages.

The bug report Simon McVittie reported in Debian bug #654876 that his laptop running Linux 3.0 or 3.1 would sometimes crash (panic) while idle. He initially suspected a driver bug, but the screen did not show any information about where the original fault occurred. However, using netconsole, he was able to capture a full log of the crash. This showed that a packet received through the wireless interface was being processed by IGMP, which then divided by zero. IGMP IGMP is part of the IPv4 protocol suite, supporting multicast routing. Every multicast address corresponds to a dynamic set of hosts, called a multicast group. Multicast routers can send query messages asking which hosts belong to which groups, and hosts using multicast report back at intervals. Routers can then limit forwarding of multicast packets to the interfaces where the group has members. More sophisticated switches can also snoop IGMP and use it to limit their multicast forwarding. There are unfortunately three different versions with semi-compatible message formats. In version 1, the maximum reporting interval (Max Response Time) is fixed as 10 seconds, but from version 2 it is specified in query messages. The Linux IGMP implementation supports all three versions. It distinguishes query messages as specified in RFC 3376 section 7.1: v3 messages are longer than v1 or v2; v2 messages have a non-zero Max Response Time whereas v1 messages always have zero. It is possible to force use of a specific protocol version, but normally if there are multiple multicast routers using different protocol versions it will respond according to the earliest protocol version in use so that all routers can understand its responses. Source and fix for the bug Linux 2.6.36 included two fixes to the version selection logic. Unfortunately, the second of these introduced the bug in question. While v2 query messages cannot possibly have zero Max Response Time (as that would make them v1), v3 query messages can. What this means is unspecified, but the Linux IGMP code previously treated it as the minimum valid value of 1/10 second. But in the case where a v3 query is received and a v2 query has also recently been received, this is no longer done. This results in a reporting interval of 0 seconds and a division by zero when deciding the initial random delay. The fix for this is pretty obvious. It is included in Linux 3.0.17, 3.1.9, 3.2.1, and the Debian package version 3.1.8-2. Security impact This is easily exploitable for denial of service within a local network. Linux does not check the destination address of IGMP queries, so it may also be possible to attack a target through its unicast address from several hops away. The attacker only needs to send a single IGMPv2 query followed by a single IGMPv3 query with zero Max Response Time. All systems running Linux 2.6.36 or later (up to the above fixed versions) with any active IPv4 multicast listeners (other than for the 'all hosts' address) are vulnerable.

The Israeli patent registrar have reverted previous ruling regarding patents on software and published a draft for the procedures to accept such patents. The procedures are open to public comments for the next 30 days. Two years ago the patent registrar have started to consider revising the the issue and got many position papers (e.g. Hamakor s papter). At the end he decided not to accept patents on software. De facto, at least one such patent (US patent 7,596,609) was accepted to be valid in Israel after that ruling. Now that the rulings is reverted, I guess will see many more software patents granted here. I wonder about the implications on the local software market hopefully it won t stagnate due to patent wars such as the ones we see every now and then in the US.
Filed under: Software Patents

Steve McIntyre has been contributing to Debian since 1996, 2 years before I joined! But I quickly stumbled upon Steve: in 1999, he was struggling with getting his debian-cd script to produce 2 ISO images (it was the first time that Debian did no longer fit on a single CD), I helped him by rewriting debian-cd with a robust system to split packages on as many ISO images as required. I remember those times very well because Steve was very supportive of my efforts and it was a real pleasure to get this done. His friendly nature probably also explains why he got elected Debian Project Leader twice! Anyway, enough history, check out his interview to learn more about the great work he s doing nowadays. My questions are in bold, the rest is by Steve. Raphael: Who are you? Steve: I m a professional software engineer, 37, living in Cambridge (England) with my new wife Jo. I studied for the EIST degree at the University of Cambridge, then (like many people here, it seems) I just forgot to go home again afterwards and settled here. I spent more of my study time playing with Linux than working on my degree, so I guess I m lucky that it worked and I found a career in that area! Raphael: How did you start contributing to Debian? Steve: During my time in college, I started hacking on software in my free time, using Slackware as my first Linux distribution from the middle of 1994. After encountering more and more problems with Slackware, I was encouraged by a number of friends to make the jump over to Debian and in October 1996 I did. The installation process back then was much harder than anything people see today, but after a long weekend I finally had my Debian system up and running. I was already one of the main upstream developers for the Mikmod music player at that time, so that very same weekend I applied to be a DD so I could maintain it in Debian too. Back then, the NM process was much simpler: I just mailed a key to Bruce and he set me up with an account almost immediately! I then found that Joey Hess had beaten me to it and already packaged Mikmod. Grrr! Raphael: What s your biggest achievement within Debian? Steve: Without a doubt, my proudest achievement within Debian is being elected Project Leader for 2 years by the other developers. It s a great feeling to have earned the trust of your friends and peers, and also a great responsibility to go and help Debian where needed: talking to the press about Debian, assisting wherever problems crop up, etc. The DPL job is certainly a lot of hard work, and I have nothing but respect for anybody who volunteers for it.

It s a great feeling to have earned the trust of your friends and peers.

Elsewhere, I ve been leading the Debian CD team for years too, both doing most of the maintenance of the debian-cd package and producing and testing the regular installation CDs and DVDs that we ship to the world. Again, this is a time-consuming job but it needs doing and it s worthwhile. Raphael: You re currently employed by ARM. What are you working on and are they supportive of your Debian involvement? Steve: The situation within ARM is very interesting; I m employed in PDSW (Processor Division, SoftWare), a new group founded just a couple of years back to help improve the state of software on ARM. Most of the people in the group are working on Free Software at this stage (e.g. toolchains, browsers, Linux kernel), which is lovely. Some of the engineers have also been seconded into a new non-profit company Linaro, which is a collaboration between ARM and a number of other companies investing in core Linux software and tools for ARM-based CPUs. I m one of the ARM engineers in Linaro, and I m a Technical Architect in the Office of the CTO. My role includes looking at future projects for Linaro to help with (e.g. ARM servers), but for the last few months I ve been concentrating on the new armhf architecture in Debian, Ubuntu and elsewhere. armhf is a new architecture in Debian and Ubuntu terms, but it s not strictly a new type of hardware. Instead, it s a new ABI. We have two reasons for doing this work:

1. It targets the latest version of 32-bit ARM CPUs (v7) and makes better use of the hardware, for better performance. Compare targetting i686 instead of i386, for example. We ll still support the older armel port for the foreseeable future for users with older hardware that can t run armhf.
2. More importantly: we are standardising on the ABI / compiler options / hardware support for future users.

In the past, there has been a huge amount of specialisation (aka fragmentation) in the ARM Linux environment, and that worked OK for specialised devices that only ever ran the software shipped with them. ARM CPUs are now becoming more and more mainstream, so people will expect to be able to install generic software on their machines. That gives a requirement for a standard base platform, and armhf (arm-linux-gnueabihf in GNU triplet terms) is that standard that we are pushing in the community. Debian, Ubuntu, Fedora, Suse and others are all going to use this, making compatibility possible. I ve been working with a small team of people to make armhf happen, helping where needed: putting together build machines; patching Debian packages directly; discussing and fixing toolchain issues with Ubuntu folks; agreeing ABI specifications with people from Fedora; advising people from other distros bootstrapping their new ARM ports. ARM and Linaro are very supportive of this work, and it s been lovely being sponsored to work directly on Free Software like this. It s work that will directly benefit ARM and its partners (of course!), but it s also helping out more generally too: Debian QA work, cross-build support, bootstrapping efforts, multi-arch. More and more of the ARM market is driven by Free Software, and companies are acknowledging that. I should probably also mention that we re hiring ! Raphael: What are your plans for Debian Wheezy? Steve: There are three main tracks here. Obviously, I m interested in seeing armhf release with Wheezy. We ve just been added to Testing last weekend, so that s going well. We ve got over 90% of the archive built now, and we re mopping up the remaining issues. I m the primary maintainer of cdrkit at this point, but I d prefer to have it go away. Xorriso and the associated software in libisoburn is almost capable of replacing all the aging cdrtools-derived software that we have in Debian, The only missing feature that I m aware of is creating the HFS hybrid filesystems that we use for installations on Mac systems. I ve been talking with the upstream folks about this for some time already, and I m hoping we can finish this soon enough that we can get it into Wheezy. Finally, I ve got the ever-growing wishlist of things for debian-cd. We ve got the beginnings of an automated test suite that Mart n Ferrari has written, but it needs integrating and improving. I want to help get regular weekly/daily/release debian-live builds running on the main CD build machine. There s work needed if we want to make good installation media for the new multi-arch world, too. The Emdebian people are asking for help making CD images The list goes on Raphael: The ARM community seems to be very interested in multi-arch. Can you explain why? Steve: There are a number of reasons for ARM people to be interested in multi-arch; two really stand out for me:

• With the historical issues around the plethora of ARM ABIs in the wild, multi-arch will allow us to potentially support multiple ABIs cleanly on one system. That allows users to have (for example) an up-to-date system that makes the most of their current hardware, yet also run legacy programs that might use an older ABI. There s also a new 64-bit architecture coming (ARMv8) which will run older 32-bit software; again, multi-arch makes mixed installation of old and new software reasonable.
• ARM has traditionally been a common target for cross-compilation, and I d expect that to remain the case for a long time to come yet. For a lot of embedded developers, using a big fast i386/amd64 machine to compile is much faster than using a limited-power small ARM CPU. However, setting up sane cross-compilation environments has long been a bugbear for developers. Getting the toolchain and all the cross-architecture libraries to work together correctly can be like black magic. This is potentially the killer app for multi-arch: simply install the libraries for the target architecture directly on your development machine. Install a simple cross-gcc package and (maybe) qemu, and you re all set.

This is potentially the killer app for multi-arch: simply install the libraries for the target architecture [ ], install a simple cross-gcc package [ ] and you re all set.

Raphael: What s the biggest problem of Debian? Steve: For me, Debian s biggest problem has been the same for a long time: we are forever short of enough people to do the work that we re trying to do. That might sound like a weird thing to claim when Debian is one of the largest Free Software projects on the planet, but it s more a statement of just how huge our goals are. Many of the largest things in Debian are developed or controlled by very small teams working very hard, and there s always a risk of losing people due to burnout in those situations.

We are forever short of enough people to do the work that we re trying to do.

Some of the tasks that should be easy given our large membership (e.g. large-scale packaging transitions) can often instead take a very long time. We are fortunate to have more people wanting to join in Debian s work all the time, but we also need to be careful to keep on promoting what we re doing and recruiting new contributors, encouraging them to get more and more involved in core work. Debian gets ever bigger in terms of the size and the number of packages we distribute; we re not currently matching that growth rate elsewhere. Raphael: What motivates you to continue to contribute year after year? Steve: This one is much easier to answer! The thing that first attracted me to Debian was the fact that I could help to develop it, help to decide how things could and should be done within it. Instead of being forced to accept what some corporation decided I could do with my computer, I could change the software to suit my needs and preferences. Alongside that, I could get involved with a strong community of similar people all over the world, all with their own strong opinions about how software should work. I joined in and found it was great fun and very rewarding. That hasn t changed for me in the intervening years, and that s why I m still around. I work on Debian because it helps me to get the OS that I want to use. It seems that lots of people around the world find it useful too, and that s awesome. Raphael: Do you believe that Stefano Zacchiroli will be the first DPL who managed to stay 3 consecutive years on the seat? Would you like him to candidate again? Steve: To be honest, I would be very surprised if Zack stood again for DPL this year. He told me himself that he wasn t planning on it, and I can understand that decision. He s been an awesome DPL in my opinion, and I m glad that he took the job. But: it is also a very difficult and time-consuming task that would be enough to wear down anybody. If Zack does decide to stand again, I would support him 100%. But I know that we also have lots of other good people in Debian who would be ready to take up the challenge next. Raphael: Is there someone in Debian that you admire for their contributions? Steve: There are lots of people I admire in Debian, so many so that I almost don t want to list individuals here for fear of missing people out. But Bdale Garbee has been an inspiration to many of us, for many years. He s technically excellent, a great friend to many of us, an endless source of sage advice and (last but not least) he has some wonderful stories to tell about his experiences over the years. On top of that, he s just cool. Christian Perrier is another exceptional developer, in my eyes he s great at co-ordinating people in translations, working tirelessly to make this very important part of Debian work better and better with every release. He s also a really nice guy and we all love him. I also have to mention Joey Hess here, whether he likes it or not. *grin* He s been responsible for so many good things in Debian over the years, even if he did steal my first package Finally, the teams of people who make sure that Debian is always working: the security team and DSA. The rest of us can choose to take time off from Debian to go and do other things, but these people need to cover things every day. That s a major responsibility, and I salute them for taking on that challenge.

---

Thank you to Steve for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Note that you can find older interviews on http://wiki.debian.org/PeopleBehindDebian.

Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Google+, Twitter and Facebook.

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

I had a bit of an adventure yesterday, which would have taken some explaining if the police had gotten involved. It went a little something like this... My friend and former co-worker Sara was in the US Virgin Islands for the holidays. Her boyfriend, Karl, flew there separately for the tail end of her time there. Yesterday, I received a phone call from Sara, saying that Karl had managed to fly out to the Virgin Islands without his passport. Apparently you can get there without one, but to get back into the mainland US, you need one. She wanted to know if I could get one of my lock-picking co-workers to break into their apartment and retrieve Karl's passport and mail it them. Karl was supposed to fly out the next day. Attempts by Sara to contact her landlord had failed, so they didn't have many other options (apart from mailing me a key, which would have cost them another day). I asked one of my co-workers, Jason, who I knew was into lock picking, if he was up for it, and he offered to put me in touch with another guy who had dominated the recent lock picking night that he'd run. So now I'm talking to David, who's on board with the mission, but doesn't have his lock picking gear on him. No problem, Jason says he'll lend me his, which was at work with him. So we have a plan. Our friends Ian and Melinda are currently in Australia. They've lent us their car because it's leased, and they have some minimum mileage they're supposed to do and they're under it, so I've been driving to work in their car some days. As it happens, I drove to work in it yesterday. So now David and I set out in a car that neither of us own, with a lock picking set that belongs to another person, to break into an apartment of someone who's in the Virgin Islands. What could possibly go wrong? I'm told that it's not illegal to own a lock picking set, but if you're caught with one on your person and you're not a locksmith, you can get into all sorts of trouble. On top of that I'd have a hard time explaining the car I'm driving. We get to Sara and Karl's condo complex. It has a common gate that visitors would normal get buzzed through. Turns out it's not that hard to climb over. It's got some benign-looking spiky things on top, but I could get a leg over from the left hand side of the gate and jump over without impaling myself. Then I let David in and we proceeded upstairs to Sara and Karl's apartment door, where David set to work. Sara said that just the dead bolt was locked. David started at it with Jason's tools, trying to be as discreet as possible. It was about 3:30pm and there was no one around, but we could hear some noises from the neighbouring apartment (the two front doors were right next to each other). After what felt like about half an hour without success (the last pin of the lock was particularly tricky apparently) David was having to resort to more noisy techniques with the lock, so I decided to take the up-front approach and just inform the next door neighbour what we were doing in case he/she (I think it was a she) decided to call the cops on us. I told her through the door why we were there and what we were doing. She didn't seem to care too much. David then proceeded to start "raking" the lock, essentially brute forcing the pins with a lot of jiggling, and finally managed to pick it and we were in. I quickly found Karl's passport where it was suspected to be, and then we pondered how we were going to lock the door again. We could have just locked the door knob instead of the deadbolt and closed the door behind us, but we weren't sure if Sara and Karl had a key to the doorknob (Sara said they always just locked the deadbolt). Sara was fine with leaving the door unlocked until they got home, but weren't so keen on leaving our fingerprints all over the place and then leaving the door unlocked. David tried to re-pick the deadbolt so that he could lock it via the same means as opened it, and I scouted around for a key. I managed to find a key that locked both the deadbolt and the doorknob, so I took that with us and locked up their apartment. In David's defense, the deadbolt was a bit stiff to lock even with the key. I dropped David back at work, collected my stuff (it was now about 4:30pm) and headed to the UPS Store to ship Karl's passport to him as fast as humanly possible. I just made the 5pm pick up. Today I received an SMS from Sara informing me that they had received the passport. I was very impressed with how fast it got to them. So that was all a bit of an adventure. I'm not sure how much longer Karl is going to have to stay in the Virgin Islands as a result. I'm going to suggest that Sara and Karl leave a spare key with someone in future.

A few weeks ago I went on my first cruise, from Sydney to Melbourne on the Dawn Princess. VacationsToGo.com (a discount cruise/resort web site) has a review of the Dawn Princess [1], they give it 4 stars out of a possible 6. The 6 star ships seem to have discount rates in excess of $500 per day per person, much more than I would pay. The per-person rate is based on two people sharing a cabin, it seems that most cabins can be configured as a double bed or twin singles. If there is only one person in a cabin then they pay almost double the normal rate. It seems that most cruise ships have some support for cabins with more than two people (at a discount rate), but the cabins which support that apparently sell out early and don t seem to be available when booking a cheap last-minute deal over the Internet. So if you want a cheap cruise then you need to have an even number of people in your party. The cruise I took was two nights and cost $238 per person, it was advertised at something like $220 but then there are extra fees when you book (which seems to be the standard practice). The Value of Cruises To book a hotel room that is reasonably comfortable (4 star) in Melbourne or Sydney you need to spend more than $100 per night for a two person room if using Wotif.com. The list price of a 4 star hotel room for two people in a central city area can be well over $300 per night. So the cost for a cruise is in the range of city hotel prices. The Main Dining Room (MDR) has a quality of food and service that compares well with city restaurants. The food and service in the Dawn Princess MDR wasn t quite as good as Walter s Wine Bar (one of my favorite restaurants). But Walter s costs about $90 for a four course meal. The Dawn Princess MDR has a standard 5 course meal (with a small number of options for each course) and for no extra charge you can order extra serves. When you make it a 7 course meal the value increases. I really doubt that I could find any restaurant in Melbourne or Sydney that would serve a comparable meal for $119. You could consider a cruise to be either paying for accommodation and getting everything else for free or to be paying for fine dining in the evening and getting everything else for free. Getting both for the price of one (along with entertainment etc) is a great deal! I can recommend a cruise as a good holiday which is rather cheap if you do it right. That is if you want to spend lots of time swimming and eating quality food. How Cruise Companies Make Money There are economies of scale in running a restaurant, so having the MDR packed every night makes it a much more economic operation than a typical restaurant which has quiet nights. But the expenses in providing the services (which involves a crew that is usually almost half the number of passengers) are considerable. Paying $119 per night might cover half the wages of an average crew member but not much more. The casino is one way that the cruise companies make money. I can understand that someone taking a luxury vacation might feel inclined to play blackjack or something else that seems sophisticated. But playing poker machines on a cruise ship is rather sad not that I m complaining, I m happy for other people to subsidise my holidays! Alcohol is rather expensive on board. Some cruise companies allow each passenger to take one bottle of wine and some passengers try to smuggle liquor on board. On the forums some passengers report that they budget to spend $1000 per week on alcohol! If I wanted a holiday that involved drinking that much I d book a hotel at the beach, mix up a thermos full of a good cocktail in my hotel room, and then take my own deck-chair to the beach. It seems that the cruise companies specialise in extracting extra money from passengers (I don t think that my experience with the Dawn Princess is unusual in any way). Possibly the people who pay $1000 per night or more for a cruise don t get the nickel-and-dime treatment, but for affordable cruises I think it s standard. You have to be in the habit of asking the price whenever something is offered and be aware of social pressure to spend money. When I boarded the Dawn Princess there was a queue, which I joined as everyone did. It turned out that the queue was to get a lanyard for holding the key-card (which opens the cabin door and is used for payment). After giving me the lanyard they then told me that it cost $7.95 so I gave it back. Next time I ll take a lanyard from some computer conference and use it to hold the key-card, it s handy to have a lanyard but I don t want to pay $7.95. Finally some things are free at some times but not at others, fruit juice is free at the breakfast buffet but expensive at the lunch buffet. Coffee at the MDR is expensive but it was being served for free at a cafe on deck. How to have a Cheap Cruise VacationsToGo.com is the best discount cruise site I ve found so far [2]. Unfortunately they don t support searching on price, average daily price, or on a customised number of days (I can search for 7 days but not 7 or less). For one of the cheaper vessels it seems that anything less than $120 per night is a good deal and there are occasional deals as low as $70 per night. Princess cruises allows each passenger to bring one bottle of wine on board. If you drink that in your cabin (to avoid corkage fees) then that can save some money on drinks. RumRunnerFlasks.com sells plastic vessels for smuggling liquor on board cruise ships [3]. I wouldn t use one myself but many travelers recommend them highly. Chocolate and other snack foods are quite expensive on board and there are no restrictions on bringing your own, so the cheap options are to bring your own snack food or to snack from the buffet (which is usually open 24*7). Non-alcoholic drinks can be expensive but you can bring your own and use the fridge in your cabin to store it, but you have to bring cans or pressurised bottles so it doesn t look like you are smuggling liquor on board. Generally try not to pay for anything on board, there s enough free stuff if you make good choices. Princess offers free on-board credit (money for buying various stuff on-board) for any cruise that you book while on a cruise. The OBC starts at $25 per person and goes as high as $150 per person depending on how expensive the cruise is. Generally booking cruises while on-board is a bad idea as you can t do Internet searches. But as Princess apparently doesn t allow people outside the US to book through a travel agent and as they only require a refundable deposit that is not specific to any particular cruise there seems no down-side. In retrospect I should have given them a $200 on the off chance that I ll book another cruise with them some time in the next four years. Princess provide a book of discount vouchers in every cabin, mostly this is a guide to what is most profitable for them and thus what you should avoid if you want a cheap holiday. But there are some things that could be useful such as a free thermos cup with any cup of coffee if you buy coffee then you might as well get the free cup. Also they have some free contests that might be worth entering. Entertainment It s standard practice to have theatrical shows on board, some sort of musical is standard and common options include a magic show and comedy (it really depends on which cruise you take). On the Dawn Princess the second seating for dinner started at 8PM (the time apparently varies depending on the cruise schedule) which was the same time as the first show of the evening. I get the impression that this sort of schedule is common so if you want to see two shows in one night then you need to have the early seating for dinner. The cruise that I took lasted two nights and had two shows (a singing/dancing show and a magic show), so it was possible to have the late seating for dinner and still see all the main entertainment unless you wanted to see one show twice. From reading the CruiseCritic.com forum [4] I get the impression that the first seating for dinner is the most popular. On some cruises it s easy to switch from first to second seating but not always possible to switch from second to first. Therefore the best strategy seems to be to book the first seating. Things to do Before Booking a Cruise Read the CruiseCritic.com forum for information about almost everything. Compare prices for a wide variety of cruises to get a feel for what the best deals are. While $100 per night is a great deal for the type of cruise that interests me and is in my region it may not be a good match for the cruises that interest you. Read overview summaries of cruise lines that operate in your area. Some cruise lines cater for particular age groups and interests and are thus unappealing to some people EG anyone who doesn t have children probably won t be interested in Disney cruises. Read reviews of the ships, there is usually a great variation between different ships run by one line. One factor is when the ships have been upgraded with recently developed luxury features. Determine what things need to be booked in advance. Some entertainment options on board support a limited number of people and get booked out early. For example if you want to use the VR golf simulator on the Dawn Princess you should probably check in early and make a reservation as soon as you are on board. The forums are good for determining what needs to be booked early. Also see my post about booking a cruise and some general discussion of cruise related things [5].

• [1] http://www.vacationstogo.com/cruise_ship/Dawn_Princess.cfm
• [2] http://www.vacationstogo.com/
• [3] http://www.rumrunnerflasks.com/
• [4] http://boards.cruisecritic.com/
• [5] http://etbe.coker.com.au/2011/11/17/cruises/

Related posts:

1. Cruises It seems that in theory cruises can make for quite...
2. Combat Wasps One of the many interesting ideas in Peter F. Hamilton s...
3. Victoria Hotel Melbourne I have just stayed at the Victoria Hotel Melbourne. I...

Linux 3.2 was released yesterday. It s been a fairly busy release for ASoC in terms of the subsystem, including the first piece of work at moving the register I/O code over to regmap to eliminate the duplication there, but a pretty quiet one on the drivers front.

• Substantial optimization of the DAPM algorithm, substantially reducing the CPU usage when power states change. This is especially beneficial with larger modern devices.
• Support for CODEC drivers using the regmap API.
• Some smaller API updates support for larger register maps, support for specifying a source when setting a sysclk.
• New CPU drivers for Alchemy and Freescale MXS.
• New CODEC drivers for Analog ADAU1373, Realtek RT5631 and Wolfson Microelectronics WM1811 and WM5100.

The end of the year is a period of time during which many people sit down and decide to donate some money to initiatives that pursue the public good. I have that habit myself. At the end of 2011 I've decided to donate to Wikipedia, as I consider Wikipedia to be one of the greatest achievements of humanity and I see a lot of value in keeping it running on a purely non-profit basis. (Not to mention that it's already quite annoying to see Jimbo's banners one month per year, go figure what would happen if those banners would suddenly turn into permanent advertisement banners!) You may wonder why I haven't donated to Debian, given my involvement in the project. In fact, that involvement is precisely why I didn't donate to Debian: there is some sort of sanity in keeping a distinction between causes to which I donate my spare time (the case of Debian) and those to which I donate money (the case of Wikipedia), and I like to keep that distinction. As DPL, I've the luxury of being cc:-ed on Debian donation notifications that flow through SPI, and I can also check the flow of donations to other Debian trusted organizations. This year, I've been particularly impressed by the high flow of Debian donations during the end of the year. Thank you, donors, it is thanks to your generosity that we keep many Debian activities going. Using the money people like you regularly donate to Debian we:

• buy hardware and hardware-related services that keep the Debian infrastructure running
• sponsor sprints and other events that allow volunteer developers to get together and work on Debian in fun and productive contexts
• support travel expenses of Debian developers that attend conferences or meetings as representatives of the Debian Project

On a more political note, I'm happy to observe that Debian incomes come almost entirely from private citizens. We do have big corporate sponsors, but their contributions tend to be concentrated as specifically earmarked donations for our annual conference. This is good for them, because they get the fancy banners on the DebConf website and at the conference. But it is also good for Debian, because a donation-based economy (as Debian's, with DebConf exception) is less likely to be influenced by the whims of a few big donors. But with (great) donations comes (great) responsibility. In particular, it comes the need of budget transparency. You can't go out soliciting donations and simply say "thanks, your contribution is appreciated". You need to show donors how their money are used, so that they can judge whether they made the right choice in donating to you or not. Whether they will donate again in the future or not granting long term sustainability to your project usually depends on that. So, if you have donated to Debian or are considering doing so in the future, here are a few of places where you can check what we have been doing with donated money:

• Minutes of SPI monthly meetings, that come with monthly reports of incomes and expenses of all affiliated projects
• the list of sprints, past and forthcoming
• "Bits from the DPL" mails (indexed on the DPL "team" page), that often come with a "money" section highligthing significant expenses for the reporting period
• the DebConf reports, that come with detailed "budgeting" sections of each DebConf edition

Albeit quite detailed, the above is not enough: we should do better on the transparency of Debian budget. For one thing, the above is too scattered: budget transparency should not depend on (potential) donors mixing and matching too many sources of information. Further more, the above is not even complete: SPI is not the only Debian trusted organization, and the accessibility of information about Debian budgets hosted at other organizations varies quite a bit. We've been working on improving this for the past year or so: we're not there yet, but I'm positive we can have detailed and comprehensive budgets encompassing all Debian trusted organizations published in the coming months . Why has it taken so long and what could possibly be so difficult about it? I think the cause of the delay is twofold:

1. The disperse nature of Debian adds some difficulties to regular accounting challenges. Contrary to other FOSS projects I'm aware of, we've many different trusted organizations, each one with its own different way of reporting things. The advantage of such a setup is that we can often avoid the costs of money transfers around the world, costs in which we'd incur had we a single organization holding our assets, say, in the US. Still, having too many organizations is counterproductive. This is why for the past 1.5 years I've been working on consolidating our money assets into as few budgets as possible (avoiding, for instance, to use more than one organization per currency).
2. We tend to be good at recruiting packaging geeks, but not so good at recruiting other kinds of geeks: budget geeks, artwork geeks, journalist geeks, management geeks, etc. But it is upon those other kinds of "geekness" that many activities of "standard" Debian geeks depend. For example: if you want to have a steady flow of new project members, you need to communicate effectively Debian values and make some buzz around them, so that you could hope they get to the right ears. If you want to organize sprints for maintainers to work together you need money donations, and to solicit donations you need a transparent budget. Etc. In the specific case of accounting, we're now lucky enough to have found "standard" Debian geeks who also have a passion for accounting and auditing; but that appaears to be, essentially, a coincidence. If we don't fix the more general problem, I believe our difficulties in recruiting "non-standard" Debian geeks might hurt us quite a bit in the long run.

Recently I've been wanting to replace my old point and shoot camera, a Canon PowerShot A620. I've got a pair of DLSR cameras and I do frequently carry one of them out with me, but there are undoubtedly occasions where I'd rather not bother, or where I find myself wanting to take a picture without having one to hand. Unfortunately the PowerShot is pretty large itself, although significantly less so than the DSLRS I possess. (I cannot remember the last time I used the PowerShot outside my flat, that is how rarely it goes outdoors). The PowerShot has been a good camera to me for many years and the three features I liked the most:

• A real view-finder.
• It runs on 4x AA batteries; easy to find.
• Shoots (smallish) movies.
  • This last thing is no longer a concern now I have a Kodak Playsport HD video toy.

Picking a replacement camera, even with the help of fine comparison websites like snapsort.com is hard. Cameras have moved on and "improved" a lot over the last few years - to the extent that finding one with a built-in viewfinder is hard. Finding one with a built-in viewfinder and running on easily replaceable batteries was virtually impossible. Eventually I settled on the Panasonic Lumix FS16, which omits both:

• Integrated rechargeable battery.
• LCD-only viewfinder.

The way that you use the LCD or viewfinder differs pretty significantly, but the LCD wasn't as bad as I'd feared:

ViewFinder

You hold the camera to your eye, and press the appropriate buttons.

LCD

You typically hold the camera at arms length, which means you're prone to shaking your hands/arms and getting blurry shots. Because you're holding the camera relatively far away from your eyes if you have the sun at your back you're liable to need to squint.

The LCD on the Lumix FS-16 isn't amazing, but neither is it horrific and it is better than expected in dark locations. So after a week what do I think? On the whole it is a fine camera, better than the PowerShot in many ways, and while it has draw-backs none are deal-breakers:

Size

The best camera is one you have with you; on that basis this camera is a clear win being smaller, lighter, and more compact than the Canon. I've taken this camera with me, randomly, to several places and returned with useful and interesting images.

Low Light

Low light performance is pretty poor. With only one manual control you see noise if you're shooting in gloomy pubs, and outdoors. With the flash you can get acceptable pictures if you're careful - but its a tricky thing to get right. (To update this a little: Outdoors at night? No. In a pub with poor lighting you'll be alright.)

Manual Controls

The camera features precisely two manual controls:

• "Flash on" vs. "Flash off".
• ISO can be changed from: Auto, 100, 200, 400, 800, 1200 and 1600.

There is no notion of shutter speed, nor is there any ability to change the aperture size. (Though both these values are displayed on the screen as you take a picture I wonder why? As you can't change anything you can't use the information in any useful fashion, and presumably a non-camera-person wouldn't understand what these numbers represent.) The lack of these two controls is a little galling, but pretty common for the low-end P&S cameras.

Video Recording

There is no external MIC so sounds aren't great, but they're not horrible either. Video recordings are limited to the smaller of 8 minutes or 2Gb. So no long films, but short ones look fine. Just be aware that once you start recording focus won't change, nor will zooming work. Compared to the canon the quality is improved; but the Canon allowed you to (optically) zoom whilst recording. Here you can only zoom with your feet.

Recharging Time

When I received the camera it took about an hour to charge. The battery life seems reasonable - the level is 2/3 a week later and I've been shooting, reviewing, and deleting regularly. (Note: I never use USB to transfer pictures, I always remove the card and plug it into my PC. Whether this makes a difference to battery life I don't know.)

Controls

Physical controls are reasonable. There is a mechanical slide-switch to turn on/off. I like that, as it is less prone to being knocked by keys, change, etc. There is also a physical slide-switch to change from "shoot" to "review current images/videos". (Same as my Canon) I think this is a mistake, and don't see why it can't be a soft-button.

Full Auto

There are several modes available in the camera (remember the caveat about lack of aperture/shutter speed) I've been using both full-auto and manual modes, and both are good. Full auto would suit most people - it has clever face-tracking.

Focusing Speed

As expected this is not stellar. Walking to the corner shop the other lunchtime I found a cat in the road, I talked to her and she rubbed herself against my ankles. Could I focus fast enough to catch her looking up at me? No. For static scenes, and candid shots of people it'll suffice. For fast action and moving children probably not a chance.

On balance, the upgrade was worthwhile. ObQuote: "I don't mean to lecture and I don't mean to preach. And I know I'm not your father..." - Spider-Man

That time of the year comes where I summarize my running activities. It's now 4.5 years that I resumed running, after nearly 10 years without active sports. Apparently, things continue to improve, though I'm logically reaching my limits in some way. I finally missed the 2500km mark by 14 kilometers, mostly because of a cold I had during the last 2 days of the year. The grand total is thus 2486 kilometers run, in 237 hours (9 days 21hours), at about 10.5km/h. The climbed height difference is 27700 meters, so about three times the altitude of Mount Sagarmatha..:-) This was achieved in 294 "activities". That seems to be a lot (nearly 1 activity per day): indeed, there are days where I have up to 4 activities, when I run to/back work, which means two runs in the morning (3+4km) and two in the evening. If I count the number of days where I had at least one running activity, this lowers to 181. In short, I ran about every 2 days. Indeed, along the year, the biggest timeframe between two runs has been 7 days. In short, I ran at least once every week during this year. The most active month was July with 272km and the less active was September with 163.5. When counted by distance, this summarizes to:

• less than 5km: 169 activities, 603km, 11.2km/h average
• 5-10km: 38 activities, 308km, 10.8km/h average
• 10-15km: 43 activities, 507km, 10.6km/h average
• 15-20km: 19 activities, 330km, 10.2km/h average
• 20-25km: 13 activities, 281km, 10.8km/h average
• 25-42km: 8 activities, 245km, 9.8km/h average
• over 42km: 4 activities, 208km, 9km/h average

When it comes at results, I ran 8 official races during the year : two "ultra" races (70km Le Puy-Firminy in November, by night and 55km Paris Ecotrail), two marathons (Paris, two weeks after Ecotrail, and Berlin in September), one 35km trail race (Trail des Cerfs in May), two half-marathons and one 12km cross-country race in my hometown. The seasons "peaks" were clearly the Ecotrail+Paris Marathon succession in March/April, the Berlin marathon in September and my longest race ever in November. Most were as successful as I expected, except maybe Berlin marathon, were I was secretly hoping to break my record (indeed, I can still be proud of running in the same race than Patrick Makau breaking the world record in 2h03'38"). An injured ankle unfortunately prevented me to prepare it as serously as I was hoping. This year was indeed the first year where I was trying to go beyond the marathon distance as another challenge. And, believe me, ultra distances are really fun (yes, running 9 hours by night *is* fun!). Indeed, I only regret not breaking one of my best times (either half-marathon or marathon). I'll try to do that in 2012. How about next^W this year? Well, my goals are currently being secured:

• increase distance again by running the 80km Paris Ecotrail race (and this time finishing at Eiffel Tower's 1st floor). That will be late March.
• run two marathons during the year and try to break my 2010 3h40'19" record in one of these. The marathons will probably be the "Courants de la Libert " marathon near Caen and along the D-Day beaches, in early June, and Budapest marathon in early October
• run again the Le Puy Firminy 70km night race in November because I enjoyed it a lot (this race is such a "small" one that it doesn't even have a web site..:-))
• probably run 3 half-marathons in my neighbourhood: Bullion (February), Rambouillet (March, two weeks before Ecotrail) and Bois d'Arcy (September). The latter will likely be an tentative against my best time (1h37'20", same place, in 2010)
• start thinking about a possible 100km in 2013...:-)
• have good runs during my holidays that are likely to happen in Nicaragua in July (guess why?)

Busy program....I cross fingers for no injury to come and disturb all this.

This article could become one of my recurring "let's make noise about translators work" articles. You've been warned. In Squeeze, a few languages reached full completion of debconf strings, those "questions" that are asked during packages installation or upgrades. This can be followed here (for unstable: we don't have an online status page for testing).. Many of you, particularly those who aren't bored at reading me, know that I like pushing this friendly "competition" as a good way to encourage progress in localization of that part of Debian. As of now, we have really good and active teams that are able to maintain a great completion in this. Several of them are likely to reach full 100% completion for wheezy. Let's look at the current status:

• Seven languages are currently the best candidates for full completion: Czech, Spanish, Portuguese, Swedish, Russian, German and French. They will definitely reach 100% in unstable and I'm tracking the status in testing, which is currently excellent.
• The status for Japanese is a bit unclear to me. Though the completion is quite high, I don't witness a constant effort to bring what's incomplete to the complete status. So, I unfortunately doubt it can make it to 100% (Japanese translators, you know what to do to prove me wrong...)
• Vietnamese which is next in the ranking has a specific situation. Its main (by far) contributor, Clytie Siddall (who is a very well known figure in the l10n community for free software as she contributed to Vietnamese l10n of many end-user software), cannot currently do the highly dedicated work she was doing, because real life sucks. There have been tentatives by the local community in Vietname to take this effort over, but they're probably more focused on end-user software than Debian work.
• Dutch and Danish are the best suspects for joining the 100%-fighters club. Both now have at least one very very motivated contributor who's "jumping" on each and any pending l10n work. So, yes, Jeroen Schot and Joe "Dalton" Hansen, you can make it!
• Effort for Italian is not as constant as it could be. It is maybe missing a noisy and hardworking "leader". Still, I know that the team is very active in other areas of localization such as the DDTP (where Italian is leading) so, maybe one person could diverge his her attention for debconf work..:-)
• A few next languages see a more hectic activity: Galician, Finnish and Basque used to have one very active contributor, but recent activity is much much lower.
• Brazilian Portuguese sees some effort but the situation is similar to Italian, here. The pt_BR team is more focused on the DDTP (and does well in this). It might only need a motivated volunteer, but 100% is quite far and the effort would be focused on wheezy+1
• Slovak is indeed one of the good candidates for "could be 100% some day". Progress is currently quite regular but Slavko is starting from very far away and it will take time. Keep going on!
• Other in the ranking are really mostly stalled, so if you language is among them....then, you known what to do!

I hope this maybe gave you the idea of joining these efforts. Please pop up on one of the i18n mailing lists if you're interested, and if you don't know where to start, then debian-i18n< is what you're looking for. See you soon!

Debian is finally transitioning from the unmaintained and Debian-specific font manager called defoma. The replacement is called fontconfig and it is maintained upstream and in Debian (by upstream) and is cross-distribution with wide support from our upstreams and other distributions. With the upload of libwmf 0.2.8.4-9 (thanks Lo c!) the last package in Debian sid declaring a strict dependency on defoma has removed this dependency. There is still more to do, some more bugs to file and some lenny->squeeze->wheezy upgrade testing to do. Thanks go to Christian PERRIER for slogging through and providing encouragement, bug reports and NMUs. The transition is unfortunately not without loss of functionality;

• Xorg does not yet support fontconfig so for now programs relying on server-side fonts will only be able to use the xfonts- packages shipping their fonts in the directories known by the X server. According to Keith Packard it isn't easy to add fontconfig support to Xorg, there are some ways to paper over this though. We could use the Xorg server's font catalogue system to link to a fontconfig provided symlink farm (similar to what is done with defoma & Xorg). We could adjust the Xorg fonts utils to recurse into subdirectories. As far as I can tell, other distributions have completely ignored this issue and not all fonts are available to the Xorg server there.
• There are some issues with Ghostscript and CJK that I do not fully understand, I am hoping these can be resolved before the release of wheezy. We need people to restart work on this issue.

TeX uses a different directory for fonts to the rest of the system. Fonts used by TeX cannot be used by the rest of the system and vice versa. This issue has always existed in Debian and other distributions and is unrelated to the removal of defoma. If your software doesn't use one of the text renderers (such as Pango, Qt or QuesoGLC) that find fonts on their own and fall back on other fonts where needed (due to missing fonts or glyphs), please switch text rendering systems. If you are unable to switch, please use fontconfig to search for font filenames rather than hard-coding them at build time. This message brought to you by the Debian Fonts Task Force. We welcome people who want to help us maintain font packages or improve support and quality assurance for fonts and font related software.

For my lab work, I have developed an (almost) cross-platform program based on Qt4 that help us analyze our data. One of the motivations to use Qt was the ability to port the program to other platforms, and in particular MacOSX (half of my team uses them). After installing the required development tools using MacPorts (mind you, the MacOS version of the development tools, not the X11 one), I was able to compile and run the program without a single code change on my bosses' Mac. But here come problems: several things do not work the same way in Mac and in Linux (whereas it should, I think), so additional tweaking and debugging will be necessary.This is where the problem comes in: I don't own a Mac and don't intend to, so I need to connect to my bosses' Mac in order to perform testing. How can I connect to a Mac display ? X11 connection won't work, since my application is a Mac application and not a X11 one. I had him turn on screen sharing (the most basic tick box), which sets up a VNC server on the Mac. Unfortunately, when I connect using the command-line VNC clients available for debian, ie vncviewer (from the packages xvnc4viewer or xtightvncviewer), I get the following problems:

~ vncviewer chrismac
VNC Viewer Free Edition 4.1.1 for X - built Mar 10 2010 22:31:05
Copyright (C) 2002-2005 RealVNC Ltd.
See http://www.realvnc.com for information on VNC.
Wed Dec  7 10:40:41 2011
 CConn:       connected to host chrismac port 5900
 CConnection: Server supports RFB protocol version 3.889
 CConnection: Using RFB protocol version 3.8
 CConnection: No matching security types
 main:        No matching security types

The good news is that remmina is able to connect graphically, although for me it required that I set the display depth to 24 bits (else it seems to connect, but the connection dies immediately). Great, I'll be able to debug, then...
Edit: after a while, I found out that remmina had some drawbacks when connecting to a Mac, such as, at least in my case, a weird problem with Shift: once I hit Shift, I'm never able again to type in lowercase characters, which is quite painful. I tried also Vinagre, who handled that better (but had some quite painful freezing moment), so I must say that I finally found a client I'm happy with: gtkvncviewer.

One of Django applications I maintain is our internal tool used at SUSE used for managing incoming L3 requests. Recently request to add some API arose (read only for now). Looking at available solutions, I came to conclusion that django-piston should be the best choice for me. Adding simple model based API with it is indeed quite simple, all basic information you need is written in getting started part of their documentation. On the other side, things can never go without problems, so I was hit by well known bug. Fortunately fix exists, though it is not yet merged upstream. While digging so deep into problem anyway, I've submitted a request to include this patch in devel:languages:python OBS repo.

Filed under: Django English Suse 4 comments Flattr this!

* This post is almost translation of my this post on Gujarati blog (with some corrections and additions etc). If you re not interested in Wikipedia, move on. So, as I mentioned here and here, Wikipedians in Ahmedabad planned event: Wikipedia Takes Ahmedabad. We gathered at Gandhi Ashram. Met Noopur again and some volunteers were already there at 8 AM. I never been to Ashram since long time. This place has something, you know it, folks! People started coming around 8.30 and we quickly divided them based upon their interests on 4 routes we already decided. Most of people went to old city s route 1 and our route 2 had odd 6 (and 2 coordinaters) people only. Good. Less is always good. Noopur and Anirudh gave introduction to wikipedia, creative commons license and some basic rules and todo. We then left for Swaminarayan Temple at Sahibaug. We asked for permission to take photographs and we got it after meeting main swamiji there along with nice sweets and he promised to send professional picture for wikipedia to use. We then left for Delhi Darwaja. Ahmedabad has numbers of old fort gates. We covered some of them and moved to Kalupur Railway Station. Palak and Chirag were caught by traffic police and we should take care of following rules from next time. Point noted for next photowalk. We then left for Zulta Minar. This is well known for its carving and some myths associated with it. We discussed some points regarding uploading pictures, categories and left for Raipur Darwaja. This place is famous for Bhajiyas. We didn t taste it but had again fun taking pictures, talking to police and had smile before we leave for home. Only bad thing I ve got in this walk is that due to some or other reason my phone s touch screen seems stopped working That s another topic, but I couldn t call Noopur/Anirudh for lunch etc due to that You can view all uploaded pictures at: Categories: Ahmedabad 1 Most of Ahmedabad is covered due to event. Time to write articles?

This is my monthly summary of my Debian related activities. If you re among the people who made a donation to support my work (364.18 , thanks everybody!), then you can learn how I spent your money. Otherwise it s just an interesting status update on my various projects. Dpkg and Multiarch I had some hope to have a multiarch-enabled dpkg in sid for Christmas as Guillem told me that it was realistic. Alas Guillem got sick. We re in January and we re still not there. While some of Guillem s commits in December were related to multi-arch, the size of his pu/multiarch/master branch did not really shrink. We still have 36 commits to merge most of the work he did was refactoring some parts of the code that were already merged. And he initiated some discussion on interface changes. I participated to those discussions hoping to bring them to a quick resolution. I m still maintaining my own pu/multiarch/full branch, it is based on Guillem s branch but with further fixes that I developed and that he has not yet merged and with a change reverted (Guillem s branch allows crossgrading packages between different architectures while dpkg does not manage this correctly yet). I can only hope that January will be the last month of this never-ending saga. It s been one year since I started working on this project. Misc dpkg work I reviewed (and later merged) a patch of Kees Cook to enhance dpkg-buildflags so that it can report which hardening features are enabled. This feature might then be used by tools like lintian to detect missing hardening features. I mentored Gianluca Ciccarelli who is trying to enhance dpkg-maintscript-helper to take care of replacing a directory by a symlink and vice-versa. I took care of #651993 so that dpkg-mergechangelogs doesn t fail when it encounters an invalid version in the changelog, and of #652414 so that dpkg-source --commit accepts a relative filename when a patch file is explicitly given. Guillem also merged a fix I developed for LP#369898. Packaging work WordPress 3.3 came out so I immediately packaged it. Despite my upstream bug report, they did not update their GPL compliance page which offers the corresponding sources for what s bundled in the tarball. So I hunted for the required sources myself, and bundled them in the debian.tar.xz of the Debian source package. It s a rather crude solution but this allowed me to close the release critical bug #646729 and to reintroduce the Flash files that were dropped in the past which is great since the Flash-based file uploader is nicer than the one using the browser s file field. Quilt 0.50 came out after 2 years of (slow) development. The Debian package has many patches and several of them had to be updated to cope with the new upstream release. Fortunately some of them were also merged upstream. It still took an entire morning to complete this update. I also converted the packaging from CDBS to dh with a short rules file. Zim 0.54 came out and I immediately updated the package since it fixed a bug that was annoying me. Review of the ledgersmb packaging As the sql-ledger maintainer (and a user of this software for my accounting), I have been hoping to get ledgersmb packaged as a possible replacement for it. I have been following the various efforts initiated over time but none of them resulted in a real package in Debian. This is a real pity so I tried to fix this by offering to sponsor package uploads. That s why I did a first review of the packaging. It took several hours because you have to explain everything that s not good enough. I also filed a wishlist bug against lintian (#652963) to suggest that lintian should detect improper usage of dpkg-statoverride (this is a mistake that was present in the package that I reviewed). nautilus-dropbox work I wanted to polish the package in time for the Ubuntu LTS release and since Debian Import Freeze is in January, I implemented some of the important fixes that I wanted. The Debian package diverges from upstream in that the non-free binaries are installed in /var/lib/dropbox/ instead of $HOME.
Due to a bug, the files were not properly root-owned so I first fixed this (unpacking the tarball as root lead to reuse of the embedded user & group information, and those information changed recently on the Dropbox side apparently). Then we recently identified other problems related to proxy handling (see #651065). I fixed this too because it s relatively frequent that the initial download triggered during the package configuration fails and in that case it s the user that will re-trigger a package download after having given the appropriate credentials through PackageKit. Without my fix, usage of pkexec would imply the loss of the http_proxy environment variable and thus it would not be possible for a user to download through a proxy. Last but not least I reorganized the Debian specific patches to better separate what can and should be merged upstream, from the changes that upstream doesn t want. Unfortunately Dropbox insists on being able to auto-update their non-free binaries, they are, thus, against the installation under /var/lib/dropbox and the corresponding changes. Book update We re making decent progress in the translation of the Debian Administrator s Handbook, about 6 chapters are already translated (not yet reviewed though). The liberation campaign is also (slowly) going forward. We re at 67% now (thanks to 90 new supporters!) while we were only at 60% at the start of December. Thanks See you next month for a new summary of my activities.

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

I ve recently been reading the Sociological Images blog [1]. That site has lots of pictures and videos that are relevant to the study of Sociology (most of which have a major WTF factor) and it s run by people who have Ph.Ds in Sociology so the commentary is insightful. Since reading that I ve started photographing relevant things. I can t work out the logic behind the above advert for Energy Watch which was on a billboard near Ringwood Station in Melbourne, Australia. The only thing that it clear is that it spreads bad ideas about mental illness and psychiatric treatment. It doesn t make me want to do business with them. The above picture is a shop-front for the Antons clothing store (I m not sure if they are a tailor or if they sell ready to wear). It was taken on Lonsdale St, Melbourne where the store apparently used to be, now they are in Melbourne Central. The above pictures show more detail. Unfortunately the combination of lighting and my camera (Xperia X10 phone camera) wasn t adequate to show the apparent ethnic differences between the two men. It seems that the most likely Australian interpretation of the ethnic groups that are represented are African (maybe Afro-American), Southern-European or maybe American Hispanic, North-Western European, and Japanese. It s good to have mannequins representing the fact that not everyone in Australia is white, but different facial expressions for different races seems a strange choice (admittedly it might be a choice made by mannequin manufacturers). Also the Japanese woman with fan idea is rather outdated. I ve just started reading You May Ask Yourself: An Introduction to Thinking Like a Sociologist (Second Edition) by Dalton Conley. I ve only read the first chapter, but that was good enough that the entire book has to be good enough to recommend.

• [1] http://thesocietypages.org/socimages