LDAP's "Country" entry reads "France" The correlation among quiet times for a blog and quiet times in its owner's life is often negative. My past two months are no exception. Beside my regular Debian activities, I've used a good chunk of my day time to (try) settle down and stop wandering around Europe, one temporary academic position after another. In the end, it has turned out very well. Starting September 1st, I'll be joinining the PPS laboratory as a Ma tre de Conf rences, a tenured academic position roughly equivalent to US' Associate Professor (at least according to Wikipedia; see the high quality references that tenured people resort to use?). More specifically, I'll continue to work in the context of IRILL (Research and Innovation on Free Software), an exciting new entity that I've helped bootstraping over the past couple of years. Thanks to IRILL and to his director Roberto Di Cosmo, I've been able not only to pursue quite some research on FOSS distros, but I've also been supported (rather than discriminated) in my Debian activities, including acting as DPL around the world. Last but not least, within IRILL I have also been able to offer support to several Free Software communities such as: Debian itself (hosting Sprints and sponsoring DebConf hardware), GNU, OSI, OCaml, Darcs, and many others. I realize how lucky I've been ending up in a place like IRILL and I'm glad to know I'll be around here for quite some time. The main change I'll expect to happen from September on is that I'll get back to do some teaching, trading-off time from research activities. I've been teaching only on and off since I've moved to France in 2008 and I miss that quite a bit. It looks like that next year I'll be teaching various classes on FOSS-related (or at the very least UNIX-y) topics. Time looks scarce, but who knows, maybe I'll also find a way to mix-in the nice packaging tutorial that Lucas has recently put together. Wish me luck!

I've pasted here something from an IRC channel which revealed a person's name in a given situation. The "fun part" that I tried to show in the "things i love in debian" post was mainly related to the way we (debian people) use to deal with things in a non-personal way in order to be fair at the end (don't tell me about your life, just give me your username so i check the logs). It had not to do with the individuals involved. I apologize if it has caused any damage to one's life. Of course removing the post doesn't help too much, but at least may reduce a little the noise. Thanks to those who kindly pointed that out to me - btw, kindness is another valuable thing that i like to see in debian community.

Got my tickets, now looking for a place to sleep... My first debconf. It's going to be gooood :)

In a series of experiments performed over the past few days, I've determined that the actual mechanism by which "water saving" shower heads work is not, as you might naively imagine, reducing the amount of water dispersed per unit time. Instead, they make showering such an unpleasant experience that you perform amazing feats of speed washing so you can get out as quickly as possible. In extreme cases, I can imagine you would save even more water by just not washing at all.

Right around the time I immigrated to the US Alex Trebek began a revival of a TV game show originally hosted by Art Fleming called Jeopardy. In fact I believe I saw the first episode or one of the first ones anyway. And ever since I began watching, people have said to me I ought to be a contestant. I've tried to get on every now and again with little success until this year. In February I took the online entrance test not expecting any results as usual. Indeed nothing happened at first then suddenly, a few weeks ago, I was surprised to receive an email inviting me to an audition. So today (or yesterday depending on when you read this. June 27th.) I went to a conference room in the New York Sheraton Towers hotel to show off my telegenic looks, rapier wit and mastery of general knowledge to the Jeopardy producers. I had to bring in a list of five fun facts about myself for the between-round amusing banter. You'll have to wait until I actually appear on the show (if in fact I do. See below.) but let me assure you my banter is very amusing. My spirit flagged a bit when they took a photo of me for their files. I managed to do a convincing impression of Tow Mater from Cars 2 which is not quite the showbiz look I was going for. My morale rose again after the next portion of the audition in which you had to answer 50 trivia questions in about 8 minutes. They don't tell you your score but based on my conversations with fellow auditionees (there were about 20 of us) I think I only got 1 wrong. The next part of the audition was a mock game with a real board and buzzers etc. I was in the first group of three to play which further leads me to believe I got a good score in the questions. Unfortunately I had a bit of bad luck in the categories half of which were not in my strong subjects but I did ok. More importantly I demonstrated a good speaking voice (a lot of people mumble or speak too softly), good buzzer technique and as I may have previously mentioned, amusing banter. Does this mean I am actually going to be on TV? I don't know. Every year they select approximately 2,000 people for auditions and of those, around 400 are selected for the contestant pool. So I have a 1 in 5 chance of making it. The consensus in the group was I had done pretty well for a first timer (Some were making their second or third attempt.) so I am optimistic. All I know is that sometime in the next 18 months I might receive the call to fly to Los Angeles and fulfill my destiny. Btw, in case you were wondering about the title.

In a series of experiments performed over the past few days, I've determined that the actual mechanism by which "water saving" shower heads work is not, as you might naively imagine, reducing the amount of water dispersed per unit time. Instead, they make showering such an unpleasant experience that you perform amazing feats of speed washing so you can get out as quickly as possible. In extreme cases, I can imagine you would save even more water by just not washing at all.

Given that I was responsible for putting together the system architecture for Github when they moved away from their previous services provider to Anchor Systems, I keep an eye on what's going on there even though I've gotten out of professional IT. Recently(ish), Ryan Tomayko blogged about some experiments in using Amazon CloudFront as a CDN for static assets. While discussing as-yet unsolved performance issues, he quoted a tweet from Shopify's CEO (who I would have thought would have known better):

Protip to make SSL fast: terminate in your load balancer, that makes SSL session cookies actually work.

No, no, NO -- a million times NOOOOOO! Load balancers are, by their very nature, performance chokepoints. You can't horizontally scale your load balancer, because if you do (by, say, putting another load balancer in front of it -- don't laugh, I've seen it done) you've just re-introduced all the same problems that putting SSL on the load balancer was supposed to accomplish (that is, getting SSL session caching to work). The only thing you accomplish by putting your SSL sessions onto the load balancer is bring the moment your load balancer melts down through excessive CPU usage that much closer. I dunno, maybe Shopify doesn't actually do that much traffic or something, but I certainly wouldn't be signing up for that headache if it were my infrastructure. (Sidenote: yes, I know that you can get "SSL hardware accelerators", that put the basic crypto operations into dedicated silicon, but they're rarely cheap, and you can't horizontally scale those, either. They're effectively a specialised and outrageously expensive form of "scaling by bigger hardware" -- which is a valid method of scaling, but one with fairly terminal limitations that certainly wouldn't make it practical for Github). The problem you're trying to solve by centralising SSL operations is that SSL includes a mechanism whereby a client making a new TCP connection can say "here's the crypto details from last time I connected to you" and the server can just pull out all of the per-connection data that would otherwise take a long time (several TCP round trips and a smallish chunk of CPU time) to setup. This can make SSL connections a lot snappier (in Ryan's opinion, "We spend roughly as much time handshaking as we do generating the average dynamic request."), so they're a definite win if you can do it (and yes, you can do it). Webservers don't typically do this caching by default, but setting up a simple SSL session cache for a single nginx or Apache webserver is pretty trivial. Testing it is simple, too: just install gnutls-bin and run:

	gnutls-cli -V -r HOSTNAME  grep 'Session ID'

If all three Session IDs are the same, then you've got SSL session caching running. (If you're wondering why I'm using gnutls-cli rather than openssl s_client, it's because openssl is living in the pre-IPv6 dark ages, and I've got IPv6-only services running I wanted to test). So that's great for your little single-server hosting setup, but per-machine caches aren't much use when you're running behind a load balancer, Github style, because each SSL-enabled TCP connection can very well end up on a different server, and a per-machine cache won't help you very much. (If you think the answer to this problem is "session affinity", you're setting yourself up for a whole other world of pain and suffering.) Here's the kicker, though -- the SSL session is just a small, opaque chunk of bytes (OpenSSL appears to store it internally as an ASN.1 string, but that's an irrelevant implementation detail). An SSL session cache is just a mapping of the SSL session ID (a string) to the SSL session data (another string). We know how to do "shared key-value caches" -- we have the technology. There won't be too many large-scale sites out there that aren't using memcached (or something practically equivalent). So, rather than stuff around trying to run a load balancer with enough grunt to handle all your SSL communication for all time, you can continue to horizontally scale the whole site with as many backend webservers as you need. All that's needed is to teach your SSL-using server to talk to a shared key-value cache. Far be it for me to claim any sort of originality in this idea, though -- patches for Apache's mod_ssl to do this have been floating around for a while, and according to the release notes, the 2.4 series will have it all built-in. However, Github uses nginx, to great effect, and nobody's done the work to put this feature into nginx (that I could find, anyway). Until now. I present, for the edification of all, a series of patches to nginx 0.8.x to provide memcached-enabled SSL session caching. Porting them to other versions of nginx hopefully won't be too arduous, and if you ask nicely I might give it a shot. If you don't use memcached (gasp!), my work should at least be a template to allow you to hook into whatever system you prefer. Sharding the memcached calls wouldn't be hard either, but I'm not a huge fan of that when other options are available. I had originally hoped to be able to say "it works at Github!" as a testimonial, but for some reason it hasn't been deployed there yet (go forth and pester!), so instead I'm just releasing it out there for people to try out on a "well, I don't know that it doesn't work" basis. If it breaks anything, it's not my fault; feel free to supply patches if you want to fix anything I've missed.

As part of trying to help with Freedom Box, I gained access to a Dream Plug The Dream Plug is one of the leading possible platforms for Freedom Box. Computationally it s sexy for a low-power device. There s a 1200 mhz arm with 512m of RAM. As a platform to enable people to create novel applications, it s great. It has multiple USB ports, two ethernets, a built-in 802.11B/G access point, bluetooth, audio, ESATA, Micro SD and full-sized SD. So, whether you application needs storage, networking, audio, or some interesting side device, you re covered. With the optional JTAG adapter it s even fairly friendly to developers: there are options for recovering from most failures and full console access. If you re looking at a reference platform that s still nominally embedded, but that allows you to play around thinking about what your application could do, this is a great option. However, especially for Freedom Box, it s important to remember that the reference board a developer wants is not the same as a cost-reduced product on which to actually deploy something for people to buy. The Dream Plug is wrong for every actual deployment I ve imagined. First, it s huge. If you happen to have free power plugs on your wall with lots of space above and below them, it might be an option. If however, you re like everyone I know and have power strips, constrained spacing, etc, then the industrial engineering will disappoint at every turn. I was hoping for something that kind of looked like an Apple Airport Express. It s significantly larger than that in every dimension. Also, the plug is oriented the wrong way for minimizing the fraction of the power strip it takes up. The power supply part of the device can be detached, although even that is way too huge for a power strip, and the cable between the power supply and the computer is fairly short. You can reconfigure the device without its plug nature: running a cord from a normal power outlet to the power supply. But then if you have to detach the power supply for heat management reasons, you get a cord from the outlet to the power supply and another cord from the supply to the device. Add a few USB or ESATA devices and the octopus of cables begins to resemble some arcane mechanism. (So far, no elder gods have appeared though.) The other issue is that you almost never want all the functionality. You pay for the bluetooth, audio and ESATA in terms of cost, heat and space regardless of whether you use them. I don t have a lot of applications that really take advantage of the full array of hardware. The firmware update mechanism is decidedly not targeted at end-users. The version I obtained had a hacked copy of Debian lenny. No mechanism was provided for replacing the image in a safe manner that did not potentially require the optional highly-non-end-user-compatible JTAG board if something got interrupted. You could either unscrew the device and get to the micro SD card containing the image, or run software to replace the image from within Debian lenny. It s possible to configure the boot loader to run an update image off USB or SD until that succeeds, but doing that is also a non-end-user operation. In conclusion, the name is perfect. This is exactly what hackers need to dream about the power of small computers everywhere. However we must not forget that there s a step required to turn dreams into reality. Just as with any fully proprietary product, Freedom Box will require cost reduction steps, semi-custom boards and actual OEMs to truly be usable. The claim in the previous sentence that the Freedom Box may have proprietary elements is disquieting to some. I think we can put together a software stack that is free with the possible exception of some device firmware. However, my suspicion is that anyone who turns that into a fully realized end-user product will add proprietary elements. I suspect some of the results of the cost reduction process such as resulting semi-custom boards will be proprietary. In many cases though, I suspect some proprietary software elements will be introduced.

git doesn't have a feature as simple and useful as darcs setpref test. To emulate it, I have created a script in .git/hooks/pre-commit. For instance, if the use was darcs setpref test make, the git script goes as:

erase()  
    rm -rf /tmp/workdir$$ /tmp/patch$$
 
handle()  
    erase
    exit 1
 
git new-workdir  git rev-parse --show-toplevel  /tmp/workdir$$
git diff --cached > /tmp/patch$$
cd /tmp/workdir$$
patch -p1 < ../patch$$
make   handle
erase

By the way, I miss darcs revert, and specially darcs unrevert. It's possible to emulate darcs revert -a using git reset --hard, but this comes without darcs unrevert latter. Yes, there is git stash, but it's not the same thing. Also, I could not find a way to have something like darcs revert.

Given that I was responsible for putting together the system architecture for Github when they moved away from their previous services provider to Anchor Systems, I keep an eye on what's going on there even though I've gotten out of professional IT. Recently(ish), Ryan Tomayko blogged about some experiments in using Amazon CloudFront as a CDN for static assets. While discussing as-yet unsolved performance issues, he quoted a tweet from Shopify's CEO (who I would have thought would have known better):

Protip to make SSL fast: terminate in your load balancer, that makes SSL session cookies actually work.

No, no, NO -- a million times NOOOOOO! Load balancers are, by their very nature, performance chokepoints. You can't horizontally scale your load balancer, because if you do (by, say, putting another load balancer in front of it -- don't laugh, I've seen it done) you've just re-introduced all the same problems that putting SSL on the load balancer was supposed to accomplish (that is, getting SSL session caching to work). The only thing you accomplish by putting your SSL sessions onto the load balancer is bring the moment your load balancer melts down through excessive CPU usage that much closer. I dunno, maybe Shopify doesn't actually do that much traffic or something, but I certainly wouldn't be signing up for that headache if it were my infrastructure. (Sidenote: yes, I know that you can get "SSL hardware accelerators", that put the basic crypto operations into dedicated silicon, but they're rarely cheap, and you can't horizontally scale those, either. They're effectively a specialised and outrageously expensive form of "scaling by bigger hardware" -- which is a valid method of scaling, but one with fairly terminal limitations that certainly wouldn't make it practical for Github). The problem you're trying to solve by centralising SSL operations is that SSL includes a mechanism whereby a client making a new TCP connection can say "here's the crypto details from last time I connected to you" and the server can just pull out all of the per-connection data that would otherwise take a long time (several TCP round trips and a smallish chunk of CPU time) to setup. This can make SSL connections a lot snappier (in Ryan's opinion, "We spend roughly as much time handshaking as we do generating the average dynamic request."), so they're a definite win if you can do it (and yes, you can do it). Webservers don't typically do this caching by default, but setting up a simple SSL session cache for a single nginx or Apache webserver is pretty trivial. Testing it is simple, too: just install gnutls-bin and run:

	gnutls-cli -V -r HOSTNAME  grep 'Session ID'

If all three Session IDs are the same, then you've got SSL session caching running. (If you're wondering why I'm using gnutls-cli rather than openssl s_client, it's because openssl is living in the pre-IPv6 dark ages, and I've got IPv6-only services running I wanted to test). So that's great for your little single-server hosting setup, but per-machine caches aren't much use when you're running behind a load balancer, Github style, because each SSL-enabled TCP connection can very well end up on a different server, and a per-machine cache won't help you very much. (If you think the answer to this problem is "session affinity", you're setting yourself up for a whole other world of pain and suffering.) Here's the kicker, though -- the SSL session is just a small, opaque chunk of bytes (OpenSSL appears to store it internally as an ASN.1 string, but that's an irrelevant implementation detail). An SSL session cache is just a mapping of the SSL session ID (a string) to the SSL session data (another string). We know how to do "shared key-value caches" -- we have the technology. There won't be too many large-scale sites out there that aren't using memcached (or something practically equivalent). So, rather than stuff around trying to run a load balancer with enough grunt to handle all your SSL communication for all time, you can continue to horizontally scale the whole site with as many backend webservers as you need. All that's needed is to teach your SSL-using server to talk to a shared key-value cache. Far be it for me to claim any sort of originality in this idea, though -- patches for Apache's mod_ssl to do this have been floating around for a while, and according to the release notes, the 2.4 series will have it all built-in. However, Github uses nginx, to great effect, and nobody's done the work to put this feature into nginx (that I could find, anyway). Until now. I present, for the edification of all, a series of patches to nginx 0.8.x to provide memcached-enabled SSL session caching. Porting them to other versions of nginx hopefully won't be too arduous, and if you ask nicely I might give it a shot. If you don't use memcached (gasp!), my work should at least be a template to allow you to hook into whatever system you prefer. Sharding the memcached calls wouldn't be hard either, but I'm not a huge fan of that when other options are available. I had originally hoped to be able to say "it works at Github!" as a testimonial, but for some reason it hasn't been deployed there yet (go forth and pester!), so instead I'm just releasing it out there for people to try out on a "well, I don't know that it doesn't work" basis. If it breaks anything, it's not my fault; feel free to supply patches if you want to fix anything I've missed.

It has been over 5 years since we voted on the GNU FDL. At the time I was misled by certain people who insisted that they had inside knowledge and that the GFDL was going to be fixed within the year. The FDL is still a bad license, and the successor meant to be less bad, the GSFDL, has not progressed beyond a discussion draft from September 2006. Personally, I feel dirty having voted the way I did. We compromised our principles and ended up in a stalemate that many people on either side of the issue are still unhappy about to this day. Hopefully I have learned my lesson.

What is Unknown Horizons? Unknown Horizons is a Free Strategy game I have written about from time to time about and do from time to time contribute. I also build Packages for Debianoids. Unknown Horizons is not a new thing, it has been there for some years now. It currently gets boosted by 3 very active GSoC Students and evolving steadily. Preparing for 2011.2 Unknown Horizons is Preparing for another Release, 2011.2. As part of the effort I have updated the official Unknown Horizons Debian and Ubuntu weekly archives with new rc builds to get some more testing before the release happens. Please test! Why isn't it in Debian main yet? Unknown Horizons hasn't been uploaded to Debian yet. This is mostly due to 2 factors: The game engine Unknown Horizons build upon, FIFE isn't in Debian, evolving fast and not providing much of a stable interface and therefor Unknown Horizons has traditionally had a strict dependency to some VCS state of approximately the same age. Not good for a Debian package obviously. And second, Unknown Horizons got rid of some content that was not free (as in "main") just recently. Personally I'm hoping we can have some packages soon as the freeness stuff is sorted out now and I haven't seen any troubling breakages with regard to the engine recently.

In the aftermath of the World IPv6 Day YouTube seems to be serving its content over IPv6 now. Interestingly the frontpage is still served via IPv4 (if you're not in a Google IPv6 whitelisted network). But all the Flash and HTML5 video content is served through IPv6 if available, as the cache servers return proper AAAA DNS records. Apparently that's the case unless your network is blacklisted because of bad IPv6 support and even if Google has some caches at your provider's site (which is the case for Alice DSL in Germany, at least).

I think that's quite some motivation for the providers to at least fix IPv6 connectivity if available and to suppress rogue IPv6 router advertisements in their networks. I had to ensure the former today and the latter is a constant source of grief with the bulk of L2 switches and Wi-Fi access points not being IPv6 ready.

In the graphics side, the major differences between ARM and X86 systems is that on ARM 3D acceleration is done with OpenGL ES. It is mostly a subset of modern OpenGL used on X86 desktop machines. From QEMU point of view this could mostly be ignored, as OpenGL was mostly used on games and specialist applications. This has now been changing, as desktops and user interfaces have started OpenGL to render graphics. Without acceleration, these user interfaces become slower than slugs crossing a tarpit.

For this reason, MeeGo introduced OpenGL ES acceleration support to QEMU. With the lack of easily available MeeGo QEMU images and test setup, I've created a test setup for Linaro 11.05 image.

Running torus opengl es1 demo from mesa-demos inside QEMU.

I ve gotten fed up with Evolution s bugs and slowness. Even though I experience less problems than some weeks ago since I ve applied a patch related to locks in e-d-s, Evolution has now become really too slow and given that my mail flow is not really diminishing, I ve come to the point when I think about migrating. I ve been a user of Gnus for years also (at home, with much satisfaction, as it runs fine inside a GNU Screen), so I could switch to it with moderate damage. Also, as I m using org-mode, it would be quite complementary of course, staying more in Emacs One nice (and even priceless) feature of Evolution is the vfolders, that allow me to manage the tons of emails in different contexts, wherever that may be located. AFAIK, Gnus doesn t offer any comparable feature. But it seems that the most interesting way to have it is to integrate Gnus with NotMuch. Fortunately, my colleague Roland has written a nice howto explaining (among other details of his mail system setup) how to integrate these together. Now, if I m able to setup a similar NotMuch + Gnus setup for newly received mail, I m left with migrating all my piles of old mail, currently stored in Evolution. It seems that one possible way to do so is through copying Evolution mail folders into a newly setup local IMAP server s Maildir storage. The copy is supposed to preserve some flags like the read/unread status of the important flag. From the first tests I ve made, it s possible to install a local Dovecot IMAPd server, configure it so that the mail is stored in the user s ~/Maildir/ maildir directory, which can then be recognized by Evolution as a target for copying mail. It seems that nomuch can then be configured so that it doesn t flag all new mails as unread, and understangs the imap server flags accordingly (unread, important, and such). Needless to say, I m glad all these useful programs are packaged in Debian I need to make further tests and also test Gnus + Notmuch integration, but having a possible solution to migrate my existing mail looks like a relief. I d be curious to read your alternative ideas for such a migration. Stay tuned for next iterations.

As a Debian/Ubuntu user, you re likely to be exposed at some point to an error reported by dpkg. In a series of articles, I ll explain some of the errors that you might encounter. Some error messages can be confusing at times. Most of the error strings do not appear very often and developers thus tend to use very terse description of the underlying problem. In other cases the architecture of the software makes it difficult to pin-point the real problem because the part that displays the error is several layers above the one that generated the initial error. This is for example the case with this error of dpkg:

Unpacking replacement xulrunner-1.9.2 ...
dpkg-deb (subprocess): data: internal gzip read error: '<fd:0>: too many length or distance symbols'
dpkg-deb: error: subprocess <decompress> returned error exit status 2
dpkg: error processing /var/cache/apt/archives/xulrunner-1.9.2_1.9.2.17+build3+nobinonly-0ubuntu1_amd64.deb (--unpack):
 short read on buffer copy for backend dpkg-deb during  ./usr/lib/xulrunner-1.9.2.17/components/libdbusservice.so'

First, the decompression layer discovers something unexpected in the data read in the .deb file and dpkg-deb outputs the error message coming from zlib ( too many length or distance symbols ). This causes the premature end of dpkg-deb --fsys-tarfile that dpkg had executed to extract the .data.tar archive from the deb file. In turn, dpkg informs us that dpkg-deb did not send all the data that were announced (and hence the short read in the error message) and that were meant to be part of the file /usr/lib/xulrunner-1.9.2.17/components/libdbusservice.so . That s all nice but it doesn t help you much in general. What you must understand from the above is that the .deb file is corrupted (sometimes just truncated). In theory it should not happen since APT verifies the checksums of files when they are downloaded. But computers are not infallible and even if the downloaded data was good, it can have been corrupted when stored on disk (for example cheap SSD disks are known to not last very well). Try removing the file (usually with apt-get clean since it s stored in APT s cache) and let APT download it again. Chances are that it will work on the second try. Otherwise consider doing a memory and HDD check as something is probably broken in your computer.

Join my free newsletter and learn more tips for users.

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

I sponsored the upload of fonts-anonymous-pro prepared by Rog rio Brito. This fixed-width font is especially designed for people who write code, for instance by making clear differences between characters such as O and 0, or I, l and 1. I fixed a few glitches in various l10n scripts related to D-I (those tthigns that run daily, for which I receive a daily mail). They were the consequence of Alioth migration and I omitted to fix them until now....mumbling every morning about the scripts' noisy output..:-) I worked on only one bug for samba (doh). This was #631118 which I forwarded upstream in order to get it fixed in 3.5 series (even if 3.6 is due out soon and will be what we target for wheezy). I tried to follow the flow of translations/reviews in DDTP for French. The activity is high, here, with about 10 packages translated every day (most often packages I target for the team...by using high-popcon stats). We even had a big bump during the week-end when Georges Khaznadar (who is very active when it comes at educative software) initiated the translation of many edu-related packages (many of which he maintains himself). That's about it. Quiet week, indeed with more time invested in paid work, including during my spare time..:-). And also a week-end in our country house in Normandy, which usually means more gardening than hacking.

I haven t blogged for a while, because I ve been doing so many things that I scarcely had time nor will for it. Among all those things, and during the weekends of the last few months, we have been teaching kids (8-12 y.o.) about computers, Free Software and technology. Those kids are great, very intelligent, very motivated, and very funny to be with. I miss them a bit after the program has ended. In any case, I ve been given the chance to teach some more kids during summer weekdays, and I m really looking forward to it. The downside of this is that I won t have any summer holidays and, thus, I finally won t be able to attend DebConf 11 in Banja Luka, which was something I was also looking forward too. But, even though that s something I d really love to do, one cannot be in two places at the time, so this year I finally won t be able to attend DebConf either. Have lots of fun! I ll miss you! In case you want to know more about all of this (sorry, links are in Spanish):

• La Servilleta de Paco Prieto [feb 26 2011]: J venes descubriendo talento: tecnolog a, ciencia, emprender y matem ticas
• La Servilleta de Paco Prieto [jun 21 2011]: Estudiantes que quieren m s ca a !!!

Oh, and to show you what I m exchanging you for (nothing personal): I wouldn t like to end this post without thanking all the kids from both Campus TIC and Yo Programo for being so cool, and also to welcome the kids from Fantastic Park, in case any of them -or their parents- are reading. Oh, and all of you who attend DebConf this year, have a lot of fun!

In brief:

• I made the firefox-wrapper package public. Although it seems that mozilla.debian.net is liable to be preferred by most.
• I wrote a script to archive a reddit inbox as a maildir folder, reddit2maildir. Perfect for archiving those interesting discussions that aren't public.
• I posted some random animal photographs, mostly to remind myself to take more.

Finally having recently bought the Canon 70-200mm f/2.8 lens for a King's ransom I've agreed to buy the 24-105mm f/4.0 lens from a friend - that will be my new portrait lens of choice, and I'll sell my existing 85mm f/1.8. ObQuote: "I could help you cross your yard." - Up