If a single man can display so much hatred
think only of how much love we all can display together.

Stine Renate H heim

I wrote a Norwegian post explaining my experience at Ut ya. I had taken this blog for dead, and had entirely forgotten that it was syndicated on Planet Debian. I don t want to let Google Translate make this disaster any worse than it is the translation of bullets into balls being particularly bad so the international attention the massacre has garnered in consideration, I am writing an English translation of my experiences. I feel somehow duty-bound to make people aware of what happened, but I don t want to get into anything else but a sober description of the events and some very brief reflections. There are many details I have chosen to omit. Others have written their experiences of the events at Ut ya. I wanted to write mine down as well, and get it out there . Partly, I want to write this down because I m unsure if I will remember all the details at a later point in time, although I think I d prefer it if I couldn t. I m also writing this because people are asking about my experiences and it s much better to have an URL to give them, lest I have to keep going through the same spiel over and over again. Our former Prime Minister and current labour movement demigod Gro Harlem Brundtland had recently left the island. I had been the cameraman for a video interview of her talking about Ut ya, and I was in the media group room encoding the video into a file suitable for YouTube, when someone else in the room startled and said that Twitter was full of messages about a loud explosion in Oslo. As the newspapers brought us information about the extent of the damages, a consensus arose that an informational meeting was in order. As soon as the current round of talks finished, we were gathered into the main hall. The meeting was duly held, and after the statement was made that a TV feed would be made available, I took it upon myself as the local alpha geek to make it happen. Of course, the situation caused both the wireless network and the GPRS networks to become totally unusable. As I was waiting for someone to set up a password, I took the opportunity to face the consequences of having eaten two bits of a microwavable dish called Hold-It the local equivalent of a Hot Pocket and went to the toilet. As I was in there, I first heard agitated shouting, then screams, then gunshots coming from just outside the toilets. More than anything else, it sounded like a toy gun. I was convinced that someone was making a joke in incredibly bad taste and I stormed out of the booth with the intent of halting it. As I tore the door open, I saw two of my comrades hiding in a recessed corner. Their facial expressions left absolutely no doubt that this was no toy. They signalled for me to get back in the booth. I closed the door, did a mental double-take in utter, complete confusion, and opened it again. They were still signalling. Had they not stood there, I would have run straight into the gunman; they saved my life. I looked out into the hallway, and I made eye contact with a young boy lying in a pool of blood. He was motioning for me to help him. I heard more gunshots from inside the building and retreated back inside. As I was trying to think through my next move, I realized that the decidedly insubstantial wood-fiber door would not resist any kind of bullets. I made my way out into the hallway, with the intent of escaping outside. At that point, I was of course not aware that there was an intention to kill as many as possible, so I thought that the open spaces outside would be a place of relative safety. Of course, this proved to be wrong and my life was probably saved a second time by one of the caf volunteers taking me into a hard-to-spot employee s bathroom. We sat there for ninety minutes. Always ready to make a run for it, ready for just about anything. A peculiar group dynamic arose with these two people with whom I had barely previously spoken. We came to share a strange sense of common destiny and gallows humour. One of them had seen the shooter and described the police uniform. I perceived it to be realistic that we were the only ones aware of the wounded outside the toilet. I tried to reach the emergency services, but all their lines were busy; the terror attack in Oslo had probably clogged their lines. I finally got through to the fire services, who could inform me that the police did know about the situation and were on their way. This was to take 90 minutes and by the time we evacuated, the young boy outside my door had perished. The despair I first saw in his eyes as I passed him, fleeing from one room to the other and the empty, blank stare as we left, are burned into me and they are images I will never in my life forget. Finally, the real police arrived. We walked out. I chose the path through the minor conference hall something I now regret. The sight was simply beyond my capacity to describe fully, and so terrifying that I barely remember the sight only the terror it struck in me. There were several people bunched up in a corner, a big amorphous heap of bodies. Some were conscious and yelled at me not to do anything that could startle the police, others lay still. Their bodies were all covered in blood, and a thick pool of blood extended at least a half-metre in all directions around them. The policeman across the hall was screaming orders at me, but he was screaming so loudly that I couldn t make out his words at first. We were first moved into the camp newspaper s offices. There were about eight of us there, I think, in addition to one girl who lay wounded. Towards the end she was drifting in and out of consciousness. We covered her with sweaters to keep her warm and one of us tried to at least temper her bleeding. The bullet had missed her heart, but by the entry wound it was clear that it was not by far. I do not know who this girl was or how she is now. I sat behind and never saw her face. The wounded were evacuated first. I don t remember how long we remained; I had lost all concept of time. In spite of protests from the group who knew him, one kid was put in handcuffs. At the time I didn t understand why, and the policeman seemed to say something almost to the effect that there was no reason for it at all. I didn t see when they undid his cuffs, but I remember thinking that this treatment made a terrible experience even worse for him. I tried my best to comfort him but knew it would be little help. Later, when things stabilised a little, we were told that he was handcuffed because he had come from an unsecured area. The police was extremely good at carefully explaining what was happening and why; this was a big help and I am grateful for it. Eventually we were moved out into the main corridor of the building, where we joined up into a group of about fifty. Only when I saw the two people who saved my life did any emotion other than mild confusion arise. I broke down shivering in tears in one of their arms. After a few seconds, I came back to my senses and realised that this was not the time. I quickly gathered myself, got the shaking under control, and sat down. We were given some chocolate and soda from the kiosk. I remember making an offhand remark that an inability to find joy in free candy was a sure sign of a bad situation. We all laughed out loud. Gallows humour is a coping mechanism, but in retrospect one almost feels guilty for it. We were shown out in a single file with hands above our heads. I remember an intense concern that someone would slip in the steep, muddy slope and create a misunderstanding. Outside, there were more bodies. Some under improvised covers a tarpaulin from the waffle stand, the deflated bouncy castle but some simply lay there. Everyone I met displayed a courage, a mental discipline and unity of purpose far beyond anything one would ever wish to expect from people this young. Everyone conducted themselves with an attitude that could almost be described as stiff upper lip . Safely across the fjord we were offered blankets. I was asked if I was aware of any injuries, and asked to lift my shirt and show my abdominal region. We were shown into the bus which took us to the hotel used by the survivors and their family. I simply cannot describe in any words the relief I felt when I was able to embrace my living comrades. It was completely unlike anything I had ever felt before in my life. The euphoric feeling was tempered only by the realisation that there would be many I could never see again, comrades whom I had taken great pride in calling my friends, with futures in the service of all mankind, futures I had previously found such great joy in pondering and guessing about. The feeling which continues to upset me the most, is the feeling that so many of my comrades left behind grieving families and friends. Torn away senselessly. I do not know how much more than this relatively sober account of the events on Ut ya I can muster. I would, however, like to offer some reflections. First of all, from the bottom of my heart, I want to thank the police who saved the lives of so many still on the island, the holidaymakers who took aboard swimmers into their boats and the rescue services staffed primarily by volunteers who have spared no effort in trying to soften the blow as much as they can. The opportunity to spend time with those comrades who underwent the same experience as myself has also been an immeasurable aid. I was also so relieved to find my very closest friend among the survivors, which has also been an indescribable help. If I can name a single positive in this tragedy: Had he arrived with his automatic weapon fifteen or twenty minutes prior, he would have arrived during the informational meeting, at a time when the major hall was absolutely jam-packed the death toll would be many times what it ended up being. I am agonisingly aware of the meager comfort this provides to those who have been bereft of their closest, but I do find some solace in this. We cannot sweep under a rug that this was without question! a political attack on the labour movement. But it is thankfully also an attack which has been perceived by everyone as an attack on the Norwegian society, and on a symbol of the wide recruitment to the participatory democracy which lies at our very national soul. I cannot thank the Norwegian people, and indeed the people in other nations who have offered their condolences, enough for their shows of support and shared grief. It really has been a tremendous help to me knowing that so many people feel with us. I also want to thank from the bottom of my heart the rock-steadiness of everyone in both the national and local wings of the Labour Party and Labour Youth in supporting us, and the political milieu in general for their resolute steadfastness saving me from losing yet more that I cherish; our freedoms in a participatory democracy. Our Party has lost many of its very brightest youngsters. Personally I feel an angry spite, a deep restless urge to get the wheels of society going again. I want to show his kind that we will not be broken. We re stronger than that. I will not be frightened into silence and passivity. I want to remember the dead, and honor them by carrying on our common work. I want to end this with a request to everyone who reads this, echoing a statement I read by one of my good friends and comrades: Please, don t let me see any messages of hatred, wishes for the death penalty, anything like that. If anyone should be of the belief that anything will improve by murdering this sad little person, they would be profoundly wrong. All attention now should be plowed into caring for those victims and their relatives who did not share my luck, and not giving an audience to a perpetrator who wants one. Tore Sinding Bekkedal

Sanjog Misra, who uses Rcpp for Monte Carlo Markov Chain (MCMC) analyses in quantitative marketing, kindly set me a short example of Rcpp use. The example is based on a blog post by Darren Wilkinson which itself discusses and compares the suitability of R, Python, Java or C for MCMC analysis, using the Gibbs sampler as a concrete example. Darren's post is worth checking out: he stresses the rather pragmatic aspects of how fast and/or easy it is to write the code, rather than just the mere runtime. As such, he is not too concerned with a speed advantage of Python over R which he sees at a factor of around 2.4, leaving him to continue to prototype in R. Similarly, with C 'only' being faster than Java by a factor of two, he prefers Java for the numerically more demanding parts. We do of course advocate the use of Rcpp to combine the best aspects of R and C++, respectively. This Gibbs sampler example provides a nice backdrop. So working with Darren's example, consider the same Gibbs sampler for a bivariate distribution (and apologies for the lack of latex typesetting on my blog)

f(x,y) = k x^2 exp( -x y^2 - y^2 + 2y - 4x)

where the conditional distributions are

f(x y) = (x^2)*exp(-x*(4+y*y))               ## a Gamma density kernel
f(y x) = exp(-0.5*2*(x+1)*(y^2 - 2*y/(x+1))  ## a Gaussian kernel

Sanjog then spotted and corrected a small error in the variance expression in Darren's derivation; this is now acknowledged on Darren's website. Full details are in the R script now committed in SVN. The R code for the Gibbs sample can therefore be written as follows below. Note that this uses thinning to minimize serial correlation in the conditional densities--which renders the computation more demanding as 'N times thin' draws have to be generated:

## Here is the actual Gibbs Sampler
## This is Darren Wilkinsons R code (with the corrected variance)
## But we are returning only his columns 2 and 3 as the 1:N sequence
## is never used below
Rgibbs <- function(N,thin)  
    mat <- matrix(0,ncol=2,nrow=N)
    x <- 0
    y <- 0
    for (i in 1:N)  
        for (j in 1:thin)  
            x <- rgamma(1,3,y*y+4)
            y <- rnorm(1,1/(x+1),1/sqrt(2*(x+1)))
         
        mat[i,] <- c(x,y)
     
    mat
 

A second variant can be computed using the R bytecode compiler which appeared with the recent release of R 2.13.0 (and which we analysed in this blog post from April). This is as easy as

## We can also try the R compiler on this R function
RCgibbs <- cmpfun(Rgibbs)

Thanks to Rcpp and the inline package, we can also write a C++ variant that can be built and launched from R with ease. The C++ code is assigned to an R text variable gibbscode. (And we used to typeset such code on the blog as a character string, ie in a faint red color---but have now switched to highlight it as if it were freestanding C++ code. It really is passed as a single string to R which then uses the cxxfunction() to compile, link and load a C++ function built around the code. See previous posts on the inline package for more.)

## Now for the Rcpp version -- Notice how easy it is to code up!
gibbscode <- '

  using namespace Rcpp;   // inline does that for us already
  // n and thin are SEXPs which the Rcpp::as function maps to C++ vars
  int N   = as<int>(n);
  int thn = as<int>(thin);
  int i,j;
  NumericMatrix mat(N, 2);
  RNGScope scope;         // Initialize Random number generator
  // The rest of the code follows the R version
  double x=0, y=0;
  for (i=0; i<N; i++)  
    for (j=0; j<thn; j++)  
      x = ::Rf_rgamma(3.0,1.0/(y*y+4));
      y = ::Rf_rnorm(1.0/(x+1),1.0/sqrt(2*x+2));
     
    mat(i,0) = x;
    mat(i,1) = y;
   
  return mat;             // Return to R
'
# Compile and Load
RcppGibbs <- cxxfunction(signature(n="int", thin = "int"),
                         gibbscode, plugin="Rcpp")

It is noteworthy how the code logic is essentially identical between the basic R version, and the C++ version. Two nested loops control draws of x from a Gamma distribution, conditional on y, as well as draws of y from a Normal, conditional on x. Add a small amount of parameter passing to obtain the parameters N and thin, allocation of a results matrix and setup of the random number generator state to remain consistent with R, as well as a return of the matrix---and that is all. As Darren's code uses the GNU GSL in its C variant, I also became interested in seeing how a C/C++ hybrid variant using our RcppGSL package would fare. The code is below.

gslgibbsincl <- '
  #include <gsl/gsl_rng.h>
  #include <gsl/gsl_randist.h>
  using namespace Rcpp;  // just to be explicit
'
gslgibbscode <- '
  int N = as<int>(ns);
  int thin = as<int>(thns);
  int i, j;
  gsl_rng *r = gsl_rng_alloc(gsl_rng_mt19937);
  double x=0, y=0;
  NumericMatrix mat(N, 2);
  for (i=0; i<N; i++)  
    for (j=0; j<thin; j++)  
      x = gsl_ran_gamma(r,3.0,1.0/(y*y+4));
      y = 1.0/(x+1)+gsl_ran_gaussian(r,1.0/sqrt(2*x+2));
     
    mat(i,0) = x;
    mat(i,1) = y;
   
  gsl_rng_free(r);
  return mat;           // Return to R
'
## Compile and Load
GSLGibbs <- cxxfunction(signature(ns="int", thns = "int"),
                        body=gslgibbscode, includes=gslgibbsincl,
                        plugin="RcppGSL")

This code is similar to the version using just Rcpp, but we need to allocate space for the GSL random generator object (and later release that memory allocation), and we do of course call the GSL functions. This also necessitates declaring the function using the two header files listed as arguments for the include argument of cxxfunction(). So how is the performance? The script (now committed in Rcpp's SVN repo as examples/RcppGibbs/RcppGibbs.R, and also part of the next release) creates the output below when running in non-interactive mode (whereas interactive mode creates a few charts too):

edd@max:~/svn/rcpp/pkg/Rcpp/inst/examples/RcppGibbs$ r RcppGibbs.R
Replication # 1 complete 
Replication # 2 complete 
Replication # 3 complete 
Replication # 4 complete 
                    N=1000 N=5000 N=10000 N=20000
Elasped Time (R)     0.124  2.650  10.511  41.773
Elasped Time (RC)    0.081  1.916   7.594  30.280
Elapsed Time (Rcpp)  0.003  0.076   0.306   1.221
Elapsed Time (Rgsl)  0.002  0.049   0.196   0.784
SpeedUp Rcomp.       1.530  1.380   1.380   1.380
SpeedUp Rcpp        41.330 34.870  34.350  34.210
SpeedUp GSL         62.000 54.080  53.630  53.280
               test replications elapsed  relative user.self sys.self
4  GSLGibbs(N, thn)           10   7.845  1.000000      7.84        0
3 RcppGibbs(N, thn)           10  12.218  1.557425     12.22        0
2   RCgibbs(N, thn)           10 312.296 39.808286    311.98        0
1    Rgibbs(N, thn)           10 420.953 53.658764    420.59        0

The first block is a hand-computed comparison using four sets of parameters; the second block uses the excellent rbenchmark package to compare ten runs at twenty-thousand draws. We see a nominal increase in performance due to the bytecode compiler, saving roughly 38 percent which seems appropriate given that the R code mostly controls the loops; actual work in undertaken in the already compiled RNG functions. The Rcpp variant is about 34 times faster than the pure R code. Sanjog reported higher increases on his OS X machines (and Darren's post echos a similar order of magnitude). However, on my i7 running Linux I always obtained an improvement in the mid- to high thirties. That is certainly already a rather pleasant result. What surprised and stunned me at first was that the GSL solution scores an improvement of around 53 times (close to the factor of 60 reported by Darren). A closer look at the code (shown above) makes it clear that there are very few compute-intensive operations outside of the RNG draws. I validated this further with a second study timing just one million draws each from a Gaussian and Gamma using R via Rcpp, and using the GSL. It turns out that the R code is about 2.5 times slower for random draws from the Gamma distribution than the GSL. Inspection of the source code---in files src/nmath/rgamma.c for R and randist/gamma.c for the GSL shows why. R uses a much more complex (and presumably more precise) algorithm. I may follow up with Martin Maechler to see if we can illustrative the numerical benefits of this more expensive approach---this blog entry is getting long enough already. So to sum up: Gibbs sampling is a somewhat resource-heavy Monte Carlo Markov Chain method for investigating multivariate distributions. R excels at quick and simple explorations, albeit at somewhat slower execution speed. The Rcpp package can help by providing easy means to accelerate simulations by a significant factor. The example discussed here is now in SVN repository for Rcpp and will be part of the next release.

Updated 2011-07-16: Darren has just updated his comparison; fixed two typos here too.

Squashing release critical (RC) bugs is one of the most helpful way to contribute to Debian. Because those are the bugs that we need to get rid of in order to release the next stable version. Let s see how you can help. The process is really simple:

1. Find a RC bug that you can fix
2. Prepare a fixed package
3. Send the patch to the BTS
4. Get your fixed package uploaded

I have already covered points 2 and 3 in a former article: How to prepare patches for Debian packages. So I m not going to repeat myself in this article, instead I ll cover how to find a release critical bug to fix and how to get your package uploaded. Find a RC bug with UDD The Ultimate Debian Database (UDD) provides a neat interface to query the bug tracking system: http://udd.debian.org/bugs.cgi. The form contains many options to customize the query, we ll try explain some. First, at the top, you can decide to list bugs based on whether or not they affect testing/stable/unstable. Indeed, thanks to version tracking the BTS knows if a bug applies to the version of the package present in a given distribution. I suggest you pick a choice that includes sid because that s where you re going to push your fixed package. If sid is not affected by the bug, you can t do much about it (except if you want to join the release team and help ensure updates are flowing from unstable to testing). I usually go for wheezy and sid because that filters out packages which are not in testing (and are thus not blocking the next release). Then you have lots of filters to further reduce the list of bugs. It s important to reduce the noise as you typically have several hundreds of RC bugs at a given time. I suggest you the following settings for a start, but you re free to try other combinations depending on what you want to achieve (I ll give some examples later):

• ignore bugs tagged patch (a fix is already available);
• ignore bugs tagged pending (a fix has already been committed to the VCS repository);
• ignore bugs newer than 7 days (that s the time we should leave for the maintainer to take care of the bug by himself);

I usually sort the results by source package so that I immediately see if several RC bugs are affecting the source package. And I might add popularity contest information to get a feel of whether the package is widely used or not. You can see the results of the suggested query here. Other interesting queries:

• List of RC bugs blocking the migration of their package (i.e. affecting unstable but not testing, with different version in both distributions).
• List of RC bugs on packages that you can adopt (i.e. bugs affecting any distribution but on orphaned packages, sorted by decreasing popularity).

Find a RC bug with rc-alert The downside of the above method is that you get bugs on packages that you don t know at all and that you might not care about. Some of them might even be better removed instead of fixed. With the rc-alert command (provided by the devscripts package), you will get a list of RC bugs
on packages that are installed on your computer. It should be much more restrictive. And you have command line options to further filter the list just like with the UDD form. Bonus feature: you can also filter by debtags allowing you to restrict the bugs to packages which are implemented in programming languages that you know.

$ rc-alert --include-dists TU --exclude-tags P+ --debtags implemented-in::perl,implemented-in::python
Package: gwibber
Bug:     608724
Title:   gwibber bypasses certificate checking when providing the login/password for OAuth
Flags:   [     S  ] (security)
Dists:   [STU] (stable, testing, unstable)
Debtags: implemented-in::python, interface::x11, role::program, uitoolkit::gtk, works-with::im, x11::application
[...]

Get your fixed package uploaded Usually sending the patch to the BTS is more than enough. The maintainer or another Debian developer will pick it up at some point. But if you re interested in becoming a Debian maintainer/developer, it might be worth to push your changes more quickly and get credited by a proper upload with your name. Instead of just preparing a patch, you should also prepare a fixed package following the rules of a Non-Maintainer Upload. Put this package somewhere online (for example on mentors.debian.net). When you send your patch to the BTS, include the link to the updated package and express your wish to get this update sponsored. If you haven t heard anything from the maintainer after 2-3 days, try to find a sponsor on debian-mentors@lists.debian.org. NMUs are easier to review than completely new packages and many Debian developers like to kill RC bugs, so there s a good chance that you ll find someone. Now happy RC bug-squashing! And if you really enjoy it, you can subscribe to debian-bugs-rc (~3000 mails per month)

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.

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

I ve taken the plunge, and converted my blog from a venerable but largely unmaintain(ed able) blosxom setup that I ve had since 2005 (OMG!) into a new and shiny Jekyll-backed system. The main benefits are that I m more comfortable hacking away at Jekyll (being written in Ruby), and my blog post submission no longer requires me to e-mail my blog posts to myself to put them up (that was just an artifact of how I set it up all those years ago, but it had worked so I wasn t willing to change it just for the sake of it). Jekyll s superior (for me) hackability has reaped dividends already I ve put together a home-grown comments system, which fulfils my primary requirements of being as close to completely statically-generated as it s possible to be (about 10 lines of PHP is the only dynamic content), and doesn t involve JavaScript or putting my blog comments in the cloud .

Unfortunately, GLabels is currently unmaintained. Still, it's a very convenient tool, IMHO to print DIY business cards. Here's my glabels business card file, for those interested to borrow and reuse it.

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.

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.

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.

It s been a few months since Zack and I announced the DEX project, which aims to improve the Debian ecosystem by working jointly with derivative distributions. Our first milestone The goal of our first project, nicknamed ancient-patches, was to clear out an old batch of a few hundred Ubuntu patches whose status was unclear. We couldn t tell which ones had been merged into Debian, which were waiting in the BTS, and which had yet to be submitted to Debian. All of them were several years old. I m pleased to announce that this project is now complete. Thanks to help from David Paleino, Colin Watson, Nathan Handler and Steve Langasek, we were able to clear over 95% of the patches in a matter of days. These were the easy ones: patches which were obsolete, or had already been applied. We discussed the remainder, and resolved all of the patches whose status was still unclear. This left the harder ones: patches stalled in the BTS, and patches where there was no consensus about what to do with them. One of the stalled patches was merged into Debian via an NMU, eliminating the delta between Debian and Ubuntu. Another had been submitted to Debian by a third party, but was no longer shipping in Ubuntu, so we considered it obsolete for purposes of this project. This has left only two patches out of the original list of 277. Both of them are filed in the BTS and have been discussed with the relevant maintainer team. One of them is expected to be obsoleted when a new upstream version is packaged, which implements similar functionality. The other is being discussed with the upstream developers, but there is no conclusion yet about whether it can be merged upstream or in Debian. Conclusions Although we weren t quite able to clear the whole list, we still consider the project to be a success because:

• We ensured that all of the patches received due consideration for inclusion in Debian
• We proved the concept of DEX, with developers from Debian and derivatives cooperating on a common goal and sharing tools
• Most importantly, we learned from the experience

What s next In the most recent DEX update on debian-derivatives, I highlighted a few important events for DEX:

• Our second major project, nicknamed big-merges , will begin soon. Our goal is to identify the few packages which are most diverged between Debian and Ubuntu, and work to get them as close to identical as possible. If you have suggestions for packages to focus on, let us know!
• Allison Randal is beginning a DEX project to implement the Python 2.7 transition across Debian and Ubuntu
• Nathan Handler is working on a Summer of Code project to develop specialized tools to help with this kind of cross-distribution teamwork
• Zack is organizing a derivatives BoF at DebConf 11

We re looking forward to seeing DEX develop further. If you d like to get involved, come and join us on the debian-derivatives mailing list or IRC (#debian-derivatives on freenodeOFTC). Matt Zimmerman and Stefano Zacchiroli

The BitTorrent protocol works with trackers, that track the clients or peers that share a given file. This is one specific design of a peer-to-peer protocol, very appropriate for official distribution: for instance, Debian runs a tracker for distributing the installation images.The problem There exists many BitTorrent clients, but, for what I have seen, few BitTorrent tracker. Within Debian, I think the only trackers available are the original BitTorrent's one, and its fork BitTornado. Both suffer from serious drawbacks:

• they have been unmaintained (upstream) for years;
• they provide both a tracker and a client in the same package, whereas a BitTorrent client and a tracker do not have much in common, and most people are only interested in the client, so the package maintainer had to completely disable the tracker daemon, which complicates the task to get a working tracker;
• the tracker's logging simply sucks: they had the brilliant idea to bufferize their log, with what seems no buffer control at all, so you get half-written lines, that get complete half an hour later, and so on.

Proposed solution Now that I have criticized a lot, let us be more constructive. All these issues could be fixed by modifying the code and the package (well, by adopting it, for the first one). I think it is not worth doing so, exactly because they implement both a client and a tracker: there are many good BitTorrent clients so there is no real need for them as clients, and because a tracker's job is quite different, and easier than a client's, it would be useless to maintain a client with the tracker. So, I am considering coding a BitTorrent tracker. Even though the tracker protocol is based on HTTP, it is completely stateful so it would be a standalone daemon rather than a CGI-style program. I would code it in Python because this is the language I currently prefer, and I may call it tbtt (the BitTorrent tracker, or Tanguy's BitTorrent tracker, or transport blind tout terrain (all terrain armoured transport)). If you have any information or suggestion, please comment! Perhaps I missed some existing tracker that would do the job instead of coding a new one?