You can see it from my blog activity as well, I simply lack time for lot of things. My Gammu mail folders are horribly full of unread mail, it took me there three months to release a new testing version and there are still some patches pending for review. On phpMyAdmin side I spend most time with my GSoC students, who progress really well, but that's pretty much all I can do there. The good news is that phpmyadmin.cz website has new maintainer and is again getting new content. Hopefully it will stay alive for longer time to bring back lost visitors. My Debian contributions are in still pretty good shape and I manage to fix important bugs, though my MPD related packages are still for sale. Still considering whether to go or not to go to Debconf, my decision will be probably based on fact whether I will get travel sponsorship or not (and when it would happen). Besides these free software activities I began to be more active in Spole n aktivity (in Czech) project for organizing various activities to spend free time. Occasionally I also contribute to OpenStretMap, but it's more or less random time when I notice something is wrong or when I manage to visit some place which is not that good mapped. The good thing is that Prague is pretty good shape there, so it does not motivate me to spend too much time on this :-). And of course there is my work at SUSE, working on usual L3 front and improving our Django based incident tracking tool. Maybe I should step down from some of these, but it would be pretty hard for me to choose which one...

Filed under: Debian English Gammu Phpmyadmin 2 comments Flattr this!

It is about time I get back to this blog. It has been way way too long and there are a few things I want to say (a lot to report). But I will start with something small, a mother of a programming manifesto. Enjoy.

Quiet week, indeed. I spent part of the week-end of 4-5 June to re-setup my server at home after receiving the new box from my ISP (Free). This box can no longer be configured as an Ethernet bridge but only as a router. As a consequence, my home box no longer has my public IP on one of its Ethernet interfaces, which changes several details in the local configuration. The result is finally an hopefully safer setup, as the box now filters everything but port 22, 25, 80, 443, 993, 2317 (geneweb) while the server has similar filters in its iptables. Two firewalls instead of one. I did some bug cleaning on samba, again. The bug count should lower again in upcoming releases, but we probably reached a point where it can't go further down. Half of these are reported upstream. I should maybe check with them if they're considered fixed, pointless or just ignored as of now..:-) On Wednesday 8th, I released a samba 3.6.0rc2 package less than 12 hours after upstream published it. Yet another broken record..but it was easy as the package was completely straightforward. During the week, the French team worked on several DDTP translations now that the DDTSS is repaired (and apparently much more stable). I also sent an update for devscripts mannpages French translation. I will resume activity on l10n NMU. It's now time to think about it. Letting things pile up without nagging maintainers just leads to l10n stats slowly decreasing. We're aiming at 100% for debconf translation for 7 languages, so the wheezy freeze time will be difficult. Better start now. The most difficult part is having maintainers understand that, yes, we should care THAT early in the release process. The most complete language as of now (Russian) is already missing nearly 100 strings in about 12 packages (those that changed/introduced tempaltes recently). I have to prod these maintainers now.

Just a quick heads-up: I ve just uploaded mesa 7.10.2-4, which is multiarch-enabled, thanks to Steve Langasek. As explained in its changelog, this breaks the X server currently in testing and in unstable, but a rebuild is already pending, which will make everyone upgradable. For curious people, those commands took care of scheduling the binNMU, with a proper dep-wait:

wb nmu xorg-server . ALL . -m 'Rebuild against new (multiarch-enabled) mesa.'
wb dw xorg-server . ALL . -m 'libgl1-mesa-dev (>= 7.10.2-4)'

In the meanwhile, if your mirror gets a new mesa without the rebuilt server, your package manager should bail out and refuse to upgrade mesa (or propose to remove the server). So wait a bit, upgrade everything, and enjoy! mesa 7.10.3 (released a few hours ago) should reach unstable tomorrow, so that we can ask our users to track (possible) regressions between 7.10.2-3 and 7.10.3-1 to either 7.10.2-4 (multiarchification), or to 7.10.3-1 (the stable upgrade), thanks to the excellent http://snapshot.debian.org/ service.

In a recently published article, Paul Vixie, past author and architect of BIND, one of the most popular internet domain server, explains why DNS servers should use anycast for increased reliability and faster answers. The main argument against unicast is that some resolvers may not be smart enough to select the best server to query and therefore, they may select a server on the other side of the planet. Since, you cannot go faster than light, you get a penalty of about 100 milliseconds in this case.

Unicast & anycast Most addresses that you handle are unicast addresses, i.e. the address of a single receiver. Any time you send a packet to an unicast address, it will be forwarded to this single receiver. Another common network addressing system is multicast (which happens to include broadcast). When you send a packet to a multicast address, several receivers may get it. The packet is copied as needed by some nodes. Anycast addresses allow you to send a packet to a set of receivers but only one of them will receive it. The packet will not be copied. Usually, the idea behind anycast is that the packet is sent to the nearest receiver. There is no universal way to determine if an IP address is an unicast address or an anycast address just by looking at it. For example 192.5.5.241 is an anycast address while 78.47.78.132 is an unicast address. ISC, which maintains BIND, operates the F root domain server, one of the 13 Internet root name servers. This server is queried by using 192.5.5.241 IPv4 anycast address or 2001:500:2f::f IPv6 anycast address. ISC has published a document explaining how anycast works. Several nodes around the globe announces the same subnet using BGP. When one router running BGP has to send a query to the anycast address, it will have several choices in its BGP table. It will usually select the shortest path and route the query to the corresponding router. Some nodes may choose to restrict the announcement about the subnet containing the anycast address. They are called local nodes (by opposition to other global nodes). This allows them to serve query only from their clients and use cheaper connectivity and hardware.

Lab Let s play with anycast by setting up a lab to experiment with it. We want to setup an IPv6 anycast DNS service using two global nodes, G1 and G2, and one local node, L1. We build some kind of mini-Internet. See :

Setting up the lab This lab will use UML guests for all nodes. For more details on how this works, look at my previous article about network labs with User Mode Linux. You first need to grab the lab:

$ git clone https://vincentbernat@github.com/vincentbernat/network-lab.git
$ cd network-lab/lab-anycast-dns
$ ./setup

You will need to install the dependencies needed by the script on your host system. The script was tested on Debian unstable. If some of the dependencies do not exist in your distribution, if they don t behave as in Debian or if you don t want to install them on your host system, you can use debootstrap to create a working system:

$ sudo debootstrap sid ./sid-chroot http://ftp.debian.org/debian/
[...]
$ sudo chroot ./sid-chroot /bin/bash
# apt-get install iproute zsh aufs-tools
[...]
# apt-get install bird6
[...]
# exit
$ sudo mkdir -p ./sid-chroot/$HOME
$ sudo chown $(whoami) ./sid-chroot/$HOME
$ ROOT=./sid-chroot ./setup

We are running a lot of UML guests in this lab. We assign 64 MB to each host. UML guests do not use host memory until they need it but because of cache subsystem, you can expect that each guest will use 64 MB of memory. This means that you need about 2 GB of RAM to run this lab. Moreover, each guest will create a file representing its memory. Therefore, you need about 2 GB of free space in /tmp too. Routers are named after their AS number. The router of AS 64652 is just 64652. Paris, NewYork and Tokyo are the exception. The lab will use only one switch but we will use VLAN to create several L2 networks. Each link in our schema is an L2 network. Each link will get its own L3 network. Those networks are prefixed with 2001:db8:ffff:. Leaf AS have their own L3 network 2001:db8:X::/48 where X is the AS number minus 60000. Look at /etc/hosts on each host to get the IP of all hosts.

Mini-Internet routing AS 64600 is some kind of Tier-1 transit network (like Level 3 Communications). It has three points of presence: Paris, New York and Tokyo. AS 64650 is an European regional transit network, AS 64640 is an East Asian regional transit network and AS 64610, 64620 and 64630 are North American regional transit network which are peering each other. Other leaf AS are local ISP. This is not really what Internet looks like but shaping our lab like a tree allows us to not deal with a lot of BGP stuff: we ensure that the shortest path (in number of BGP hops) from one client to one server is the best path. Each BGP router will get a basic BGP configuration containing only the list of peers. Since Paris, Tokyo and NewYork are in the same AS, they will use iBGP. They are fully meshed for this purpose but this does not provide redundancy because iBGP routes are not redistributed inside iBGP. A more complex setup would be needed to provide redundancy inside AS 64600. We don t use an IGP inside leaf AS as we should: for the sake of simplicity, we redistribute directly connected routes into BGP. While in my previous lab, I used Quagga, I will use BIRD in this one. It is a more modern daemon with a clean design on how routing tables may interact. It also performs better. However, it lacks several features from Quagga. The configuration for BIRD is autogenerated from /etc/hosts. We use only one routing table inside BIRD. This table will be exported to the kernel and to any BGP instance. Some directly connected routes will be imported (those representing client networks) as well as all routes from BGP instances. Here is an excerpt of 64610 s configuration:

protocol direct  
   description "Client networks";
   import filter  
     if net ~ [ 2001:db8:4600::/40 40,48  ] then accept;
     reject;
    ;
   export none;
 
protocol kernel  
   persist;
   import none;
   export all;
 
protocol bgp  
   description "BGP with peer NewYork";
   local as 64610;
   neighbor 2001:db8:ffff:4600:4610::1 as 64600;
   gateway direct;
   hold time 30;
   export all;
   import all;
 

We do not export inter-router subnets to keep our routing tables small. This also means that those IP addresses are not routable in spite of the use of public IP addresses. Here is the routing table as seen by 64610 (use birdc6 to connect to BIRD):

bird> show route
2001:db8:4622::/48 via 2001:db8:ffff:4610:4620::2 on eth3 [bgp4 18:52] * (100) [AS64622i]
                   via 2001:db8:ffff:4600:4610::1 on eth0 [bgp1 18:52] (100) [AS64622i]
2001:db8:4621::/48 via 2001:db8:ffff:4610:4620::2 on eth3 [bgp4 18:52] * (100) [AS64621i]
                   via 2001:db8:ffff:4600:4610::1 on eth0 [bgp1 18:52] (100) [AS64621i]
2001:db8:4612::/48 via 2001:db8:ffff:4610:4612::2 on eth2 [bgp3 18:52] * (100) [AS64612i]
2001:db8:4611::/48 via 2001:db8:ffff:4610:4611::2 on eth1 [bgp2 18:52] * (100) [AS64611i]

As you can notice, it knows several paths to the same network, however, it only selects the best one (based on the length of the AS path):

bird> show route 2001:db8:4622::/48 all
2001:db8:4622::/48 via 2001:db8:ffff:4610:4620::2 on eth3 [bgp4 18:52] * (100) [AS64622i]
        Type: BGP unicast univ
        BGP.origin: IGP
        BGP.as_path: 64620 64622
        BGP.next_hop: 2001:db8:ffff:4610:4620::2 fe80::e05f:a3ff:fef2:f4e0
        BGP.local_pref: 100
                   via 2001:db8:ffff:4600:4610::1 on eth0 [bgp1 18:52] (100) [AS64622i]
        Type: BGP unicast univ
        BGP.origin: IGP
        BGP.as_path: 64600 64620 64622
        BGP.next_hop: 2001:db8:ffff:4600:4610::1 fe80::3426:63ff:fe5e:afbd
        BGP.local_pref: 100

Let s check that everything works with traceroute6 on C1:

# traceroute6 G2.lab
traceroute to G2.lab (2001:db8:4612::2:53), 30 hops max, 80 byte packets
 1  64652-eth1.lab (2001:db8:4652::1)  -338.277 ms  -338.449 ms  -338.502 ms
 2  64650-eth2.lab (2001:db8:ffff:4650:4652::1)  -338.324 ms  -338.363 ms  -338.384 ms
 3  Paris-eth2.lab (2001:db8:ffff:4600:4650::1)  -338.191 ms  -338.329 ms  -338.282 ms
 4  NewYork-eth0.lab (2001:db8:ffff:4600:4600:1:0:2)  -338.144 ms  -338.182 ms  -338.235 ms
 5  64610-eth0.lab (2001:db8:ffff:4600:4610::2)  -338.078 ms  -337.958 ms  -337.944 ms
 6  64612-eth0.lab (2001:db8:ffff:4610:4612::2)  -337.778 ms  -338.103 ms  -338.041 ms
 7  G2.lab (2001:db8:4612::2:53)  -338.001 ms  -338.045 ms  -338.080 ms

Let s see what happens if we shut the link between NewYork and 64610. This link is VLAN 10. Since vde_switch does not allow to shut a port, we will change the VLAN of port 9 to VLAN 4093. After at most 30 seconds, the BGP session between NewYork and 64610 will be torn down and packets from C1 to G2 will take a new path:

# traceroute6 G2.lab
traceroute to G2.lab (2001:db8:4612::2:53), 30 hops max, 80 byte packets
 1  64652-eth1.lab (2001:db8:4652::1)  -338.382 ms  -338.499 ms  -338.503 ms
 2  64650-eth2.lab (2001:db8:ffff:4650:4652::1)  -338.284 ms  -338.317 ms  -338.151 ms
 3  Paris-eth2.lab (2001:db8:ffff:4600:4650::1)  -337.954 ms  -338.031 ms  -337.924 ms
 4  NewYork-eth0.lab (2001:db8:ffff:4600:4600:1:0:2)  -337.655 ms  -337.751 ms  -337.844 ms
 5  64620-eth0.lab (2001:db8:ffff:4600:4620::2)  -337.762 ms  -337.507 ms  -337.611 ms
 6  64610-eth3.lab (2001:db8:ffff:4610:4620::1)  -337.531 ms  -338.024 ms  -337.998 ms
 7  64612-eth0.lab (2001:db8:ffff:4610:4612::2)  -337.860 ms  -337.931 ms  -337.992 ms
 8  G2.lab (2001:db8:4612::2:53)  -337.863 ms  -337.768 ms  -337.808 ms

Setting up anycast DNS Our anycast DNS service has three nodes. Two global ones, located in Europe and North America and one local one targeted at customers of AS 64620 only. The IP address of this anycast DNS server is 2001:db8:aaaa::53/48. We assign this address to G1, G2 and L1. We also assign 2001:db8:aaaa::1/48 to 64651, 64612 and 64621. BIRD configuration is adapted to advertise this network:

protocol direct  
   description "Client networks";
   import filter  
     if net ~ [ 2001:db8:4600::/40 40,48  ] then accept;
     if net ~ [ 2001:db8:aaaa::/48 ] then accept;
     reject;
    ;
   export none;
 

We use NSD as a name server. This is an authoritative only name server. The configuration is pretty simple. We just ensure that it is bound to the IPv6 anycast address (otherwise, it may answer with the wrong address). The zone file is customized to answer the name of the server:

#(C1) host -t TXT example.com 2001:db8:aaaa::53
Using domain server:
Name: 2001:db8:aaaa::53
Address: 2001:db8:aaaa::53#53
Aliases:
example.com descriptive text "G1"
#(C5) host -t TXT example.com 2001:db8:aaaa::53
Using domain server:
Name: 2001:db8:aaaa::53
Address: 2001:db8:aaaa::53#53
Aliases:
example.com descriptive text "G2"

If we try from C3, we may be redirected to L1 while we are not a customer of AS 64620. A common way to handle this is to let 64621 tag the route with a special community that will let know 64620 that the route should not be exported.

protocol direct  
   description "Client networks";
   import filter  
     if net ~ [ 2001:db8:4600::/40 40,48  ] then accept;
     if net ~ [ 2001:db8:aaaa::/48 ] then  
          bgp_community.add((65535,65281));
          accept;
      
     reject;
    ;
   export none;
 

The community used is known as the no-export community. BIRD knows how to handle it. However, we hit here some limitations of BIRD:

1. The correct way to let 64622 knows about this route is to build a BGP confederation for AS 64620 and let AS 64622 and AS 64621 be part of it. This means that those three AS will be seen as AS 64200 from outside of the confederation. Moreover, the no-export community would allow to export the route only within the confederation. This is exactly what we need but BIRD does not support confederations.
2. BIRD first selects the best route to export then apply filtering. This means that even if 64620 knows non-filtered route to 2001:db8:aaaa::/48, it will select the route to L1, filter it out and export nothing to 64622.

Therefore, we need to fallback to ask BIRD to not export the route to AS 64600, 64610 and 64630 on 64620. We could use a special community to filter out the route but we keep it simple and just filter the route directly.

filter keep_local_dns  
   if net ~ [ 2001:db8:aaaa::/48 ] then reject;
   accept;
 
protocol bgp  
   description "BGP with peer NewYork";
   local as 64620;
   neighbor 2001:db8:ffff:4600:4620::1 as 64600;
   gateway direct;
   hold time 30;
   export filter keep_local_dns;
   import all;
 

Voil . Only C4 will be able to query L1. If AS 64621 is missing, it will query G2 instead. One major point about anycast is to know that redundancy is done at the AS level only. If the name server on L1 does not work correctly, requests will still be routed to it. Therefore, with anycast, you still need to provide redundancy inside each AS (or stop advertising the anycast network as soon as there is a failure).

Beyond DNS Anycast can be used to serve HTTP requests too. This is less commonly used because your connection may be rerouted to another node while it is still running. This is not a problem with DNS because there is no connection (you send a query, you receive an answer). There are at least two CDN (MaxCDN and CacheFly) which uses anycast to ensure low roundtrip time and very high reliability. Setting up an HTTP server with an anycast address is no different than setting up a DNS server. However, you need to ensure maximum stability of the routing path to avoid the connection to be dropped while running. I suppose that this is done by hiring some high-level BGP expert. You can also mix unicast and anycast:

• anycast DNS answers the IP address of a nearby unicast HTTP server, or
• anycast DNS answers the IP address of an anycast HTTP server that will issue a redirect to an unicast HTTP server when downloading or streaming large files.

Well, I booked my plane tickets on March, but there was some $JOB related problems, since the company where I work is facing a merge(and I was pretty sure that I will finish being unemployed), so I was really sad that I ll have to drop my plans and loose some money, but so far everything looks ok, I m lucky and the government did not approve the merge and asked for more bureaucratic documents, this give us one year more, so I can finally say that I ll go to DebConf11 This year I m planning to came a bit early and stay at least two days on DebCamp, my work plan is to work on pkg-boinc s long TODO list, I m really happy since I missed DebConf10, long time without see some Debian friends faces

This is a simple tip but an important one: when you re installing Debian, take the time required to ensure the machine is connected to the Internet with a wired connection. If you have DHCP available, the debian-installer will use it to configure the network. Why not use the wireless connection? Because debian-installer in Squeeze doesn t support WPA encryption, but only WEP. So if you re using WPA, picking the wireless connection will lead to no working network during the installation and this is to be avoided. If you re still using WEP, you can go ahead of course. If you only have a wireless connection with WPA, your might want to help the debian-installer team and add the required support. Matthew Palmer did some work on it a few months ago (see this mail and his branch in the netcfg git repository) but he resigned from the d-i team in the mean time. So WPA support is still not available in the wheezy debian-installer. Why is the network so important?

1. The tasks that you select during the installation process might suggest installation of supplementary packages that are not available on your installation disc. If you install without network, the resulting system might differ from the expected one since it will be missing some packages that are available in the Debian repositories but not on your installation disc.
2. Your installation media might be old and there are security updates that have been published. If you do your initial installation with network, the security updates will be installed before the reboot and thus before the services are exposed over the network.
3. If you re not installing a desktop with network-manager (Debian s default GNOME Desktop provides it), the initial network configuration is important since this configuration is kept for the future. And you surely want network connectivity on your machine, don t you?
4. Without network, APT s sources.list will not be properly configured to include an HTTP mirror of your country. And really, I prefer when apt-get install can work without the initial installation disc.

If you want to read more articles like this one, click here to subscribe to my free newsletter. You can also follow me on Identi.ca, Twitter and Facebook.

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

It was time to update my creaking old laptop. I ordered HP6-6023TX online and after a few days it arrived just before a long weekend. I first backed up Windows 7 onto a set of DVDs and found that either my blank DVDs are old or this new DVD drive is far more fussy. There were quite a few coasters made until I gave up and bought some new ones. DVDs seemed to be trouble for me that day. I downloaded the Debian 6.0.4 DVD image but couldn t burn it. Brasero would just keep saying calculating checksum and go no further. So after waiting too long, the CD iso was downloaded and installed. Installation of debian onto the laptop was straightforward. That is if you used a wired connection. Wireless needs the non-free firmware and I gave up trying to work out how to install it at debian-installer time as it didn t see the tar.gz full of firmware on the USB stick. Wireless worked perfectly once I loaded everything on. So at this point with not much trouble I had an almost fully working setup. Even the webcam and sound was working. Video Fun The laptop is one of these strange modern ones that has two video cards. The low-spec one is an Intel Sandybridge while the higher one is an AMD/ATI Radeon HD 6700M. The idea being you use the ATI when plugged in and the Intel on batteries. Xorg worked first go, but only on the Intel chip. Trying to force X to use the ATI driver with an Xorg configuration resulted in the Xserver crashing. Next attempt was the fglrx packages within Debian. aticonfig said it didn t know about the card. The reason for this is that the Debian packages use fglrx version11.4 and I needed for my card 11.5 So close but so far away. OK, so building the ATI software can t be that hard can it? A nice set of instructions on the Debian wiki and we had errors. The first problem is that the packaging used is ancient. The second problem is much more serious; it won t compile. I was stuck about here until I hopped onto the Debian irc channel and asked about it and someone found a very useful webpage about compiling the ATI drivers on Debian which importantly had information about the patches you need, especially the blk patch. Success! the program compiled and installed. A small xorg.conf specifying the fglrx driver and the BusID and we were up and running. I now have accelerated graphics on the laptop. Ouch, my eyes! I do actually get outside (one of my hobbies is gardening and that is an outdoor activity) so I don t need a monitor screen trying to give me a suntan. The default screen brightness on the laptop could be described as sub-nova . I m sure there is some alien astronomers several light-years away who will in many years time wonder what that flash from the unimpressive end of the milky-way was about. To protect your eyes and keep the neighborhood complaints down you can reduce the brightness to something sane. You do this in the power management settings which for me is System -> Preferences -> Power Management. I can see again!

Over the course of the last five years, some relatives of me and I have been working on a family book which lists all descendants of my grandgrandgrandgrandfather Isaak Riehm, born 1799, and his wife Charlotte. My task was everything related to maintaining the data, running the infrastructure and generating the final book. In the end, we have collected biographical details, often with the person s live story, of 703 descendants, 285 partners and 416 parents-in-law. Together with an extensive preface the book now has a respectable size of 401 pages, includes 144 pictures and maps and over 200 copies have been printed and sold through the family. Although I do not think that the details of the lives of my family is very interesting for the general public, or even suitable for general release, I do want to show the fruit of our work. Therefore, I have created a stripped-down on-line version that only covers the first four generations. I bundled the book body with the cover and the end sheets into one complete PDF file (caution, large: 54MB, and of course in German). Some nifty embellishments of the book that I especially like are the abstract looking descendant fan in the front-end and back-end sheets, the separating bars between the persons which indicate the livespan of that person between 1799 and 2011 and the maps of the birth places and Isaak s travel destinations in the preface. Now to the technical details: Naturally, I used only Free Software in the genesis of the work (The cover is an exception, as it was not created by me). The most important is definitely gramps, a free genealogy system that held all our data. It is written in python and extensible with plug-ins, so I was able to create a custom report that takes the data relevant for us, filters for people who have agreed to appear in the book, and then generate LaTeX code that typesets the book, ready to be printed. I learned a great deal of LaTeX for this project, which uses over 30 different packages and required me to create a font of my own (which, as a side product, lead to a publication in the Linux-Magazin). For the maps I found the Generic Mapping Tools (GMT) and the freely available data for that of great use. I still had to manually collect the coordinates for all the places I wanted to show up in the map. Here, I relied mostly on Wikipedia. The fan which appears in the end sheets is laid out using a Haskell program (naturally, I have to use Haskell somewhere). Of course, generating the book is only one side of the story; first, the data has to be collected and edited. For that, I wrote a plug-in to gramps that creates forms for each person. These forms contain the current known data and are used to correct and extend our knowledge. One variant of the form, created using LaTeX, was printed and mailed by snail-mail around the country and beyond, for those who are not reachable by mail. The other variant is an HTML form, hosted on a password-protected web site. Changes to that form cause the server to send an e-mail with a description of the changes (and only the changes, not the fields that are left untouched) to the mailing list of our team. There, the changes can be reviewed, e.g. for spelling and stylistic issues, and finally I copy n pasted them into gramps. These parts are implemented in python as well. Since genealogical data is never complete or up-to-date, I have set up a password-protected mediawiki based web site for the book where we collect corrections and additions to the data in the book. We have never anticipated that it would be so much work and that it would take us so long to finish this project, but we pulled it through and we are very happy with the result. Also, the reception has been very good and it was definitely a success. At this point I d like to express my gratitude to the hundreds of Free Software developers out there whose code we used and without whom it would not have been possible publish the book in the current form at all! Update: Due to some requests, I am making the code that I wrote available. You can download the tarball. Note that the code is a big mess and will not be usable right away. I guess if you can get the code to run and actually adjust to your needs, then you can as well write it yourself. Nevertheless it might be useful as inspiration or reference.

Last year the Psychologist and Baptist minister George Rekers who is famous for anti-homosexuality pseudo-science was discovered to be hiring gay escorts from Rentboy.com. Lots of LULZ there. But the story didn t end there. It turns out that George Rekers did some research on a child who ended up committing suicide as an adult, and the circumstantial evidence suggests that George s actions are directly related to the suicide [1]. The Rentboy.com affair doesn t seem so funny now. The Box Turtle Bulletin has a series of articles about Kirk Andrew Murphy s suicide and the roles of George Rekers and Richard Green in all of this [2], the articles are well written and generally appear to be well researched I recommend reading the articles if you can stomach them (lots of nasty stuff is described). The section answering the question of who s responsible for the mistreatment of Kirk Andrew Murphy [3] where they describe the use of ABA (AKA the Lovaas Technique) is interesting. Ivar Lovaas worked with George Rekers in such research and published a paper with him. The term ABA gets an immediate hostile reaction in the Autism community, but until now I hadn t realised why so many people hate it so much. It seems that to some extent I made the classic mistake of misjudging the reports of Autistic people who are unable to present their case well (as opposed to the psychologists who can present any position very well even if it s utterly insane). In the past I had the impression that ABA wasn t inherently bad, it was just implemented in a bad way in some cases now it seems that ABA was designed in an evil way right from the start. There is one massive problem with the Box Turtle analysis, he says Behavioral analysts don t dig around much into people s feelings, fears, dreams, family relationships or childhood memories. Indeed, in cases like autism, Lovaas s specialty, those avenues of exploration would be irrelevant . It could be that Jim Burroway (the Box Turtle writer) is merely quoting someone else without attribution, but even so saying that the feelings, fears, and dreams of a group of people are irrelevant is just awful, a statement that denies the humanity of a group of people can t be quoted without further explanation. In his article about ABA Jim refers to childhood Autism as a condition for which there is no hope for interior change [4]. I m not sure if he s just saying that Autistic children are incapable of learning or whether it s all Autistic people, in either case it s nonsense in terms of science and nasty as well. Generally I expect that members of various minority groups will show more sympathy to each other than they receive from the general population. Jim s posts are a great disappointment. I understand that he would be rather stressed about the horrible things that George Rekers et al did, but even so he should be able to avoid that sort of thing. Jim is obviously a very talented writer and can do better. One might think that Jim s posts use the word Autism to refer only to the people who are non-verbal (or in other ways less capable than the huge number of Autistic people who work for companies like Google and IBM). But that s no excuse either. You can find blogs and essays written by non-verbal Autistic people that describe their experiences if you care to search for them. It s obvious that they are people too and deserve to be treated as people not objects. Abusing Autistic children to try and make them impersonate NT children is no less evil than abusing children who don t fit gender norms.

• [1] http://edition.cnn.com/2011/US/06/08/rekers.sissy.boy.experiment/
• [2] http://www.boxturtlebulletin.com/what-are-little-boys-made-of-main
• [3] http://www.boxturtlebulletin.com/cuius_culpa
• [4] http://www.boxturtlebulletin.com/blind-mans-bluff

This is a follow-up on TDebs with some detail of how existing packages can be adapted to support TDebs.

$ cat debian/package-tdeb.tdeb

[gettextdir] po
[gettextname] package
[po4apodir] doc/po
[po4amandir] doc/package/man/
[po4acommand] po4a-build


What's happening then? Well, the first thing to take into account is that a lot of the values for these settings will be dictated by upstream, which is why it is necessary for maintainers to add this information as a support file in debian/. I tried determining all this information automatically but the script got far too long and still was far from complete.

• gettextdir - usually po but some upstream packages can support multiple po generation, so this allows for those.
• gettextname - the hardest thing to identify reliably, this is the name of the files to be installed in /usr/share/locale/lang/LC_MESSAGES/ and the name of the of the POT file.
• po4apodir - po4a is for documentation translation support, which is more variable, so a po4acommand field is available too.

Other changes
The (currently unsupported in Debian) XC-Package-Type: tdeb option is used in debian/control to mark a new or existing package as a TDeb. To use an existing package, it must comply with the rules for a TDeb including that it must be Architecture: all. The other rules centre around build issues. If any of the files in the existing package would require execution of any part of the normal build process of the package, these would have to be moved out of the package before that package could be a TDeb. The reason is that TDeb generation by translators needs to not require a full build environment for every individual package and must not risk modifying package contents in ways which are related to the build environment. So, unchanged images and other architecture-independent files are OK, any files which need build-dependencies are a problem. I don't know how many packages there are out there with such files. If you have a -data or -common package which contains translated data and that package also includes architecture-independent files, I'd be interested in knowing the name of the packages involved. If those packages also include files which are generated or modified within the package build, I'll be particularly interested in knowing about those source packages.
debconf
The most common use of TDebs during a release cycle is probably going to be debconf template updates by Christian and these are handled without needing a listing in the .tdeb file.
Other formats
I'm looking at QtLinguist support and it should be fairly straightforward using the .tdeb file arrangement.

Once that's done (in a branch, please - these can't be uploaded yet), the package can be tested with the soon-to-be-uploaded emdebian-tdeb package. The old content has been moved into the emdebian-grip-server package and the dependencies of the old version stripped back. The package contains two scripts dpkg-gentdeb and dh_gentdeb which I hope to get included into the respective packages in time for Wheezy. The idea will be that build systems (dh7, CDBS, debhelper-plain etc.) includes a call to the relevant script. (dh_ is just a wrapper around dpkg- in this case). This would allow maintainers to create the first TDeb, get that through NEW and then the fun starts. Once the translation mechanism is set up, I would like a nominated person (likely to be Christian if he agrees) to co-ordinate translation updates for particular packages to allow for a single upload including updates for many translations. This would be package_version+t1_all.tdeb and an appropriate .diff.gz or debian.tar.gz. No binary upload, no impact on testing migrations.

This is mostly theory right now but the scripts do exist in Emdebian SVN.

Still more testing to do but I hope to upload these scripts to unstable in the next few days.

If you have debootstrapped the internal microSD card, the vendor-supplied U-Boot config should serve you adequately. To boot off of a USB stick, however, interrupt the boot sequence (if you don't have a JTAG/serial board at this point, go buy one immediately), and enter the following commands:

setenv x_bootcmd_kernel fatload usb 1:1 0x6400000 uImage
setenv x_bootargs_root root=/dev/sdc2 rootdelay=10
saveenv
reset

If you just want to testboot once, and don't want to make it permanent, omit the saveenv. If you do want to make it permanent, consider removing the superfluous pings from the bootcmd, but be careful to escape semicolons and dollar signs instead of zealously copying and pasting. If you haven't bothered putting a FAT partition with uImage on the USB stick, omit the setenv x_bootcmd_kernel line. Once you've booted Debian, you may wish to natively-debootstrap or copy your new partition to /dev/sda2 (which is what Linux will call the ext3 partition of your microSD card). To then return to fully booting off of microSD so you can repurpose the USB stick,

setenv x_bootcmd_kernel fatload usb 0:1 0x6400000 uImage
setenv x_bootargs_root root=/dev/sda2 rootdelay=10
saveenv
reset

Enjoy.

A stumbled across Start Com a few months ago, an Israeli company that run a Certificate Authority (CA) called StartSSL with a root certificate in all the modern browsers and operating systems. Best of all they don t participate in the cartel run by the rest of the SSL certificate industry and offer domain validated certificates at the price it costs them to issue them nothing. I had the first opportunity to use their services today when I needed an SSL cert to secure the IMAP server I run for my parents and I was very pleased with the experience. The web interface is a bit weird and you have to jump through some strange hoops, but to save paying more money to the SSL certificate cartel it seemed more than worthwhile. Like most CAs these days the certificate which signs your server certificate is not the actual root certificate included in your operating system or browser, but an intermediate CA certificate which is in turn signed by the root certificate. This means that you have to ensure that your server includes the intermediate CA certificate alongside the server certificate so the client can validate the entire path back to the root. Unlike Apache which explicitly allows you to specify a certificate chain file, the openssl methods used by Cyrus 2.2 only seem to recognise a single CA certificate in the file pointed to by tls_ca_file. All as not lost however, as the openssl libraries are actually quite smart and will automagically determine which intermediate certs they need to bundle into the handshake if you install them appropriately under /etc/ssl/certs (at least on Debian). The trick is that you have to install the intermediate CA cert into a file named after the hash of the certificate, like so:

# wget http://www.startssl.com/certs/sub.class1.server.ca.pem -O /etc/ssl/certs/startcom-class1-intermediate.pem
# hash=$(openssl x509 -hash -noout -in /etc/ssl/certs/startcom-class1-intermediate.pem)
# ln -s ./startcom-class1-intermediate.pem /etc/ssl/certs/$ hash .0
# ls -l /etc/ssl/certs/$ hash .0
lrwxrwxrwx 1 root root 34 2011-06-13 07:43 /etc/ssl/certs/ea59305e.0 -> ./startcom-class1-intermediate.pem
Then in imapd.conf:

tls_cert_file: /etc/ssl/certs/your-server-cert.pem
tls_key_file: /etc/ssl/private/your-server-key.key
tls_ca_file: /etc/ssl/certs/startcom-ca.pem
Voila. Works everywhere I ve tried so far. Start Com Highly Recommended. I ll be using them for any future SSL certificate purchases (e.g. EV certs) that I need to make.

I keep on seeing people sending messages saying "see attached file" or similar in their emails, but then forgetting to actually attach the file. I used to do it myself lots, but then with the help of some ideas I found on the net I wrote the following script to use with mutt. To use it, use the setting "set sendmail=" to point at it.

---

#!/bin/bash
#
# mutt-sendmail
# helper script to reduce embarrassment with mutt :-)
#
# Copyright 2011 Steve McIntyre <steve>
# GPL v2
###
# save msg in file to re-use it for multiple tests
###
TMPFILE= mktemp -p ~/tmp -t mutt.XXXXXX    exit 2
cat > $TMPFILE
## Attachment keywords that the message body will be searched for:
KEYWORDS='attach patch'
## Define test for multipart message.
function multipart  
    grep -q '^Content-Type: multipart' "$TMPFILE"
 
## Define test for keyword search.
function word-attach  
    grep -v '^>' "$TMPFILE"   grep -v "^X-attached:"   grep -E -i -q "$KEYWORDS"
 
## Header override.
function header-override  
    grep -i -E "^X-attached: *none *$" "$TMPFILE"
 
###
# FINAL DECISION:
# chain series of functions, use !   && for logic connections,
###
if multipart   ! word-attach   header-override; then
    formail -I bcc < $TMPFILE   /usr/lib/sendmail -oi -oem "$@"
    status=$?
else
    echo "No file was attached but a search of the message text suggests there"
    echo "should be one.  Add a header \"X-attached: none\" to override this"
    echo "check if no attachment is intended."
    status=1
fi
rm -f $TMPFILE
exit $status

As I'm asking for donations to help cover the traffic costs for the wine-unstable packages I provide and to support my Debian work in general if appreciated, I thought a "Thank you!" to all those who've donated something so far would be in order (don't worry, I won't disclose any names of donators or other personal information). Thus here we go: Thank you! It's much appreciated. For all those who just read this and think they'd like to donate something too, if just they could locate the links to do so, here they come:

• PayPal (general donation link, the wine-unstable specific link can be found on the package page
• Flattr:
  • general Debian work
  • wine-unstable packaging (traffic)
  • donate through Flattr (you need to be logged in, otherwise the previous link will redirect you to the main page)

See comments at the end about this 3rd version This is time again for yet another bubulle game: counting the number of developers per country. I already published such analysis in 2010 and 2009. So, here we are with the June 2011 version, sorted by the ratio of *active* developers per million population for each country.

Act: number of active developers
Dev: total number of developers
A/M: number of active devels per million pop.
D/M: number of devels per million pop.
2009: rank in 2009
2010: rank in 2010
June 2011: rank now

Code	Name	Population	Act Dev	Dev	Act/Million	Dev/Million	2009	2010	June 2011
fi	Finland	5374781	21	31	3,91	5,77	1	1	1
ch	Switzerland	7866500	21	26	2,67	3,31	2	2	2
mq	Martinique	397730	1	1	2,51	2,51			3
no	Norway	4964500	12	15	2,42	3,02	5	4	4
nz	New Zealand	4393500	10	15	2,28	3,41	4	3	5
ie	Ireland	4470700	10	13	2,24	2,91	13	9	6
se	Sweden	9354462	19	35	2,03	3,74	3	6	7
lu	Luxemburg	511840	1	1	1,95	1,95	8	5	8
de	Germany	81802000	155	221	1,89	2,7	7	7	9
at	Austria	8404252	15	25	1,78	2,97	6	8	10
fr	France	63136180	91	119	1,44	1,88	12	12	11
au	Australia	22632213	31	57	1,37	2,52	9	10	12
be	Belgium	11007020	15	17	1,36	1,54	10	11	13
uk	United-Kingdom	62008048	67	106	1,08	1,71	14	14	14
nl	Netherlands	16674600	18	37	1,08	2,22	11	13	15
dk	Denmark	5564219	6	10	1,08	1,8	17	17	16
ca	Canada	34480000	27	57	0,78	1,65	15	15	17
hr	Croatia	4429078	3	3	0,68	0,68	20	18	18
es	Spain	46030109	31	51	0,67	1,11	16	16	19
lt	Lithuania	3225346	2	2	0,62	0,62	28	19	20
cz	Czech Rep	10540748	6	6	0,57	0,57	21	20	21
it	Italy	60605053	33	47	0,54	0,78	23	22	22
bg	Bulgaria	7351254	4	4	0,54	0,54	25	23	23
il	Israel	7602400	4	6	0,53	0,79	24	24	24
us	USA	308745538	162	364	0,52	1,18	19	21	25
hu	Hungary	9979000	5	11	0,5	1,1	18	25	26
lv	Latvia	2245357	1	1	0,45	0,45	26	26	27
uy	Uruguay	3494382	1	2	0,29	0,57	22	27	28
jp	Japan	127960000	33	46	0,26	0,36	30	28	29
pl	Poland	38186860	9	13	0,24	0,34	29	29	30
cr	Costa Rica	4253897	1	1	0,24	0,24	31	30	31
pt	Portugal	10647763	2	4	0,19	0,38	27	32	32
sk	Slovakia	5429763	1	1	0,18	0,18	32	31	33
gr	Greece	11305118	2	3	0,18	0,27	33	38	34
ar	Argentina	40091359	7	9	0,17	0,22	34	33	35
sv	El Salvador	6134000	1	1	0,16	0,16			36
tw	Taiwan	23061689	3	3	0,13	0,13	37	34	37
br	Brazil	190732694	20	21	0,1	0,11	36	35	38
by	Belarus	9648533	1	1	0,1	0,1	35	36	39
mg	Madagascar	20653556	2	2	0,1	0,1	44	37	40
cu	Cuba	11239363	1	1	0,09	0,09		38	41
kr	South Korea	48758000	4	6	0,08	0,12	39	39	42
ec	Ecuador	14790608	1	1	0,07	0,07		40	43
cl	Chile	17224200	1	2	0,06	0,12	42	41	44
ro	Romania	21466174	1	2	0,05	0,09	45	43	45
co	Colombia	45925397	2	3	0,04	0,07	41	44	46
ru	Russia	142905200	6	7	0,04	0,05	43	42	47
za	South Africa	49991300	2	9	0,04	0,18	38	48	48
my	Malaysia	27565821	1	1	0,04	0,04			49
ve	Venezuela	29105632	1	1	0,03	0,03	40	45	50
pe	Peru	29496000	1	1	0,03	0,03	46	46	51
tr	Turkey	73722988	2	2	0,03	0,03	47	47	52
mx	Mexico	112322757	2	2	0,02	0,02	49	49	53
th	Thailand	63878267	1	2	0,02	0,03	50	50	54
eg	Egypt	80085862	1	3	0,01	0,04	51	51	55
in	India	1210193422	8	8	0,01	0,01	52	52	56
cn	China	1339724852	7	11	0,01	0,01	53	53	57
ua	Ukraine	45888000	0	0	0	0	48	53	58
			896	1450	61,79%

A few interesting facts:

• There are active DDs in 57 countries
• Martinique pops up at rank 3. As this French overseas "d partement" has its own ISO code, it is counted here separately from France, though Martinique inhabitants are French citizens. That's of course a though case but I consider that David did choose to use "MQ" in his record, which means this is important for him. Let's respect that wish.
• Norway is now ahead of New Zealand. One more DD since last count
• Sweden is ahead of Luxembourg. Two more DDs since last count
• France takes over Australia and Belgium. *seven* more DDs since last count!
• UK is ahead of Netherlands now. Three more DDs since last count.
• Denmark passes Canada and Spain (50% more DDs for DK), while Croatia passes Spain (because Spain lost 3 DDs).
• USA continues to go down (by 3 this time). We're constantly losing developers over there (-3 in one year).
• And we have a new country in this list as Malaysia now has a Debian developer. Along with Martinique (ahem), this makes two new "countries" in this list. No country disappeared.
• For the first time in 12 years, DebConf will be in a country (Bosnia and Herzegovina) that has NO Debian developer. This has to change.
• We have 23 more active Debian developers and 40 more developers overall.

v2 comment: This is the second version of this blog post. I have been pointed that the population I was using for "Ireland" is indeed the population of the entire island, so Republic of Ireland (Eire) plus Northern Ireland (Ulster). We may guess that people listing "IE" as their country are citizens of the Republic of Ireland, so the population to use is that of this part of the island. As a consequence, Ireland is bumped up to 6th rank instead of 9th. v3 comment: Doh. Since I'm doing this survey, I was always adding people using "sv" as country to Sweden. This is a quite common mistake and it was happening in the past. But now, there is only ONE developer who uses "sv" as country, this is Rene Mayorga and he definitely lives in El Salvador, not Sweden. As a consequence, Sweden lost one developer (but keeps its rank) and El Salvador now appears at rank 36. It is not a "new" country as Rene is DD for quite some time.

I am going to DebCamp11 and DebConf11. I hope I can do some productive work with the website team, as well for the DSA team. Maybe I can find someone for a little skill-exchange regarding pylons.

See comment at the end about this 2nd version This is time again for yet another bubulle game: counting the number of developers per country. I already published such analysis in 2010 and 2009. So, here we are with the June 2011 version, sorted by the ratio of *active* developers per million population for each country.

Act: number of active developers
Dev: total number of developers
A/M: number of active devels per million pop.
D/M: number of devels per million pop.
2009: rank in 2009
2010: rank in 2010
June 2011: rank now

Code	Name	Population	Act Dev	Dev	Act/Million	Dev/Million	2009	2010	June 2011
fi	Finland	5374781	21	31	3,91	5,77	1	1	1	1
ch	Switzerland	7866500	21	26	2,67	3,31	2	2	2	2
mq	Martinique	397730	1	1	2,51	2,51			3	3
no	Norway	4964500	12	15	2,42	3,02	5	4	4	4
nz	New Zealand	4393500	10	15	2,28	3,41	4	3	5	5
ie	Ireland	4470700	10	13	2,24	2,91	13	9	6	6
se	Sweden	9354462	20	36	2,14	3,85	3	6	7	7
lu	Luxemburg	511840	1	1	1,95	1,95	8	5	8	8
de	Germany	81802000	155	221	1,89	2,7	7	7	9	9
at	Austria	8404252	15	25	1,78	2,97	6	8	10	10
fr	France	63136180	91	119	1,44	1,88	12	12	11	11
au	Australia	22632213	31	57	1,37	2,52	9	10	12	12
be	Belgium	11007020	15	17	1,36	1,54	10	11	13	13
uk	United-Kingdom	62008048	67	106	1,08	1,71	14	14	14	14
nl	Netherlands	16674600	18	37	1,08	2,22	11	13	15	15
dk	Denmark	5564219	6	10	1,08	1,8	17	17	16	16
ca	Canada	34480000	27	57	0,78	1,65	15	15	17	17
hr	Croatia	4429078	3	3	0,68	0,68	20	18	18	18
es	Spain	46030109	31	51	0,67	1,11	16	16	19	19
lt	Lithuania	3225346	2	2	0,62	0,62	28	19	20	20
cz	Czech Rep	10540748	6	6	0,57	0,57	21	20	21	21
it	Italy	60605053	33	47	0,54	0,78	23	22	22	22
bg	Bulgaria	7351254	4	4	0,54	0,54	25	23	23	23
il	Israel	7602400	4	6	0,53	0,79	24	24	24	24
us	USA	308745538	162	364	0,52	1,18	19	21	25	25
hu	Hungary	9979000	5	11	0,5	1,1	18	25	26	26
lv	Latvia	2245357	1	1	0,45	0,45	26	26	27	27
uy	Uruguay	3494382	1	2	0,29	0,57	22	27	28	28
jp	Japan	127960000	33	46	0,26	0,36	30	28	29	29
pl	Poland	38186860	9	13	0,24	0,34	29	29	30	30
cr	Costa Rica	4253897	1	1	0,24	0,24	31	30	31	31
pt	Portugal	10647763	2	4	0,19	0,38	27	32	32	32
sk	Slovakia	5429763	1	1	0,18	0,18	32	31	33	33
gr	Greece	11305118	2	3	0,18	0,27	33	38	34	34
ar	Argentina	40091359	7	9	0,17	0,22	34	33	35	35
tw	Taiwan	23061689	3	3	0,13	0,13	37	34	36	36
br	Brazil	190732694	20	21	0,1	0,11	36	35	37	37
by	Belarus	9648533	1	1	0,1	0,1	35	36	38	38
mg	Madagascar	20653556	2	2	0,1	0,1	44	37	39	39
cu	Cuba	11239363	1	1	0,09	0,09		38	40	40
kr	South Korea	48758000	4	6	0,08	0,12	39	39	41	41
ec	Ecuador	14790608	1	1	0,07	0,07		40	42	42
cl	Chile	17224200	1	2	0,06	0,12	42	41	43	43
ro	Romania	21466174	1	2	0,05	0,09	45	43	44	44
co	Colombia	45925397	2	3	0,04	0,07	41	44	45	45
ru	Russia	142905200	6	7	0,04	0,05	43	42	46	46
za	South Africa	49991300	2	9	0,04	0,18	38	48	47	47
my	Malaysia	27565821	1	1	0,04	0,04			48	48
ve	Venezuela	29105632	1	1	0,03	0,03	40	45	49	49
pe	Peru	29496000	1	1	0,03	0,03	46	46	50	50
tr	Turkey	73722988	2	2	0,03	0,03	47	47	51	51
mx	Mexico	112322757	2	2	0,02	0,02	49	49	52	52
th	Thailand	63878267	1	2	0,02	0,03	50	50	53	53
eg	Egypt	80085862	1	3	0,01	0,04	51	51	54	54
in	India	1210193422	8	8	0,01	0,01	52	52	55	55
cn	China	1339724852	7	11	0,01	0,01	53	53	56	56
ua	Ukraine	45888000	0	0	0	0	48	53	57	57
			896	1450	61,79%

A few interesting facts:

• Martinique pops up at rank 3. As this French overseas "d partement" has its own ISO code, it is counted here separately from France, though Martinique inhabitants are French citizens. That's of course a though case but I consider that David did choose to use "MQ" in his record, which means this is important for him. Let's respect that wish.
• Norway is now ahead of New Zealand. One more DD since last count
• Sweden is ahead of Luxembourg. Two more DDs wince last count
• France takes over Australia and Belgium. *seven* more DDs since last count!
• UK is ahead of Netherlands now. Three more DDs since last count.
• Denmark passes Canada and Spain (50% more DDs for DK), while Croatia passes Spain (because Spain lost 3 DDs).
• USA continues to go down (by 3 this time). We're constantly losing developers over there (-3 in one year).
• And we have a new country in this list as Malaysia now has a Debian developer. Along with Martinique (ahem), this makes two new "countries" in this list. No country disappeared.
• For the first time in 12 years, DebConf will be in a country (Bosnia and Herzegovina) that has NO Debian developer. This has to change.
• We have 23 more active Debian developers and 40 more developers overall.

This is the second version of this blog post. I have been pointed that the population I was using for "Ireland" is indeed the population of the entire island, so Republic of Ireland (Eire) plus Northern Ireland (Ulster). We may guess that people listing "IE" as their country are citizens of the Republic of Ireland, so the population to use is that of this part of the island. As a consequence, Ireland is bumped up to 6th rank instead of 9th.

The DreamPlug is like a GuruPlug Server-Plus with a few notable differences:

• A separable power supply and thus none of the heating problems that plagues the GuruPlugs. My GuruPlug neither has a fan nor overheats, but other people seem to whine about these things incessantly
• Sound card with TOSLINK out
• Instead of 512 megs of NAND, it has 2 megs of SPI flash and a 2-gig microSD card inside
• It doesn't come preloaded with Debian

So let's say you want to put Debian on your DreamPlug. You do, of course, because running some other operating system is in poor taste, and you'd be embarrassed telling your friends. How do you do it? You can't use d-i. Let me back up. In the onboard SPI flash, there is a copy of Das U-Boot. This is a fork of mainline U-Boot, with no complete and corresponding source available. To the casual observer, this might look like an egregious GPL violation, but, on the other hand, no one seems to know how to rewrite the SPI flash except from U-Boot itself, so if you happen to corrupt said flash, your plug is bricked and openocd can't save you. I would be happy to be proven wrong on this last point, but for not let's assume that you're screwed and unable to replace your boot loader with free software. The next problem is the kernel, which lives on the microSD card. This is potentially free software, though I can't swear that complete and corresponding source code is available. What I can claim is that linux-2.6.33.6.tar.bz2 on Google Code will build a Linux that works on the plug. I will also point out that this doesn't match Linux 2.6.33.6 from kernel.org. Some other time I should rant about ARM Linux but for now I will just say that if you use the U-Boot of questionable provenance and either the Linux that's shipped with the plug or the one at the above link, you will be able to boot a mostly Debian system. I'll mention the third exception later. One thing you can do is to take the plug apart, remove the microSD card from its slot, and then stick it into a reader that you can then manipulate on another machine. If you're choosing this route and wish to take this opportunity to replace the microSD card with something larger than 2 gigs, keep in mind that you'll have to either preserve the uImage file from the first partition or build a new one. I am not fond of cross-architecture anything. I prefer to do things natively rather than cross-compile or foreign-debootstrap, and I own enough armel boxes that I can do this easily. So at this point I would just debootstrap a new Debian base onto the second partition of the microSD card. The first partition contains the uImage (which is your Linux image in a wrapper), and must be a FAT filesystem since you can't replace your boot loader with something that can read a better filesystem. The second partition will be your rootfs and can be whichever filesystem your Linux can read. If you do not have another armel system to play with, you might want to familiarize yourself with Marco's Sheevaplug instructions. You can install to a USB stick as well. Just remember that U-Boot needs a FAT filesystem containing the uImage on it and that you can't use a kernel in Debian yet. You'll also want to ignore the instructions regarding U-Boot, since that must be done differently. I'll be back later with some more details.

This is time again for yet another bubulle game: counting the number of developers per country. I already published such analysis in 2010 and 2009. So, here we are with the June 2011 version, sorted by the ratio of *active* developers per million population for each country.

Act: number of active developers
Dev: total number of developers
A/M: number of active devels per million pop.
D/M: number of devels per million pop.
2009: rank in 2009
2010: rank in 2010
June 2011: rank now

Code	Name	Population	Act Dev	Dev	Act/Million	Dev/Million	2009	2010	June 2011
fi	Finland	5374781	21	31	3,91	5,77	1	1	1
ch	Switzerland	7866500	21	26	2,67	3,31	2	2	2
mq	Martinique	397730	1	1	2,51	2,51			3
no	Norway	4964500	12	15	2,42	3,02	5	4	4
nz	New Zealand	4393500	10	15	2,28	3,41	4	3	5
se	Sweden	9354462	20	36	2,14	3,85	3	6	6
lu	Luxemburg	511840	1	1	1,95	1,95	8	5	7
de	Germany	81802000	155	221	1,89	2,7	7	7	8
at	Austria	8404252	15	25	1,78	2,97	6	8	9
ie	Ireland	6197100	10	13	1,61	2,1	13	9	10
fr	France	63136180	91	119	1,44	1,88	12	12	11
au	Australia	22632213	31	57	1,37	2,52	9	10	12
be	Belgium	11007020	15	17	1,36	1,54	10	11	13
uk	United-Kingdom	62008048	67	106	1,08	1,71	14	14	14
nl	Netherlands	16674600	18	37	1,08	2,22	11	13	15
dk	Denmark	5564219	6	10	1,08	1,8	17	17	16
ca	Canada	34480000	27	57	0,78	1,65	15	15	17
hr	Croatia	4429078	3	3	0,68	0,68	20	18	18
es	Spain	46030109	31	51	0,67	1,11	16	16	19
lt	Lithuania	3225346	2	2	0,62	0,62	28	19	20
cz	Czech Rep	10540748	6	6	0,57	0,57	21	20	21
it	Italy	60605053	33	47	0,54	0,78	23	22	22
bg	Bulgaria	7351254	4	4	0,54	0,54	25	23	23
il	Israel	7602400	4	6	0,53	0,79	24	24	24
us	USA	308745538	162	364	0,52	1,18	19	21	25
hu	Hungary	9979000	5	11	0,5	1,1	18	25	26
lv	Latvia	2245357	1	1	0,45	0,45	26	26	27
uy	Uruguay	3494382	1	2	0,29	0,57	22	27	28
jp	Japan	127960000	33	46	0,26	0,36	30	28	29
pl	Poland	38186860	9	13	0,24	0,34	29	29	30
cr	Costa Rica	4253897	1	1	0,24	0,24	31	30	31
pt	Portugal	10647763	2	4	0,19	0,38	27	32	32
sk	Slovakia	5429763	1	1	0,18	0,18	32	31	33
gr	Greece	11305118	2	3	0,18	0,27	33	38	34
ar	Argentina	40091359	7	9	0,17	0,22	34	33	35
tw	Taiwan	23061689	3	3	0,13	0,13	37	34	36
br	Brazil	190732694	20	21	0,1	0,11	36	35	37
by	Belarus	9648533	1	1	0,1	0,1	35	36	38
mg	Madagascar	20653556	2	2	0,1	0,1	44	37	39
cu	Cuba	11239363	1	1	0,09	0,09		38	40
kr	South Korea	48758000	4	6	0,08	0,12	39	39	41
ec	Ecuador	14790608	1	1	0,07	0,07		40	42
cl	Chile	17224200	1	2	0,06	0,12	42	41	43
ro	Romania	21466174	1	2	0,05	0,09	45	43	44
co	Colombia	45925397	2	3	0,04	0,07	41	44	45
ru	Russia	142905200	6	7	0,04	0,05	43	42	46
za	South Africa	49991300	2	9	0,04	0,18	38	48	47
my	Malaysia	27565821	1	1	0,04	0,04			48
ve	Venezuela	29105632	1	1	0,03	0,03	40	45	49
pe	Peru	29496000	1	1	0,03	0,03	46	46	50
tr	Turkey	73722988	2	2	0,03	0,03	47	47	51
mx	Mexico	112322757	2	2	0,02	0,02	49	49	52
th	Thailand	63878267	1	2	0,02	0,03	50	50	53
eg	Egypt	80085862	1	3	0,01	0,04	51	51	54
in	India	1210193422	8	8	0,01	0,01	52	52	55
cn	China	1339724852	7	11	0,01	0,01	53	53	56
ua	Ukraine	45888000	0	0	0	0	48	53	57
			896	1450	61,79%

A few interesting facts:

• Martinique pops up at rank 3. As this French overseas "d partement" has its own ISO code, it is counted here separately from France, though Martinique inhabitants are French citizens. That's of course a though case but I consider that David did choose to use "MQ" in his record, which means this is important for him. Let's respect that wish.
• Norway is now ahead of New Zealand. One more DD since last count
• Sweden is ahead of Luxembourg. Two more DDs wince last count
• France takes over Australia and Belgium. *seven* more DDs since last count!
• UK is ahead of Netherlands now. Three more DDs since last count.
• Denmark passes Canada and Spain (50% more DDs for DK), while Croatia passes Spain (because Spain lost 3 DDs).
• USA continues to go down (by 3 this time). We're constantly losing developers over there (-3 in one year).
• And we have a new country in this list as Malaysia now has a Debian developer. Along with Martinique (ahem), this makes two new "countries" in this list. No country disappeared.
• For the first time in 12 years, DebConf will be in a country (Bosnia and Herzegovina) that has NO Debian developer. This has to change.
• We have 23 more active Debian developers and 40 more developers overall.