After several months of effort by the i18n team (and quite a bit from /me), some NMUs, a lot of help by the release team to accept many unblocks, we finally reached 100% translation for debconf screens, in wheezy, for three languages. And, no, French is not among them (yet). The first to reach this heaven are Russian, German and Swedish with translations for all translatable debconf screens for packages in Debian testing (which will become the next Debian release). Three more languages (French, Czech and Portuguese) are waiting for one package to reach testing and another (Spanish) is waiting for three packages. We should then soon reach 7 complete languages. David Pr vot is even trying to get Danish as complete as possible, but it requires pushing for about 15 packages, with many NMUs and unblocks to ask. I started this work in early April, so it took about SIX months to reach this and be ableto happily make a lot of noise about such achievement. You have no idea how it is appreciated by translators....so you maybe have a better idea why I can be so noisy when some uncoordinated upload (for instance with modified localized material) breaks this... We'll have much more news about achievements in l10n for wheezy in the upcoming weeks. We had a lot of things that deserve some trumpets, bells or whistles..:-)

PostgreSQL 9.2 has just been released, after a series of betas and a release candidate. See for yourself what s new, and try it out! Packages are available in Debian experimental as well as my PostgreSQL backports PPA for Ubuntu 10.04 to 12.10, as usual. Please note that 9.2 will not land any more in the feature frozen Debian Wheezy and Ubuntu Quantal (12.10) releases, as none of the server-side extensions are packaged for 9.2 yet.

I think perhaps Alonzo Horton overstated the case but San Diego was a perfectly pleasant place to spend a week. Recently I was fortunate and attended the Linux Plumbers conference (and bits of Kernel Summit) and as on previous occasions there were some interesting sessions and some less helpful diversions.

Melodie went along with me, our first trip away together without the kids in a long time. We did the tourist thing for a few days including the USS Midway aircraft carrier tour (recommended) and the harbour boat tour (also recommended).

The conference was co-located with several other events and there seemed to be a lot of people around not connected with KS or LPC. For me the hallway track was, as usual, much more rewarding and I got to catch up with several old friends and make some new acquaintances. A lot of my colleagues were about attending the Gstreamer and Linuxcon conferences so there was the obligatory work evening event (which was pizza and beer, just done brilliantly).

A track that did stand out for me was the Clang / LLVM presentations. They gave an excellent overview of their progress towards making the Kernel compile with their tools, such innovation appears to be making both projects stronger.

One thing that occurred to me was the blandness of KS and LPC this time, usually there are at least some loud disagreements but I failed to attend even one session where there was more than small differences which were quickly resolved.

Perhaps such conferences, like the majority of people attending them, are becoming middle aged and a little complacent. An observation like that does make me wonder where the next change will come from and what it will look like. Just as open source software (including Linux) has disrupted the proprietary software industry in the last decade what will come along and disrupt us? Or is open source the end of the line and we will just continue to evolve?

I just posted the following question to ServerFault .and then realised there might be people out there in magical internetland who know the answer but never visit any of the SO sites, so i ve posted it here too. Feel free to respond here on on serverfault.

---

In a recent upgrade (from Openstack Diablo on Ubuntu Lucid to Openstack Essex on Ubuntu Precise), we found that DNS packets were frequently (almost always) dropped on the bridge interface (br100). For our compute-node hosts, that s a Mellanox MT26428 using the mlx4_en driver module. 1. Use an old lucid kernel (e.g. 2.6.32-41-generic). This causes other problems, in particular the lack of cgroups and the old version of the kvm and kvm_amd modules (we suspect the kvm module version is the source of a bug we re seeing where occasionally a VM will use 100% CPU). We ve been running with this for the last few months, but can t stay here forever.

net.bridge.bridge-nf-call-arptables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-ip6tables = 0

---

Update 2012-09-12: Something I should have mentioned earlier this happens even on machines that don t have any openstack or even libvirt packages installed. Same hardware, same everything, but with not much more than the Ubuntu 12.04 base system installed. On kernel 2.6.32-41-generic, the bridge works as expected. On kernel 3.2.0-29-generic, using the ethernet interface, it works perfectly.
Using a bridge on that same NIC fails unless net.bridge.bridge-nf-call-iptables=0 So, it seems pretty clear that the problem is either in the mellanox driver, the updated kernel s bridging code, netfilter code. or some interaction between them. Interestingly, I have other machines (without a mellanox card) with a bridge interface that don t exhibit this problem. with NICs ranging from cheap r8169 cards to better quality broadcom tg3 Gbit cards in some Sun Fire X2200 M2 servers and intel gb cards in supermicro motherboards. Like our openstack compute nodes, they all use the bridge interfaces as their primary (or sometimes only) interface with an IP address they re configured that way so we can run VMs using libvirt & kvm with real IP addresses rather than NAT. So, that indicates that the problem is specific to the mellanox driver, although the blog post I mentioned above had a similar problem with some broadcom NICs that used the bnx2 driver. openstack, bridging, netfilter and dnat is a post from: Errata

As I was upgrading harddisks I thought about giving windows 8 a spin. and got what I deserved. ;-) I had expected Grub to be wiped, however I was a little bit surprised that the existing Windows (Vista) installation (which was automatically integrated in Windows 8 bootloader) did not boot anymore. Vista's automatic system repair failed, manual intervention on the system console (bootrec) seems to have shredded the system (The partition table is messed up.) No data was lost, as I have simply switched back to the old hd again. I will need to re-do the harddisk upgrade, though.

Debian GNU/Linux Debian 7.0 (aka Wheezy) will be a general hardened distribution in my eyes. Not only that it now enabled hardened building of packages (see http://wiki.debian.org/Hardening), the Kernel team also backported with 3.2.20-1 the IMO very interesting hidepid option (already available in Wheezy since some weeks)! What is the job of hidepid ? hidepid is an new mount option for the procfs (/proc), with that you can hide processes and its information to other users, like other shell users and to web scripts. hidepid accepts three different values:

• hidepid=0 (default): This is the default setting and gives you the default behaviour.
• hidepid=1: With this option an normal user would not see other processes but their own about ps, top etc, but he is still able to see process IDs in /proc
• hidepid=2: Users are only able too see their own processes (like with hidepid=1), but also the other process IDs are hidden for them in /proc!

Additionaly you can specifiy an user/group ID which is still able to look up the processes with the gid option. So if you want to hide all processes to other users, except root (uid=0) and in this example gid=1001 (some semi administrative user in this example) your /etc/fstab has to look like this: proc /proc proc defaults,hidepid=2,gid=1001 0 0 It was a good descision to backport this feature IMO, but also be careful, it *may* break programs. I did not found any server related application which will break with hidepid=2, but we had to adjust our Nagios monitoring to execute some process checks with another UID, since the nagios user itself could not see anymore, if process A and B is still running. UPDATE 1:
Since a few people asked (thanks for it) with hidepid=2 the process IDs are not invisible, they are unavailable:
$ ls /proc/1
ls: cannot access /proc/1: No such file or directory
$

Continuing the ZFS evaluation journey (which I will summarize here with the things that I learned), I was able to fit about 2.5TB of data on a single 2TB drive, with deduplication enabled. Unfortunately, even moving files around in ZFS (which you would think would be a cheap operation) takes ages. Removing files also takes ages. In a completely unloaded Phenom II X4 910 system running Linux 3.5.2 (actually, from Debian's experimental), and zfsonlinux version 0.6.0.71-0ubuntu1~precise1 (recompiled from source to work with my Debian system), I tried to remove a subdirectory that had about 4000 files. According to time, it took:

real    42m51.487s
user    0m0.188s
sys     0m16.769s

Which is a bit too slow. I just (read: "yesterday") upgraded this machine from 4GB to 6GB of RAM (well, I would have updated it to 8GB of RAM as that is what I ordered, but it one of the RAM chips arrived dead here and I simply took one of the new 4GB card and one of the older 2GB card). But, honestly, I don't see change in upgrading the RAM from 4GB to 6GB and, unless something magic happens with 2GB more, I wouldn't expect a whole different story with 8GB of RAM. Oh, no swap is being used (well, it is an unloaded machine after all), and the Linux kernel swappiness knob is at its default of 60. What I do see, though, is that even for a single file removal, the disk is thrashing a lot. I mean like crazy and that is, of course, the prime suspect of the bad performance (of course, of course). So, there must be some really crazy metadata churning going on here and I guess that the people from the LLNL would like to know of their modules producing this behavior. Keep tuned for some future impressions.

Lessons learned from trying to do some simple non-linear video editing on Linux: Kdenlive has reached a point where it's usable. Not good by any means there are glaring problems such as the color management support being very rudimentary, almost no multicore support, general lack of optimization, frequent near-crashes, and so on but usable to the point where you can actually create a video from start to end. I'd say it's very roughly comparable to Premiere 5 was, circa 1998, but it's not something I'd recommend to my mother. slowmoVideo, on the other hand, was not very useful to me for framerate up-conversions; the end results were simply too poor given the general complexity in my scenes. It can seemingly do an okay (but not perfect) job for down-conversion if you're willing to hack it a bit and live with general slowness and demand for disk space. So, well, behold the end result, I guess. If you like frisbee, that is.

A couple of months ago I was experimenting with adding no-new-privileges to various systems I run. Unfortunately I was surprised a few weeks later at unintended breakge. My personal server has several "real users", and several "webserver users". Each webserver user runs a single copy of thttpd under its own UID, listening on 127.0.0.1:xxxx, where xxxx is the userid:

steve@steve:~$ id -u s-steve
1019
steve@steve:~$ sudo lsof -i :1019
COMMAND  PID    USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
thttpd  9993 s-steve    0u  IPv4 7183548      0t0  TCP localhost:1019 (LISTEN)

Facing the world I have an IPv4 & IPv6 proxy server that routes incoming connections to these local thttpd instances. Wouldn't it be wonderful to restrict these instances, and prevent them from acquiring new privileges? Yes, I thought. Unfortunately I stumbled across a down-side: Some of the servers send email, and they do that by shelling out to /usr/sbin/sendmail which is setuid (and thus fails). D'oh! The end result was choosing between:

• Leaving "no-new-privileges" in place, and rewriting all my mail-sending CGI scripts.
• Removing the protection such that setuid files can be executed.

I went with the latter for now, but will probably revisit this in the future. In more interesting news recently I tried to recreate the feel of a painting, as an image which was successful. I think. I've been doing a lot more shooting recently, even outdoors, which has been fun. ObQuote: "You know, all the cheerleaders in the world wouldn't help our football team." - Bring it On

This is my monthly summary of my Debian related activities. If you re among the people who made a donation to support my work (88.41 , thanks everybody!), then you can learn how I spent your money. Otherwise it s just an interesting status update on my various projects. This month has again been a short one since I have mostly been in vacation during the last 2 weeks. Dpkg Things are relatively quiet during the freeze. I only took care of fixing 3 bugs: a regression of 3.0 (quilt) (#683547), a segfault of dpkg-query -W -f (commit) and a bad auto-completion for French users (#685863). Testing the upgrade to wheezy We got several reports of wheezy upgrade that failed because dpkg ran the trigger while the dependencies of the package with pending triggers are not satisfied. Unfortunately fixing this in dpkg is not without problems (see #671711 for details) so Guillem decided to defer this fix for Jessie. My suggestion of an intermediary solution has fallen in limbo. Instead we now have to find solutions for each case where this can fail (example of failure: 680626). Another way to avoid those errors is to ensure that triggers are run as late as possible. We can improve this in multiple ways. The first way is to modify most triggers so that they use the interest-noawait directive. In that case, the packages activating the trigger will be immediately marked as configured (instead of triggers-awaited ) and the trigger will thus not need to be run as part of further dependency solving logic. But as of today, there s no package using this new feature yet despite a nudge on debian-devel-announce. The second way is to modify APT to use dpkg no-triggers, and to let the trigger processing for the end (with a last dpkg configure -a call). I requested this early in the wheezy timeframe but for various reasons, the APT maintainers did not act on it. I pinged them again in #626599 but it s now too late for wheezy. I find this a bit sad because I have been using those options for the entire wheezy cycle and it worked fine for me (and I used them for a dist-upgrade on my wife s laptop too). It would have been good to have all this in place for wheezy so that we don t have to suffer from the same problems during the jessie upgrade, but unless someone steps up to steer those changes, it seems unlikely to happen. Instead, we re back to finding klumsy work-arounds in individual packages. Packaging I prepared security updates for python-django (1.4.1 for unstable,
1.2.3-3+squeeze3 for stable). I packaged a new upstream version for cpputest (3.2-1). I reviewed ledgersmb 1.3.21-1 prepared by Robert James Clay and asked him to prepare another version with further fixes. I released nautilus-dropbox 1.4.0-2 with supplementary changes of my own to support https_proxy and to display better diagnostic information when the download fails. With the help of Paul van der Vlis and Michael Ziegler, we did what was required to be able to migrate python-django-registration 0.8 to Wheezy even though it s a new upstream version with backwards incompatible changes. Thanks to Adam D. Barratt who unblocked the package, we now have the right version in Wheezy despite the fact that I missed the freeze deadline. Debian France Julien Cristau reminded the board of Debian France that we have to elect officers (President, Secretary, Treasurer) as the current officers have withdrawn. I was somewhat afraid that nobody would take over so I pinged each member to try to get new volunteers. We now have volunteers (me, Julien Danjou and Sylvestre Ledru) and we re waiting until Julien finds some time to run the election. Misc With the help of DSA, I setup antispam rules for the owner@packages.qa.debian.org alias because I was getting tired by the amount of spam. In the process, they asked me to write a wiki page for dsa.debian.org to document everything so that they can refer to it for future queries. I did it but it looks like that they did not apply my patch yet. I also tested an upstream patch for gnome-keyring (see bugzilla #681081) that reintroduces the support of forgetting GPG passphrases after a specified amount of time. Thanks See you next month for a new summary of my activities.

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

La Quadrature du Net is a European advocacy group that has been created to defend our rights and freedoms on the Internet against the continuous political threats driven by major corporations, such as the recent ACTA. After the recent citizen victories against these monsters, it is time to take the initiative and advocate for a reform of the copyright system which has become inappropriate with the omnipresence of copy-based systems. To this end, la Quadrature will give each Member of the European Parliament a customized USB drive, preloaded with a set of elements for a copyright reform, and with an anthology of free cultural works. To fund that campaign, la Quadrature is asking for everyone's help, by the means of an Ulule campaign (Ulule is a crowd-funding platform similar to Kickstarter). This initiative is noteworthy by at least two aspects:

• after years of being in a defensive position, I think this is the first offensive initiative from the citizen group in the copyright wars;
• the crowd funding will strongly indicate that it is supported by citizens.

If, like me, you are tired of the continuous attacks from the major corporations of mass entertainment, in addition to not helping them by buying their crap, you can now participate in this first counter-attack. This will probably not end the war, so I hope there will be more offensive actions from the citizen group!

There's been good progress in Fedora's implementation of UEFI Secure Boot, so time for a quick update.
Boot process signingThe infrastructure for signing the bootloader binaries is now implemented. pesign is in the archive and being used to sign shim, grub2 and the kernel. At the moment they're all being signed by test keys, and the private key is actually in the pesign package. This is, obviously, not intended for production use - it's just to ensure that we can build correctly signed images. We've proof-of-concepted signing via cryptographic hardware and will shortly be deploying new build systems dedicated to building the signed binaries. These won't be general access systems and will have a lightly modified mock configuration to ensure that the crypto hardware is available to the build chroots, but otherwise there's nothing special about them.

As far as signing with the Microsoft keys goes, we're in the final round of legal review of the appropriate agreements and will be migrating to a version of shim signed with their key in the near future.
Kernel modificationsThere's two main sets of patches for the kernel. The first is to automatically enable the locking down of various bits of functionality when secure boot is enabled, in order to prevent users (including root) from being able to modify the kernel at runtime. They've just been posted upstream and haven't been dreadfully received, though we'll probably be changing the name of the capability. The main thing that users will notice is that any X drivers that still need direct hardware access (which, on secure boot systems, should be zero - we've implemented native kernel drivers for all the hardware we expect to see there) will fail to work, as will setpci. The plan is for kexec to require that kernel images be signed, but that's requiring rather more reworking of kexec than expected so for now kexec will just be disabled.

The other lump of kernel functionality is the support for module signatures. That had been somewhat blocked based on a lack of consensus between patch authors and upstream, but an agreement got hammered out at Kernel Summit last week and so we should see progress there shortly. Right now we're still looking at modules being signed with a throwaway key, but the plan is still for keys in db (and MOK, if using the Suse approach) to be imported into the kernel keyring and used. That's dependent upon that code being written in time, though. It's definitely still a goal for F18.
Key managementWe're planning on using Suse's approach of permitting local key management at the shim level, and I spent some time discussing this with Vojtech last week. In combination with the above, this should provide a workable mechanism for permitting the end-user to install module signing keys.
General UEFI support improvementsWe've added support to grub to use the kernel's built-in UEFI setup functionality, although there's still some discussion with upstream to ensure that it's implemented in an acceptable way. This approach also makes it easy for us to obtain PCI ROMs via UEFI, which improves radeon support on a bunch of Macs. Finally, we've been hammering on some remaining UEFI bugs and are definitely at the point where the machines that don't work are surprising and the ones that do are the tedious expectation. This is far better than any previous release.
DocumentationStill has to be written, and that's probably where much of the my next month is going.
SummaryFedora 18 is still on track to have full UEFI Secure Boot support out of the box, and the Beta should be fully signed although perhaps still with our test keys.

For those of you who get sent to surprisingly expensive conferences, I'll be discussing some of this as part of a presentation on improving Linux support for UEFI at the Intel Developer Forum in San Francisco next Tuesday morning. Feel free to say hi if you're in the area.

comments

I've been slowly noticing, over a number of years now, a place where I don't react to other people the way that I want to. I've been stumbling over defensive reactions that I didn't realize I had. These are a few rules of thumb that I'm formulating for myself to try to improve that, and I thought it might help to write them down. And maybe they'll be meaningful for someone else.

1. Things people are excited about are probably exciting. If I don't find them exciting, that's probably because I don't know enough about them to understand why they're exciting. Or perhaps I have a different mindset, and therefore the exciting parts don't connect with me. Both of those are okay! There are way more things to learn about than I will ever possibly have time to learn, and I don't have to get excited about everything other people are excited about. But, equally, just because I'm not excited doesn't mean that the thing is not exciting.
2. My misplaced sense of obligation should not be someone else's buzzkill. This requires a bit of unpacking, since I only intermittantly realize that I'm doing this. But (partly for cultural reasons, partly due to natural inclinations) I've always felt a strong sense of obligation to "keep up" with things. To know a lot about a lot of topics. And one of the things I've realized is that my brain occasionally twists an interest in knowing lots about the world into a sense of obligation to "stay current" and know something about everything important, at least within my vague field of expertise. And usually that part of my brain has a very expansive notion of field of expertise; all of software development, for example, which is, when I pull it out into the light, ridiculously broad. This then sparks one of the standard failure modes of human cognition. I have an unrealistic expectation of myself. I fail to meet that expectation. This makes me feel guilty and stressed. At that point, my brain starts trying to find targets for me to displace negative feelings onto, and that generally ends up being the next person who is excited about something new that I don't know anything about but feel like I should. This is all very interesting psychologically, in the abstract. However, the concrete result is that I sometimes get all snarky and negative about something that someone else is excited about because it happens to be the moment I hit overload, or because I didn't want to hear about another thing that I feel like I should know more about. And that, in turn, can be either confrontational or discouraging to someone who is legitimately excited (and may rarely get the chance to be excited). And that's not the person I want to be.
3. It's okay not to have an opinion. Seriously, it's okay. The world is full of stuff, far more stuff than any one person can know anything about. It's okay not to go read about everything people say is exciting. It's okay not to know about something new. It's okay to focus on the things I'm already doing. Really. What's not okay is to make up an opinion about something I know nothing about just so that I can feel better about myself by having an opinion. Particularly since that opinion formed under those circumstances tends to be negative, despite the fact that I have no actual basis for having any opinion at all. I need to practice just quietly not having an opinion. No one else needs to know about my lack of opinion.
4. Before bristling at imposition, be sure someone is actually imposing. I frequently leap to the conclusion that, when someone raises a topic, they want me to do something about it. It's a gut emotional reaction, I think in part because the emotional part of my brain likes to make everything about me. Intellectually, if I can engage that part of my brain, it's often obvious that it's not about me, or that they're not asking me to do anything. Often, when someone brings something up, they just want to tell someone else about it, or make me aware of it. If I've listened to, or read, all the sentences and understood then, then congratulations! I've done everything that I needed to do and was expected to do and need not feel any further obligation. Even if something further needs to be done, it doesn't necessarily need to be done by me. I'm very protective of my time and available resources because I almost always feel overwhelmed by all the things that I want to work on. This does not entitle me to snap at random people who are being excited around me on the grounds that they're trying to put more obligations on me. They're probably not. If it becomes clear that they really want me to do something I don't have time to do, I can politely decline, but if I just shut up and listen for longer, usually that's not the case at all.

(Please note that this is not prompted by any current discussion happening anywhere, and paticularly not by anything in Debian. Insofar as it was prompted by anything, it was by a throwaway comment in an unrelated private discussion. It's just something that gelled enough to write down while I was walking home from work.)

Panama just underwent a nasty e-voting exercise: Electronic-mediated elections were held for the committee of the PRD party. It sounds simple - Even trivial! There were only 4100 authorized voters, it was geographically trivial (all set inside a stadium)... But it blew up in smoke. I won't reiterate all what happened, I'll rather direct you to our project's (the e-voting observatorium) page: News regarding Panama (for those coming from the future, search starting at 2012-08-27 and yes, it's all in Spanish, but there are free-as-in-beer translation services. Many e-vote proponents/sellers/pushers were very eagerly waiting for this election to brag about one more success... So much that they could not just ignore it, and started rationalizing it away. Anyway, while feeding the observatorium, I came across this opinion-article in the Voto Digital website, which makes quite a bit of pro-e-voting noise. I replied to it, and I think my analysis is worth sharing also with you:

So, lets make some simple numbers, rounding the numbers: The PRD vote in Panama was done for a universe of 4100 voters. It took 10 hours (instead of the planned 4), so 410 people were processed every hour. There were 40 voting (electronic) booths, so each processed 10 people per hour. This means, each person spent 6 minutes by the booth. A manual vote in this fashion is highly parallelizable: Each of the voters can be given ballots with anticipation, or many of them cna be allowed in to be given the ballots in situ (depending on the electoral scheme employed). The contention time is the time it takes to each voter to get near the booth and deposit his ballot (either folded or in an envelope) - And it will very rarely be more than a couple of seconds. So, given that using electronic booths parallelism cannot grow (there is a fixed number of machines) and the queues grew wildly, with traditional voting it would have surely fitted in the expected four hours (they were expected, also, based on their past experiences). As for counting, that's the slowest part of manual voting, it's also highly parallelizable: If each of the 40 booths has slightly over 100 ballots, the party personnel can easily count them in under 30 minutes. Capture and aggregation for the 40 partial results would take an extra 10 minutes, even being generous. Manual voting would have saved them around five hours, without demanding additional resources (and being thus much more economical than having to buy 40 specific-purpose computers). And as an additional advantage, the physical and tangible vote proofs would remain, in case they were ever again needed.

I've never really used facebook so it's not too hard for me to delete my account there. The only thing that's a pity is that I found (or others found me) many people that I once met and which I'd love to meet again once. So I'll go through my facebook contacts list and will try to copy all contact data especially the email adresses and plan to write emails to everybody every quarter or half a year about happenings in our lifes. I'd be glad to receive such emails from others too! They'll surely be read more carefully then my facebook timeline!

This gets me to another point: I still don't have a satisfying free (as in freedom) solution to manage my contacts across devices and available on my web server. The same for image galleries. So I can understand how convenient facebook for many people is. Still facebook is evil and it's an important and ongoing project to provide a better alternative.

It'll be harder for me to leave Twitter. This one comes next. If people would just switch to the free and privacy aware alternative identi.ca...

And then I've to finally provide a better alternative for my family to share baby pictures then Google Plus... Leaving Xing and Linkedin also doesn't worry me, I just have to collect the addresses of my important contacts there. Not so pressing is to leave Couchsurfing for bewelcome.org.

So if you want to hear news from me just pass by www.koch.ro from time to time or put my blogs feed into your feed reader. I'll also keep my identi.ca account.

update: One tiny example of facebooks evilness is, that they don't show me your real email address (anymore). They only show me an @facebook address. So if I don't know your real email address from any other source, I would not be able to send you messages without sending it over facebooks servers. I read that you can change the email address shown back to your real email address somewhere in the options.

CURP: Clave nica del Registro Poblacional, or Unique Population Registry Code. This is a (hopefully) unique, 18 character long, string identifying each Mexican - I won't get into the technicalities, but serve yourselves. By following such a convoluted scheme, the authorities should have ensured a biunivocal relation between each person and their CURP number. Well, at some point, due to a bureaucratical mishap completely outside my hands (my patron registered me with the wrong birth date, as you can see in the page at the bottom), I got two CURPs - And the procedure to fix it was far from trivial. Last Sunday, I entered the Consulta CURP system to print a copy of the official document. Much to my surprise... It answered that I was not registered! A couple of minutes later, I tried again, and succeeded. But I could not refrain from printing my Certificate of non-registration. I guess their system follows a strong-but-stupid scheme such as:
So, right, if a user submits a query during the system maintenance window (after all, it was Sunday after 23:00), the system will fail to connect to the database (or whatever), raise an exception, trap it, and... Well, you no longer exist, thanks for playing!

We recently switched from Buildbot to Jenkins at work, for building Varnish on various platforms. Buildbot worked-ish, but was a bit fiddly to get going on some platforms such as Mac OS and Solaris. Where buildbot has a daemon on each node that is responsible for contacting the central host, Jenkins uses SSH as the transport and centrally manages retries if a host goes down or is rebooted. All in all, we are pretty happy with Jenkins, except for one thing: The job configurations are a bunch of XML files and the way you are supposed to configure this is through a web interface. That doesn't scale particularly well when you want to build many very similar jobs. We want to build multiple branches, some which are not public and we want to build on many slaves. The latter we could partially solve with matrix builds, except that will fail the entire build if a single slave fails with an error that works on retry. As the number of slaves increases, such failures become more common. To solve this, I hacked together a crude tool that takes a yaml file and writes the XML files. It's not anywhere near as well structured and pretty as liw's jenkinstool, but it is quite good at translating the YAML into a bunch of XML files. I don't know if it's useful for anybody else, there is no documentation and so on, but if you want to take a look, it's on github. Feedback is most welcome, as usual. Patches even more so.

On year ago, we (the mancoosi team) published a comparison study regarding the state of the art of dependency solving in debian. As few noticed, the data presented had few glitches that I promised to fix. So we've repeated our tests using exactly the same data we used one year ago, but now using the latest available versions of all package managers as available in debian unstable. During the last year, three out of four solver that we evaluated release a major upgrade so I expected many improvements in performances and accuracy.

• apt-get 0.8.10 -> 0.9.7
• aptitude 0.6.3 -> 0.6.7
• smart 1.3-1 -> 1.4
• cupt 1.5.14.1 -> 2.5.6

Mpm, our test-bench for new technologies, changed quite a bit under the wood as a consequence of the evolution of apt-cudf and the recent work done in apt-get to integrate external cudf dependency solvers. Overall the results of our study are not changed. All solvers but mpm, that is based on aspcud, are not scalable as the number of packages (and alternatives) grows. It seems that Smart is the solver that does not give up, incurring in a timeout (fixed at 60 seconds) most of the time. Aptitude is the solver that tried to give you a solution, doesn't matter what and as result providing solutions that do not satisfy the user request for one reason or the other. Apt-get does surprisingly well, but it gives up pretty often showing the incomplete nature of it's internal solver. Cupt sometimes timeout, sometimes gives up, but when it is able to provide an answer it is usually optimal and it is very fast ... Mpm consistently finds an optimal solution, but sometimes it takes really a long time to do it. Since mpm is written in python and not optimized for speed this is not a big problem for us. The technology used by mpm is now integrated in apt-get and I hope this will alleviate this problem. All the details of our study can be found one the Mancoosi Website as usual with a lot of details. For example here you can find the results when mixing four major releases : sarge-etch-lenny-squeeze. Comments are more then welcome.

I have been having quite costly experiments with (embeded) hardware in the last few weeks/months. To cover at least part of the expenses, I am trying out to use Google's AdSense with my blog. I plan on blogging more frequently with the results of the experiments, but it will take me a few days, as I want to offer people only the "meat" of what I actually did, pointing out some pitfalls that made me waste a lot of time. Anyway, back to AdSense, one interesting thing about trying it is that I applied to be part of the program for 3 or 4 times late in August and, due to unspecified reasons, my application was rejected for "not complying with their policies". I read the policies from left to side, from up and down and nowhere I saw anything that my blog infringed. This morning, I tried once again and I'm now in a sort of "probation period" for AdSense, which is progress I think. So far, I only put one advertisement at the top of my pages, but I am curious to know how "targeted" those ads would be to a blog that has articles that were written more than a decade ago, with posts in at least two languages. I guess that this is a weaker version of what Rapha l Hertzog is trying to do with his funding campaigns, except that I only expect to cover the costs of my hardware (even if I am skeptical that I will actually manage to reach that point of self-sufficiency).