Martín Ferrari: DebConf, travelling, pictures, SoC... Oh my!
I'm still lacking the obligatory post-DebConf7 post... These weeks had been intense...
So, first of all, thanks to all the DC-team for another wonderful conference. Next year I'll feel how it's done one of the two things that everybody likes but nobody wants to know how it's done. Hint: not sausages.
This is the first time I've also attended DebCamp, and it was very useful. Not that I could do any real work, as very few people are able to do that during DebConf, but I managed to do what I planned, that is talk with many people who are working on debian-cd, debian-installer and custom-cdds.
I've already uploaded my pictures to a temporary place, whitout captions, until I decide how I will replace the stinko called gallery. And there you can see that I was one of the few that actually wore a kilt during the event —not a proper Debian kilt, but hey...
After DebConf, and after a year of hard work, I took a seven days vacation in the UK. So I was able to know Edinburgh (I prefer to hang out with Debian people that doing tourism during the conference, so I only knew the way to the supermarket). I also went to the Arthur's Seat HIll, which was very beautiful, and was only a 1-hour walk from the hostel to the top. Then I did a small visit to Stirling and concluded that castles in Scotland are not that interesting (but go to the Smith Museum!).
Then, I went to London for a couple of days (dang, that was expensive!!), visited Marx's tomb, rided near the car bombs, got to know all the nice stuff that the british stole from around the world in the British Museum (it's really great, and free), and went to Cambridge to spend a day (and punting, I even did the punting myself!). Finally I spent my last day walking around that beatiful city, in the Soho and South Bank areas. I don't want to forget to say thanks to Nattie, Kai and Ben for hosting me, you guys rock!!
This last week has been very productive. I was working GSoC project, trying to recover from lateness, and staying until late. It was worth it, I have finished settling down the architecture and overall design, and wrote the main program which will coordinate all the tests to be run. It includes from the begining dependency-based scheduling and paralellism, so I hope it will scale well in SMP computers. I also wrote a draft specification for the plugins and description of the running plan in the wiki page.
I've also asked for the creation of a Alioth's project, so I can start publishing the code, and get feedback from the people that will use it.

So, we did manage to have some pancakes to celebrate Debian’s Big 10 (Social Contract) anniversary, though albeit, they are not your
This graph shows the percentage of the total download that used HTTP
from a mirror. The optimal line shows the minimum possible (i.e. all
peers are connected), which corresponds to only one copy (the first)
of every package being downloaded using HTTP.
This verifies my previous thinking, which is that fracturing the
download population into multiple small swarms results in lots of
inefficiencies, and lots of HTTP downloading. All efforts will need
to be taken to keep the downloading populations together. (This is
especially difficult for unstable, when a new swarm could be created
twice a day due to archive updates.) Swarms of 1,000 peers or more
seem to be sufficient to minimize the HTTP downloading.
This graph shows the amount of unnecessary HTTP downloading that
occurred, which is just the difference of each line from the optimal
one in the previous plot. This shows the danger of selective
downloading, as all of this unnecessary HTTP downloading occurs
because the swarm is too big to find peers that have the desired
package (they do exist). Fortunately, this unnecessary downloading
seems to approach a maximum as the swarm size increases.
For the large swarm sizes needed to make the downloading efficient,
and assuming a reasonable number of connections of 100 (bittorrent
defaults to maintaining at least 40, and large swarms usually means
a large number of connections), we can expect to be using HTTP for
about 4% of the download. This number is surprisingly low due to the
popularity distribution of packages (only rare ones are hard to
find, but they aren't downloaded very often). I think 4% is
manageable in our situation, given that there is a backup method to
find the rare packages, though it does show the need to have that
backup method available. This is probably more of a problem for
regular bittorrent clients, in which there is no backup method.
The store served a general, non-technical audience. DRM-FREE, it turns
out, is a good way to sell music. Not just to geeks but to any consumer
who has been stymied unfairly by DRM or knows someone who has. That, it
turns out, is a whole lot people. Consumers know what DRM is and they
know don't like it.
As consumers learn more about DRM, they want to avoid it. Seeing this,
the companies that produce DRM are looking for ways to escape.