For some time, I've had this idea brewing for how the 'net would work without DNS. Initially I was mostly thinking of how to get rid of the dark side of the registrar business, but it appears that maybe it could help with security in general too. It may not be feasible at all, or I may have forgotten extremely crucial points. I'm not a DNS guru, so bear with me and consider this as a thought experiment. This is, however, a proposal for how the Internet could be made truly decentralized, or acentric. Made so, because it currently is very centralized on at least two counts: the DNS is an inherently hierarchical structure of authority; and so is the situation with the SSL certificates used for securing websites. Let's start with DNS, if you will. Basically, the idea is to replace the current Domain Name System, which is centralised in nature (even if subdomains can be delegated) with a fully decentralised system with no central authority. The point of current DNS is to map names to IP addresses in a unique way. It currently works by registering a this name is managed by such-and-such server, ask for details at such-and-such IP address message. Of course, since there's only one namespace (or a limited number thereof, if you consider that TLDs are different namespaces), there needs to be a central authority to resolve conflicts, because some names will be more popular than others. I propose to start with a cryptographic key pair (think GPG key). Anyone can create their key pair; we assume that it's extremely unlikely for two people to generate the same keys, and that it's also very hard for two people to generate keys with the same fingerprint. By (being the only one) knowing the secret part of a key, I am the authority on what can be signed with it. I could for instance sign records that say that www points to this set of IP addresses, and smtp points to that other address. Within my area of authority, which is to say within my domain. Which is identified by the fingerprint of my key pair. What do we have so far? A mechanism that allows in a decentralised way to verify who's authoritative on the F5566852EB92BD779CF137190EA756B5144843F5 domain . In DNS terms, more probably F55...3F5.some-tld. Now let's publish the signed records on a decentralised peer-to-peer network. I'm not up to date with the latest trends in that domain, but I think something like Gnutella or Freenet would qualify, since it doesn't need central hubs but only an initial list of nodes, and it does automatic discovery of new nodes. Projects such as the FreedomBox (name likely to be changed) will probably help with that. Anyway, when looking up www.F55...3F5.some-tld, the resolver gets the signed record (and the public part of the key) from the P2P network, checks the signature, and uses the contents of the record to determine the IP address. No central or delegated registry involved at any point. Lesser risk of a single point of failure, which means better resilience against outages. Also, a better resilience against DNS-based censorship, be it promoted by non-democratic states or by greedy corporations. Of course, F5566852EB92BD779CF137190EA756B5144843F5 isn't a terribly easy name to remember or transmit. But the string of hex could be presented to the user in some other form easier to recognize for people without geek super-powers. My favourite would be the bibi-binary representation, but I'm told that the bubble-babble method works equally well. It would still be unreasonable to expect people to remember such names, and especially to type them into their web browsers or e-mail agents. A possible solution to that would be to use a short form, such as 144843F5 (or its bibi-binary equivalent), complemented by a visual representation of the full fingerprint such as the one SSH does. That pair could be displayed on business cards, email signatures, glossy brochures, advertisements and so on, and allow users to just type the strange word or flash the 2D barcode, check that the funny picture matches (in case the strange word returns several results), and get the website they want. Which they can of course bookmark under a name they can remember, probably even the same name that everyone else uses to bookmark that website. And nothing precludes convenient directories mapping names to full URLs (like search engines currently do) as long as users check that the visual representation of the site they go to matches what they've seen elsewhere. That elsewhere could, of course, take advantage of the natural web of trust that emerges in of GPG-using communities. If I'm directed at a website whose key I don't immediately recognize, then I can see who trusts that key to be legitimate (by checking the signatures), and who trusts them, and so on. Ultimately, the decision is mine to make, and mine only. In any case, once I know what URL I want to visit, I can be sure this DNS replacement will give me the right IP address (or addresses). DNS servers replying with advertisement sites instead of correct ones, and DNS-based filtering, will be things of the past. Of course, having the right IP address only solves the attacks on the DNS part. Eavesdropping can also happen by diverting traffic at the IP level. But we have a trustable way to know information related to a domain, so let's use it: the signed record can also contain the fingerprint of cryptographic keys (SSL or SSH or whatever). So we can be sure we're actually talking to the correct server, rather than to some man-in-the-middle spy. With the same guarantees of correctness as the ones for the DNS, backed by the web of trust and out-of-band validation. Again, we get rid of the hierarchy of certification authorities , some of which have been known for helping organizations get at the (supposedly secret) data people exchange over the net. To summarize: with this scheme, if I know the site I want to access is F55...3F5, then I can be certain that a) I get the right IP address for it and b) I'm actually talking to it. And nobody in-between can intercept the traffic, if the site is properly administrated and its private key is kept secure. And from the site admin's point of view, there's no need to trust DNS registrars and SSL certification authorities not to fool around with the data, or blackmail me into paying increasing fees for keeping my URL working or my SSL key certified. There's still the problem of the allocation for the IP addresses themselves, but two major parts of the centralized and hierarchical net can be gotten rid of. There are proposals attempting to fix part of the problems already, but they're incomplete. DNSSEC only solves the authentication of DNS records, not the centralisation problem. Monkeysphere aims at adding a web of trust to the SSL certificates system, but the CA chain problem seems to persist (although I must admit I'm not up to speed with the actual details). This is of course only a rough draft, full of technical considerations yet certainly not exhaustive. I've thought about it though, and I believe there are no theoretical problems with the implementation of such a scheme (apart for the handling of expiration and revocations, probably). The main obstacle to mass-adoption I can envision is the UI part, and the entrenched habit of just typing a keyword into a search engine and implicitly trusting its results, then blindly trusting the website itself; but even if mass-adoption isn't reached, I can't see anything wrong with giving those who want to be careful a more secure Internet.

Prospective Debian contributors typically follow this process:

1. Read the New Maintainers' Guide.
2. Find something they want to package.
3. Create a package.
4. Email the debian-mentors mailing list asking for someone to review the package, and if it passes review, upload it.
5. Feel increasingly lonely and sad, as the days pass without a reply on the list.
6. (Optional) Blame themselves when no one seems to care, when in fact they submitted a perfectly fine package.

Okay, so I'm exaggerating that last point. But I'm very interested in improving the culture of Debian, like I promised as follow-ups for that Debian for Shy People talk. I was talking about the email list on the #debian-mentors IRC channel. I got this vote of confidence from andrewsh:

<andrewsh> silence is bad

When there are humans involved, silence isn't always golden. So now I have a plan: Niels and I promised that any email to debian-mentors will be answered within four days. Maybe we'll say, "Sorry, we all seem to be busy!" Or maybe we'll say, "I'll try to review that next Thursday." The goal is to replace self-doubt and worry among contributors with feedback and clear expectations. (Thanks to Karen Rustad for help with editing.)

Thanks to the efforts made by Steffen, and recently the great work from Daniel(Boinc s Ubuntu maintainer, and now member of pkg-boinc team) Squeeze will have boinc 6.10.58 \o/. If you are curious you can see all changes since 6.2.14(Current version on lenny) http://packages.debian.org/changelogs/pool/main/b/boinc/current/changelog The main feature for this release is that now nvidia and ATI users can use their GPU with boinc(they need to download the non-free libs and apply some workarounds). And if you read trough here, and you are a boinc user and want to help us, please send an email to pkg-boinc-devel@lists.alioth.debian.org, we need freshblood there

A month or so ago, I published a paper with Leah Buechley that is mostly an analysis of how the LilyPad Arduino has been used. I read an earlier draft last year and loved it so, when the opportunity arose, I was honored to help out as the paper evolved. LilyPad is a microcontroller platform that Leah created a few years back and that is specifically designed to be more useful than other microcontroller platforms (like normal Arduino) in the context of crafting practices like textiles or painting. Leah's design goal with LilyPad was to create a sewable microcontroller that could be useful for making things that were qualitatively different from what most people made with microcontrollers and that, she hoped, would be of interest to women and girls. Our paper tries to measure the breadth of LilyPad's appeal and the degree to which it accomplished her goals. We used sales data from SparkFun (the largest retail source for both Arduino and LilyPad in the US) and a crowd-sourced dataset of high-visibility microcontroller projects. Our goal was to get a better sense of who it is that is using the two platforms and how these groups and their projects differ. We found evidence to support the suggestion that LilyPad is disproportionally appealing to women, as compared to Arduino (we estimated that about 9% of Arduino purchasers were female while 35% of LilyPad purchasers were). We found evidence that suggests that a very large proportion of people making high-visibility projects using LilyPad are female as compared to Arduino (65% for LilyPad, versus 2% for Arduino). Digging deeper, qualitative evidence suggests a reason. LilyPad users aren't just different. The projects they are making are different too. Although LilyPad and Arduino are the same chips and the same code, we suggest that LilyPad's design, and the way the platform is framed, leads to different types of projects that appeal to different types of people. For example, Arduino seems likely to find its way into an interaction design project or a fighting robot. LilyPad seems more likely to find its way into a smart and responsive textile. Very often, different types of people want to make these projects. Leah and I believe that there's a more general lesson to be learned about designing technologies for communities underrepresented in science, technology, engineering, and mathematics (STEM) -- and for women in particular. The dominant metaphor in the discussion on women in computer science is Margolis and Fisher's idea of "unlocking the clubhouse." The phrase provides a good description of the path that most projects aimed at broadening participation of women in computing projects seem to take. The metaphor is based around the idea that computing culture is a boys' club that is unfriendly to women. The solution is finding ways to make this club more accessible to those locked outside. It should go without saying that we share Margolis and Fisher's goal of increasing participation of women in STEM. That's LilyPad's point, after all. It it hopefully also clear that we're supportive of, and involved in, projects working to remove systematic barriers to participation by women and other groups. That work must continue. But I also think that Leah's work with LilyPad suggests another way forward based on addressing issues of self-selection that will affect even the most welcoming technological communities. Here's what we say in our paper:

Our experience suggests a different approach, one we call Building New Clubhouses. Instead of trying to fit people into existing engineering cultures, it may be more constructive to try to spark and support new cultures, to build new clubhouses. Our experiences have led us to believe that the problem is not so much that communities are prejudiced or exclusive but that they're limited in breadth--both intellectually and culturally. Some of the most revealing research in diversity in STEM found that women and other minorities don't join STEM communities not because they are intimidated or unqualified but rather because they're simply uninterested in these disciplines. One of our current research goals is thus to question traditional disciplinary boundaries and to expand disciplines to make room for more diverse interests and passions. To show, for example, that it is possible to build complex, innovative, technological artifacts that are colorful, soft, and beautiful. We want to provide alternative pathways to the rich intellectual possibilities of computation and engineering. We hope that our research shows that disciplines can grow both technically and culturally when we re-envision and re-contextualize them. When we build new clubhouses, new, surprising, and valuable things happen. As our findings on shared LilyPad projects seem to support, a new female-dominated electrical engineering/computer science community may emerge.

I have a strong belief that computing can be an empowering tool and that expanding users' control over technology is a critically important issue. Our paper argues that we should attempt to expand participation in computing by broadening the possibilities of computing, rather than only by broadening participation in extant, computing organizations, projects, and genres. Even if computing and electrical engineering communities were perfectly welcoming (which they are not) most people (both male and female, but disproportionately female) will choose not to participate. Building new clubhouses requires creativity of its proponents and risks charges of reinforcing stereotypes and existing status hierarchies. But, executed carefully and well (as I believe LilyPad has been), it suggests ways to reach the majority of people that no "unlocking" project will ever seem relevant to.

I today deactivated my Facebook account. It was some effort, because I had developed some Facebook applications, and their page to reassign them to a different developer was broken (actually the whole application edit page was broken).I have always been a "responsible" user, keeping good control over my data, and usually just posting stuff that I'd tell anyone anyway. Facebook has also always been some kind of "marketing" tool for me, being able to support some friends by inviting people to go to their events etc.However, there are plenty of reasons to abstain from Facebook:

• They track you on millions of web pages via the like button. See earlier posts on how to block some of this tracking.
• They collect tons of data on you even when you do not join, by collecting data on you via your friends email accounts, phone books etc. For example it has been shown that, when one of your friends uses Facebook for iPhone, then Facebook already has collected your phone number.
• Facebook is flooding you with information that is entertaining at first, but actually quite useless. (e.g. who became 'friends' with whom). FBpurity is a good way to remove much of the trivially useless information.
• Facebook is a huge time sink if you are not responsible, e.g. refrain from using all the games, use FBpurity to filter our cruft etc.
• Facebook is giving you the impression of having lots of friends and of being social - while in fact, you are probably even spending less time with your actual friends than ever before.
• Facebook is a great tool - for mobbing. You can easily tell things to everybody except a certain person. Invite them all to a party, but hide it from the target until its over, then brag on how great the party was. And so on - and in fact, that is what happens to non-Facebook users already; this is the kind of social pressure that made Facebook so big.
• Facebook is a lot about bragging rights. Having the most friends, the coolest photos, the best links, the prettiest girls posting on your wall.

Facebook makes things easier, but also a lot more shallow. When someone took note and remembered your birthday, there was some effort involved that shows that they cared. With Facebook reminding people to greet, what is a birthday greeting on Facebook more than an automated message? It's about as personal as the annual christmas card by some large company. Face it: the "social" part of the "social web" is pretty shallow.As you can see above, I've been caring about these issues for some time; I post selectively, I filter much of the tracking, I don't use their games. With my Hiatus, I want to further improve, in particular

• use my spare time for useful projects instead of reading trivialities posted on Facebook. There is just so much tiny stuff that you could do with your time instead.
• spend more time with my true friends
• be more self-aware of my time use in general
• remind people that they know people outside of Facebook, too

The bug webinterface of the Universal Debian Database currently knows about the following release critical bugs:

In Total:	767
Affecting Squeeze:	387
Squeeze only:	86
Remaining to be fixed in Squeeze:	301

Of these 301 bugs, the following tags are set:

Pending in Squeeze:	23
Patched in Squeeze:	41
Duplicates in Squeeze:	30
Can be fixed in a security Update:	32
Contrib or non-free in Squeeze:	10
Otherwise fixed in Squeeze:	24

Ignoring all the above (multiple tags possible), 177 bugs need to be fixed by Debian Contributors to get Debian 6.0 Squeeze released. However, with the view of the Release Managers, 232 need to be dealt with for the release to happen. Please see Interpreting the release critical bug statistics for an explanation of the different numbers.

After being noticed in blog comment about another theme for phpMyAdmin, I started to look for other hidden contributions for phpMyAdmin and I was surprised how many people did not even try to submit their code upstream. Have you ever considered trying to contact upstream? Quick search on SourceForge.net revealed: VisualMCD for phpMyAdmin

An Add-on for phpMyAdmin which enables user to create PDF Schema and Relation with a simple click and mouse moves. No more fastidious typing of table coords needed to create the PDF Schema.

Even though the SF.net history says it was released 440 days ago, it is actually dated back to 2003 and it obviously is not compatible with current code base. Also we have similar feature for few years now, so it was just duplicated effort. phpMyAdmin theme: Paradice

Paradice is a Theme for the popular web-based database administration tool phpMyAdmin. You will find the development version here. All official releases will be made by the phpMyAdmin project.

This theme is just developed externally, but you can get it from our themes page phpMyAdmin persian project

phpMyAdmin persian project

Something what seems to be dead from beginning. Anyway if you want to translate, please use our translation server. MySQL Form Generator pour PHPMyAdmin

C'est un outil pour crr un site autour d'une base. Un gnrateur de formulaire. Sur base d'une DB Mysql.Projet prvu pour tre intgr PhpMyAdmin.mysql -> formulaire HTML+javascript avec le code PHP pour trater les soumissions de donnes.

Something we still don't have in phpMyAdmin, however the project is inactive for more than year. pmahomme

Clean, modern and easy to use phpMyAdmin theme.

Theme which started this search, however it seems to fail for me right now. phpMyDesigner

Plugin for phpMyAdmin. PhpMyDesigner is a tool written in PHP and Ajax. This CASE with WEB interface. ( MySQL )

This actually does not fit into this blog, because it is one of projects that got merged and are now part of our code base. phpMySchema

phpMySchema is a tool written in PHP for generating an ERD or otherwise graphical view of your MySQL databse over the web. It is being developed to be used as a standalone script and as a module for phpMyAdmin.

Generally it looks like an interesting addition, however we can quite well compete with this after this year's GSoC, which added ability to export schema in various formats.

Filed under: Phpmyadmin 0 comments

The month is coming to an end, and I d like to recommend you some things on flattr.com :)OpenRheinRuhr Ein Pott voll Software Die OpenRheinRuhr ist eine Messe mit Kongress rund um das Thema Freie Software . Die OpenRheinRuhr 2010 findet am 13. und 14. November im Rheinischen Industriemuseum in Oberhausen statt. Freie Software ist aus Firmen, Verwaltungen, Bildungseinrichtungen und Privathaushalten nicht mehr wegzudenken. In der bev lkerungsreichsten Region Europas bietet der OpenRheinRuhr e.V. durch Ausstellungen, Vortr ge und Workshops Informationen ber Freie Software. Auch Themen jenseits der Technik, wie B rgerrechte im Netz oder die Handhabung von Lizenzen werden behandelt. Vortr ge in mehreren Tracks sprechen Menschen mit unterschiedlichem Kenntnisstand an vom Anf nger bis zum Profi. Entwickler & Projekte bekommen die Gelegenheit zum Erfahrungsaustausch. Weitere Informationen und Anmeldem glichkeiten unter: http://openrheinruhr.deBitlBee The IRC geek s solution to instant messaging. Tunnels instant messaging traffic (supporting all popular IM protocols and Twitter) to a virtual IRC channel and virtual IRC queries. Can be installed locally, but also available as a public service for people who can t/don t want to install it.
KiBi s blog This blog mainly features Debian-related posts on various topics: X.Org package maintenance (including calls for help, and status updates towards users), Debian GNU/kFreeBSD (GNU userland running on a FreeBSD kernel), and Debian s Graphical Installer (now based on X.Org). Also some upstream stuff, like the bugzilla replica type for SD (Simple Defects).
phpMyAdmin phpMyAdmin is a tool intended to handle the administration of MySQL over the Web. It can create, rename, and drop databases, create/drop/alter tables, delete/edit/add fields, execute any SQL statement, manage keys on fields, create dumps of tables and databases, export/import CSV data, and administrate one single database and multiple MySQL servers.
Debian Backports Over the last years I did numerous backports for Debian and also run backports.org. Since September 2010 we moved backports.org to backports.debian.org so its an officialDescriptions shamelessly stolen from flattr.Some words on these things:

• OpenRheinRuhr is a nice small FOSS event in my area
• I m using BitlBee every day as my main jabber client
• KiBi just rocks ;)
• phpMyAdmin is a tool I couldn t live/work without
• formi runs backports very good :) (yes, I know, he is not the only one)

Around three years ago I've migrated my stuff to Subversion from GNU Arch. Last year I migrated most important/alive things to Git. Unfortunately not all, so I still needed to host SVN server on my own. I think it's now time to get rid of it :-). In past weeks I've moved most Debian packaging stuff to some team/collab-maint repositories (being it Git or Subversion), because I really don't see need for hosting that stuff on my own. The remaining repositories are mostly historical (with single exception of StarDict dictionaries conversion tools) and nobody will probably care if they are gone. Ah and there are some dead projects as well which were never finished and will never be :-). Anyway svn.cihar.com is going to disappear soon and nobody will miss it.

Filed under: Coding Debian 0 comments

Lucas has written two long, insightful posts on the frustration about the social aspects of integrating Ruby stuff Debian The first one, on September 12 and the second one, on September 29. I cannot really blame (thoroughly) the Ruby guys for their position. After all, they have a vibrant community, and they are advancing great pieces of work. And they know who that code is meant for Fellow programmers. And yes, although it is a pain to follow their API changes (and several of the Gems I regularly use do often get refactorings and functionality enhancements which break compatibility but introduce very nice new features), they say that's solved with one of Gems' main features being the simultaneous installability of different versions. The key difference in Debian's worldview with Ruby's is they cater to Fellow programmers. Even leaving aside heaps of different positions and worldview/mindset, we have a fundamental difference: Debian cares about its users, whatever that means. So, our users should not even care what language a given application is implemented in They should only care that it works. We, as packagers, should take care of all the infrastructural stuff. And yes, that's where we find the conflicting spot: We don't want to ship many versions of a system library (that in this case would be a Gem). Specially if later versions fix known bugs in earlier versions and backports are not available or supported. Specially if upstream authors' only response to a bug in an older release will be "upgrade and rewrite whatever breaks in your application". As an example of this, I am not currently updating the gems I maintain, as Debian is on a freeze to get out the next stable release. Or if at all, I am targetting those uploads to our Experimental branch, in order not to create a huge backlog for me when the freeze is over (just a series of rebuilds targetted at unstable). And yes, I will have to be responsible for any bugs that will most likely not be supported by most of my upstreams during the next ~2 years. That's the role of a Linux distribution. And yes, as Lucas writes in the comments he got as responses to the first post This dissonance comes in no small part because the Ruby developer community is mostly made from non-linuxers. People coming from a background where (mostly propietary) applications bundle up everything they need, where static linking is more popular than dynamic libraries, where there is no coordination between parts of the system are much less likely to understand our work. And yes, the Perl community is a joy to work with in this regard. And that's the same I understand from the Python one. Because of their origins and where their main strength was grown and remains. PS - And yes, I will join the flock of people saying that... The specific person that attacked your work is a great programmer, but well known as intolerant and obnoxious. Fortunately, even if our respective cultures fail to mix so much, most of our interactions just end with a "sigh" of lack of understanding, and not with the flames you got targetted with :-/

Kevin Stone gave an interesting TED talk about the biological future of joint replacement [1]. Using stem cells and animal tissue which has been prepared to destroy the chemicals that trigger immune responses the tissues can regrow. Replacing joints with titanium and ceramic lets people walk again, regrowing them with Kevin s methods allows them to compete at the highest levels of sporting contests! Derek Sivers gave a brief and interesting TED talk advising people to keep their goals secret if they want to achieve them [2]. The Parrot AR.Drone is an interesting device [3], it s a four-propeller helicopter that is controlled by WiFi. Apparently there is little security (it binds to the first WiFi client it sees) which is a significant down-side. It returns a video feed to the controlling iPhone as it flys and can hover when it loses it s connection. It will be interesting to see when people write software for other devices (Android etc). Also I wonder whether there will be open source weapons kits for it. If you could have those devices use either a nerf gun or a lance to attack each other s turbines then you could have drone jousting. Don Marti had an interesting new idea for a crime game [4]. The main concept is to use the element of mistrust that is present in real criminal gangs. The new guy you invite to join a job might inform the police and you won t know for sure. Sometimes a heist will be discovered by the police through bad luck (or good police work) and you will wonder whether there was an informant. The aim is for a simple game design and with the complexity in email discussions between the players. The C64 isn t dead, it s even on the Internet [5], an original C64 is running a web site! Tan Li gave an interesting TED talk about a new headset to read brain-waves [6]. The device in question can be applied in minutes, requires no gel or abrasion of the scalp, connects to the computer wirelessly and is relatively cheap at $300US. The developer s kit (which I think includes a headset) is $500US. I wonder if the community can develop a cheaper version of this which is more open. Lisa Margonelli gave an interesting TED talk about the politics of oil [7]. One of her insightful points is that the subsidies for oil should be shifted from the oil industry to middle-class consumers. But she goes off track a bit by suggesting gradual oil tax increases until 2020, according to the best estimates of groups such as the CSIRO they won t need to have taxes to give a high oil price in 2020! She is aiming for a 20% reduction in petrol use by 2020, but I m not aware of any serious group of scientists who have evidence to suggest that the production capacity in 2020 will be close to 80% what it is now. Slate has a good article about The Innocence Project which uses DNA tests to overturn false convictions [8], it s scarey how badly the justice system works. Rachel Sussman gave an interesting talk about the World s Oldest Living Things [9], nothing less than 2000 years old is included. Nicholas Negroponte gave an interesting EG 2007 talk about the OLPC project [10]. While some of the content about OLPC production is a little dated the OLPC history is relevant and his personal opinions regarding the benefits that children receive from computers are insightful. Jayne Poynter gave an interesting TED talk about life in Biosphere 2 [11]. Her work on mini-biospheres is also interesting. Let s hope we get a permanent Biosphere running outside the Earth sometime soon. Sheryl WuDunn gave an informative TED talk titled Our Century s Greatest Injustice about the plight of women in most of the world [12]. Daniel Kahn Gillmor wrote a good article about the use of ssh-agent [13]. You really should use it to secure your ssh keys. Mark Shuttleworth has described the development process for the Ubuntu font [14]. This is a very interesting project and IMHO one of the most significant things that Ubuntu has done. Prior to this an entirely closed development process has been used for font development. Now we are getting a major new font family developed with a free and open process and with some new legal developments for a font license! One thing to note that this project appears to have involved a lot of work from professional font designers, it sounds like Canonical spent a significant amount of money on this project.

• [1] http://www.ted.com/talks/kevin_stone_the_bio_future_of_joint_replacement.html
• [2] http://www.ted.com/talks/derek_sivers_keep_your_goals_to_yourself.html
• [3] http://toucharcade.com/2010/09/06/parrot-ar-drone-review-the-coolest-rc-toy-ive-played-with/
• [4] http://zgp.org/~dmarti/wiki/software/better-crime-game/
• [5] http://www.c64web.com/
• [6] http://www.ted.com/talks/tan_le_a_headset_that_reads_your_brainwaves.html
• [7] http://www.ted.com/talks/lisa_margonelli_the_political_chemistry_of_oil.html
• [8] http://www.slate.com/blogs/blogs/thewrongstuff/archive/2010/08/17/reasonable-doubt-innocence-project-co-founder-peter-neufeld-on-being-wrong.aspx
• [9] http://www.ted.com/talks/rachel_sussman_the_world_s_oldest_living_things.html
• [10] http://www.ted.com/talks/lang/eng/nicholas_negroponte_on_one_laptop_per_child_two_years_on.html
• [11] http://www.ted.com/talks/lang/eng/jane_poynter_life_in_biosphere_2.html
• [12] http://www.ted.com/talks/lang/eng/sheryl_wudunn_our_century_s_greatest_injustice.html
• [13] http://debian-administration.org/users/dkg/weblog/64
• [14] http://www.markshuttleworth.com/archives/537

For quite some time, I wanted to use subkeys for signing at some places where I do not want to have my certification key stored, however I trust this location enough to have signing key available. I knew it should be possible with subkeys, however I never found time to look at it. First I needed to add new subkey which will be used for signing:

gpg --edit-key 42B7511D
> addkey

Now choose 4 (RSA for signing) and wait until new key is created. The only remaining step is to transfer subkeys to the other location:

gpg --export-secret-subkeys 42B7511D > /tmp/key-sub.gpg
scp /tmp/key-sub.gpg other.place:

Import them there and deleting any unwanted (eg. encryption) subkeys:

gpg --import key-sub.gpg
gpg --edit 42B7511D
> key 1
> delkey

And it's done ... much easier than I expected :-).

Filed under: Coding 2 comments

Many Unix daemons use a technique known as pre-forking . This means that to save the amount of time taken to fork a child process they will keep a pool of processes waiting for work to come in. When a job arrives then one of the existing processes is used and the overhead of the fork() system call is saved. I decided to write a little benchmark to see how much overhead a fork() really has. I wrote the below program (which is released under the GPL 3.0 license) to test this. It gives the performance of a fork() operation followed by a waitpid() operation in fork()s per second and also the performance of running a trivial program via system which uses /bin/sh to execute the given command. On my Thinkpad T61 with a Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz I could get 2429.85 forks per second when running Linux 2.6.32 in 64bit mode. On a Thinkpad T20 with a 500MHz P3 CPU I could get 341.74 forks per second. In both cases is seems that the number of forks per second is significantly greater than the number of real-world requests. If each request on average took one disk seek then neither system would have the fork performance as any sort of bottleneck. Also if each request took more than a couple of milliseconds of CPU time on the T7500 or 10ms of CPU time on the 500MHz P3 then the benefits of pre-forking would be very small. Finally it s worth noting that the overhead of fork() + waitpid() in a loop will not be the same as the overhead of just fork()ing off processes and calling waitpid() when there s nothing else to do. I had a brief look at some of my servers to see how many operations they perform. One busy front-end mail server has about 3,000,000 log entries in mail.log per day, that is about 35 per second. These log entries include calling SpamAssassin and Clamav, which are fairly heavy operations. The system in question averages one Intel(R) Xeon(R) CPU L5420 @ 2.50GHz core being used 24*7, I can t do a good benchmark run on that system as it s always busy but I think it s reasonable to assume for the sake of discussion that it s about the same speed as the T7500 (it may be 5* faster, but that won t change things much). At 2429 forks per second (or 0.4ms per fork/wait) if that time is entirely reduced to zero that won t make any noticeable difference to a system that has an average operation taking 1000/35= 28ms! Now if a daemon was to use fork() + system() to launch a child process (which is a really slow way of doing it) then the T7500 gets 248.51 fork()+system() operations per second with bash and 305.63 per second with dash. The P3-500 gets 24.48 with bash and 33.06 with dash. So it seems that if every log entry on my busy mail server involved using a fork()+system() operation and it was replaced to use pre-forked daemons then it might be possible to save almost 10% of the CPU time on that system in question. Now it is theoretically possible that the setup of a daemon process can take more CPU time than fork()+system(). EG a daemon could have some really complex data structures to initialise. If the structures in question were initialised in the same way for each request then a viable design would be to have the master process initialise all the data which would then be inherited by the children. The only way I can imagine for a daemon child process to take any significant amount of time on modern hardware is for it to generate a session encryption key, and there s really nothing stopping a single master process from generating several such keys in advance and then passing them to child processes as needed. In conclusion I think that the meme about pre-forking is based on hardware that was used at a time when a 500MHz 32bit system (like my ancient Thinkpad T20) was unimaginably fast and when operating systems were less efficient than a modern Linux kernel. The only corner case might be daemons which do relatively simple CPU bound operations such as serving static files from a web server where the data all fits into the system cache, but even then I expect that the benefit is a lot smaller than most people think and the number of pre-forked processes is probably best kept very low. One final thing to note is that if you compare fork()+exec() with an operation to instruct a running daemon (via Unix domain sockets perhaps) to provide access to a new child (which may be pre-forked or may be forked on demand) then you have the potential to save a moderate amount of CPU time. The initialisation of a new process has some overhead that is greater than calling fork(), and when you fork() a new process there are usually lots of data structures which are not written after that time which means that on Linux they remain as shared memory and thus reduce the system memory use (and improve cache efficiency when they are read). #include <unistd.h>
#include <stdio.h>
#include <sys/time.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <stdlib.h> #define NUM_FORKS 10000
#define NUM_SHELLS 1000 int main()

struct timeval start, end;
if(gettimeofday(&start, NULL) == -1)

fprintf(stderr, "Can't get time of day\n");
return 1;
int i = 0;
while(i < NUM_FORKS)

pid_t pid = fork();
if(pid == 0)
return 0;
if(pid > 0)

int status;
pid_t rc = waitpid(-1, &status, 0);
if(rc != pid)

fprintf(stderr, "waidpid() failed\n");
return 1;


else

fprintf(stderr, "fork() failed\n");
return 1;

i++;
if(gettimeofday(&end, NULL) == -1)

fprintf(stderr, "Can't get time of day\n");
return 1;
printf("%.2f fork()s per second\n", double(NUM_FORKS)/(double(end.tv_sec start.tv_sec) + double(end.tv_usec start.tv_usec) / 1000000.0) ); if(gettimeofday(&start, NULL) == -1)

fprintf(stderr, "Can't get time of day\n");
return 1;
i = 0;
while(i < NUM_SHELLS)

pid_t pid = fork();
if(pid == 0)

if(system("id > /dev/null") == -1)
fprintf(stderr, "system() failed\n");
return 0;

if(pid > 0)

int status;
pid_t rc = waitpid(-1, &status, 0);
if(rc != pid)

fprintf(stderr, "waidpid() failed\n");
return 1;


else

fprintf(stderr, "fork() failed\n");
return 1;

i++;
if(gettimeofday(&end, NULL) == -1)

fprintf(stderr, "Can't get time of day\n");
return 1;
printf("%.2f fork() and system() calls per second\n", double(NUM_SHELLS)/(double(end.tv_sec start.tv_sec) + double(end.tv_usec start.tv_usec) / 1000000.0) );
return 0;

Daily builds As of a month ago there are Ubuntu archives with fresh packages of Samba 4 and Openchange, built on a daily basis day from the latest upstream revision. This means that it is now possible to run a version of Samba 4 that is less than 24 hours old, without having to know how to extract source code from the version control system that upstream is using, without having to know how to build and install an application from source, but perhaps most importantly: without having to go through the tedious process of manually updating the source code and rebuilding. OpenChange is tightly coupled to Samba 4, so installing a new version of OpenChange usually involves installing a new version of Samba 4 as well. To make matters more confusing, the two projects use different version control systems (Samba 4 is in Git, while OpenChange is in Subversion) and different build systems (Samba 4 uses waf, OpenChange uses autoconf and make). I have been involved in Samba 4 and OpenChange as an upstream developer and more recently also as a packager for both Debian and Ubuntu. As an upstream developer for both these projects it is important for me that users can easily run the development versions. It makes it possible for interested users to confirm the fixes for issues they have reported and to test new features. The more users run the development version, the more confident I can be as a developer that doing a release will not cause any unexpected surprises. As a packager it is useful to know when there are upstream changes that are going to break my package with the next release.

Recipes The daily builds work using so-called recipes which describe how to build a Debian source package from a set of Bazaar branches. For example, the Samba 4 recipe looks like this:

# bzr-builder format 0.2 deb-version 4.0.0~alpha14~bzr revno ~ppa revno:packaging + revno:debian 
lp:samba
merge debian lp:~samba-team/samba/unstable
merge packaging lp:~samba-team/samba/4.0-ppa-maverick

This dictates that a source package should be built by taking the upstream Samba branch and merging the Debian packaging and some recipe-specific tweaking. The last bit on the first line indicates the version string to be used when generating a changelog entry for the daily build. Every night Launchpad (through bzr-builder) merges these branches and attempts to build the resulting source package, e-mailing me in case of build problems. Generally I fix issues that come up by committing directly to upstream VCS or to the Debian packaging branch. There is no overhead in maintaining the daily build after I've set it up. For more information on creating source package recipes, see getting started.

Toolchain The entire toolchain that does the daily package builds for Ubuntu is Free Software, and I have contributed to various bits of that toolchain over the years. It's exciting to see everything come together.

Soyuz Launchpad consists of multiple pillars - one of those pillars is Soyuz, which I hack on as part of my day job at Canonical. Soyuz is responsible for the archive management and package building. Debian source packages (a combination of upstream source code and packaging metadata) get uploaded by users and then built for various architectures on our buildfarm and published to the Ubuntu archive or to users personal package archives.

Launchpad-code Another pillar of Launchpad is Launchpad-code, which is responsible for the hosting and management of version control branches. Launchpad users can either host their branches on Launchpad directly or mirror branches (either native Bazaar branches or branches in a foreign format such as Subversion, Git or Mercurial). The mirrorring of native and foreign branches happens using standard Bazaar API's. In the case of Samba and OpenChange we import the branches of the upstream projects (Samba is in Git, OpenChange is in Subversion) and the packaging for both projects is in Bazaar. Launchad-code calls out to Bazaar to do the actual mirrorring. Over the last few years I have done a lot of work to improve Bazaars support for foreign branches, in particular on supporting Subversion, Git and Mercurial. As the code mirrorring in Launchpad is one of the biggest users of bzr-svn and bzr-git it has helped find some of the more obscure bugs in those plugins over the last few years, to the point where there are only a handful of issues with Git and Subversion imports left.

bzr-git and dulwich bzr-git provides transparent access to Git repositories from within Bazaar and is built on top of Dulwich. Dulwich is a Python library that provides access to the Git file formats and protocols that is completely independent of Bazaar. James Westby originally started it and I adopted it for bzr-git and further extended it. There are now several other projects that use it as well, including hg-git, and rabbitvcs. Apart from James and me almost two dozen other people have contributed it so far.

bzr-svn and subvertpy bzr-svn provides transparant access to Subversion repositories in Bazaar. When I grew frustrated with the existing Subversion Python bindings for various reasons, I decided to create independent Python bindings for Subversion from scratch. These bindings have since been split out into a separate project - subvertpy - and other projects have since also started using them, e.g. hgsubversion and basie.

Using the daily builds To use the Samba 4 and OpenChange daily builds (Ubuntu Maverick only for now), run:

$ apt-add-repository ppa:samba-team/ppa
$ apt-add-repository ppa:openchange/daily-builds

cp: Karnivool - Themata

For those who haven t heard: OpenOffice.org Community announces The Document Foundation

The community of volunteers developing and promoting OpenOffice.org sets up an independent Foundation to drive the further growth of the project The Internet, September 28, 2010 The community of volunteers who develop and promote OpenOffice.org, the leading free office software, announce a major change in the project s structure. After ten years successful growth with Sun Microsystems as founding and principle sponsor, the project launches an independent foundation called The Document Foundation , to fulfil the promise of independence written in the original charter. The Foundation will be the cornerstone of a new ecosystem where individuals and organisations can contribute to and benefit from the availability of a truly free office suite. It will generate increased competition and choice for the benefit of customers and drive innovation in the office suite market. From now on, the OpenOffice.org community will be known as The Document Foundation . Oracle, who acquired OpenOffice.org assets as a result of its acquisition of Sun Microsystems, has been invited to become a member of the new Foundation, and donate the brand the community has grown during the past ten years. Pending this decision, the brand LibreOffice has been chosen for the software going forward. The Document Foundation is the result of a collective effort by leading independent members of the OpenOffice.org community, including several project leads and key members of the Community Council. It will be led initially by a Steering Committee of developers and national language projects managers. The Foundation aims to lower the barrier of adoption for both users and developers, to make LibreOffice the most accessible office suite ever. The Foundation will coordinate and oversee the development of LibreOffice, which is available in beta version at the placeholder site: http://www.libreoffice.org. Developers are invited to join the project and contribute to the code in the new friendly and open environment, to shape the future of office productivity suites alongside contributors who translate, test, document, support, and promote the software. Speaking for the group of volunteers, Sophie Gautier a veteran of the community and the former maintainer of the French speaking language project has declared: We believe that the Foundation is a key step for the evolution of the free office suite, as it liberates the development of the code and the evolution of the project from the constraints represented by the commercial interests of a single company. Free software advocates around the world have the extraordinary opportunity of joining the group of founding members today, to write a completely new chapter in the history of FLOSS . [...]

So welcome The Document Foundation and LibreOffice. I already can see how does the community benefits from this due to the merge with go-oo:

Q: What does this announcement mean to other derivatives of OpenOffice.org?
A: We want The Document Foundation to be open to code contributions from as many people as possible. We are delighted to announce that the enhancements produced by the Go-OOo team will be merged into LibreOffice, effective immediately. We hope that others will follow suit.

(from http://www.documentfoundation.org/faq/) So, will Oracle contribute the OpenOffice.org trademark to the community ? Time will tell
Filed under: LibreOffice, Openoffice.org, Proud to use free software

If you're not using ssh-agent to authenticate yourself to SSH servers, you should be. (i'm assuming you're already using PubkeyAuthentication; if you're still using PasswordAuthentication, ChallengeResponseAuthentication or KbdInteractiveAuthentication, fix that please). You should use ssh-agent for a number of reasons, actually, but the simplest is this: when you authenticate to a text-based channel on a remote server, you should never have to type anything about that authentication into the channel that will eventually be controlled by the remote server. That's because a malicious server could simply accept your connection as an anonymous connection and print out the exact prompt you're expecting. Then, whatever you're typing goes into the remote server instead of into your authentication scheme. and congrats, you just gave away the passphrase for your key. With ssh-agent, you talk first to your agent. Then, you talk to the server and your ssh client talks to the agent. Your keys and your passphrase are never exposed. the second reason is that the agent is a much smaller piece of code than the ssh client, and it doesn't talk to the network at all (unless you force it to). It holds your key and never releases it to querying processes; It even runs in a protected memory space so other processes can't peek at it. So if this protected, isolated agent is what holds your key, you're in much better shape than if a non-protected, larger, network-active process (the ssh client) has direct access to your secret key material. The third reason is that it's just more convenient -- you can put a key in your agent, and ask it to prompt you when its use is requested. you don't actually need to re-type your passphrase each time. you can just hit enter or type "yes". And if that scares you security-wise then you can put the key in for a limited period of time, as well. (btw, you should be using the ssh-agent that ships with OpenSSH, probably not the implementation offered by gnome, which doesn't offer a confirmation prompt, doesn't run in protected memory space, and links in a ton more libraries) So how do you use the agent? It's probably already installed and running on your computer if you run a desktop with debian or another reasonable free operating system. Query what keys are in your agent:

0 dkg@pip:~$ ssh-add -l
The agent has no identities.
1 dkg@pip:~$ 

Add a standard OpenSSH secret key to your agent, prompting for confirmation after each use:

0 dkg@pip:~$ ssh-add -c ~/.ssh/id_rsa
Enter passphrase for /home/dkg/.ssh/id_rsa: your nice long passphrase here
Identity added: /home/dkg/.ssh/id_rsa (/home/dkg/.ssh/id_rsa)
The user must confirm each use of the key
0 dkg@pip:~$ 

(if you drop the -c, you will not be prompted at each use) Add a standard OpenSSH secret key to your agent, with a lifespan of one hour (3600 seconds)

0 dkg@pip:~$ ssh-add -t 3600 ~/.ssh/id_rsa
Enter passphrase for /home/dkg/.ssh/id_rsa: your nice long passphrase here
Identity added: /home/dkg/.ssh/id_rsa (/home/dkg/.ssh/id_rsa)
Lifetime set to 3600 seconds
0 dkg@pip:~$ 

(note that you can combine the -t $SECONDS and -c flags to get key that is time-constrained and requires a confirmation prompt at each use) Add a monkeysphere-style key (an authentication-capable subkey from your GnuPG secret keyring) to the ssh-agent (this will prompt you for your GnuPG passphrase with a graphical ssh-askpass program during this keyload, if such a program is available), for one hour:

0 dkg@pip:~$ monkeysphere subkey-to-ssh-agent -t 3600
Identity added: Daniel Kahn Gillmor <dkg@fifthhorseman.net> (Daniel Kahn Gillmor <dkg@fifthhorseman.net>)
Lifetime set to 3600 seconds
0 dkg@pip:~$ 

If you don't already have such a subkey, but you want to use the monkeysphere, you'll need to run monkeysphere gen-subkey to create one first. Note also that you can use both -c and -t $SECONDS with monkeysphere subkey-to-ssh-agent, just like they are used with ssh-add. Remove all keys from your running agent:

0 dkg@pip:~$ ssh-add -D
All identities removed.
0 dkg@pip:~$ 

I hope this is helpful to people! Tags: security, ssh, ssh-agent, tip

There are situations in which a given package needs to have different dependencies in Debian and in Ubuntu. Despite this difference it s possible to keep a single source package that will build both variants of the package. Continue reading to discover a step-by-step explanation. 1. When is that needed? While it is possible to have different dependencies depending on the distribution on which the package is built, it should be usually avoided when possible. This infrastructure should only be used as a last resort when there are no better alternatives. Here are some examples of when it might be needed:

• Ubuntu has some packages that Debian does not have (or vice-versa), and the resulting package would benefit from having them installed.
• The package names differ between Ubuntu and Debian and it s on purpose (i.e. the difference is a justified choice and not a mistake because both distributions failed to coordinate).
• The packages are built differently in both distributions, and the run time dependencies are not the same due to this. Maybe some associated patches are only applied in Ubuntu.

2. Using substitution variables in debian/control The dependency that varies between both distributions can t be hardcoded in debian/control, instead you should put a substitution variable (substvar) that will be replaced at build time by dpkg-gencontrol. You can name it $ dist:Depends for example:

[...]
Depends: bzip2, $ shlibs:Depends , $ misc:Depends , $ dist:Depends 
[...]

Note that you typically already have other substitution variables ($ shlibs:Depends comes from dpkg-shlibdeps and $ misc:Depends from debhelper and its dh_* scripts). 3. dpkg-gencontrol needs a -V option The value used to replace this new variable needs to be communicated to dpkg-gencontrol. You can use the -V option for this, the syntax would be something like this:

dpkg-gencontrol [...] -Vdist:Depends="foo (>= 2), bar"

If you use debhelper, you have to pass the option to dh_gencontrol after two dashes (--):

dh_gencontrol -- -Vdist:Depends="foo (>= 2), bar"

If you use CDBS, you can set the DEB_DH_GENCONTROL_ARGS_ALL make variable:

include /usr/share/cdbs/1/rules/debhelper.mk
DEB_DH_GENCONTROL_ARGS_ALL = -Vdist:Depends="foo (>= 2), bar"

The value given to dpkg-gencontrol is static in all those examples, now let s see how we can use give a different value depending on the distribution that we re targetting. 4. Using dpkg-vendor in debian/rules dpkg-vendor is a small tool (provided by the dpkg-dev package) that parses the /etc/dpkg/origins/default file (provided by the base-files package) to know the current distribution and its ancestry. It can be used in debian/rules to adjust the behavior depending on the current distribution. You can check its man-page to learn about the various options supported but we re only going to use --derives-from <vendor> in this sample. With this option the script exits with zero if the current distribution is or derives from the indicated distribution, or with 1 otherwise. Now combining all together, we can use dpkg-vendor to dynamically define the content of the substitution variable in debian/rules. Let s suppose that you want $ dist:Depends to be foo (>= 2) on Ubuntu (and its derivatives) and bar everywhere else. Using debhelper s 7 tiny rules file, this example could be:

ifeq ($(shell dpkg-vendor --derives-from Ubuntu && echo yes),yes)
	SUBSTVARS = -Vdist:Depends="foo (>= 2)"
else
	SUBSTVARS = -Vdist:Depends="bar"
endif
%:
	dh $@
override_dh_gencontrol:
	dh_gencontrol -- $(SUBSTVARS)

If you use CDBS, it could be this:

include /usr/share/cdbs/1/rules/debhelper.mk
ifeq ($(shell dpkg-vendor --derives-from Ubuntu && echo yes),yes)
	DEB_DH_GENCONTROL_ARGS_ALL = -Vdist:Depends="foo (>= 2)"
else
	DEB_DH_GENCONTROL_ARGS_ALL = -Vdist:Depends="bar"
endif

Do you want to read more tutorials like this one? Click here to subscribe to my free newsletter, you can opt to receive future articles by email.

9 comments Support my work

One of the nice things that I've been involved with since starting to work at ARM in Cambridge is setting up newer, faster machines to help with the armel port. We have six machines hosted in the machine room here now:

• abel is a porter box
• arnold, alain, alwyn and antheil are running buildd software
• arne is a hot spare (currently on my desk, but ready to go back in the rack any minute now)

All of these machines are Marvell DB-78x00-BP development boards, each configured with a 1GHz Feroceon processor (ARM v5t), 1.5GB of RAM and a 250GB drive attached via SATA. They're nice machines, reasonably powerful yet (as with many ARM-based machines) they draw very very little electrical power even when working hard. These very boards were used for a while by the folks at Canonical to help build the Ubuntu armel port, but now we've got them. In terms of configuration, these machines are not quite fully supported in Debian yet, though. The kernels we're using are locally-built, based on the Debian linux-source-2.6.32 package but with a .config (marvell.config) that's tweaked slightly to add the support for these boards. There aren't any source changes needed, so I'm hoping to get support added directly in Debian, either as a new kernel flavour or (preferred) as a patch to an existing flavour. I've had conflicting advice about whether the latter is possible, so I'm going to have to experiment and find out for myself. UPDATE 2010-09-28: I've tested, and it seems that the boards will need a new flavour after all, as the config is incompatible with the closest other config (kirkwood). Ah well... I had no end of trouble trying to get make-kpkg do the right thing, so on advice from Ben I built the kernel using "make deb-pkg", a standard target in the Linux kernel's build system: fakeroot make -j2 deb-pkg DEBEMAIL=93sam@debian.org DEBFULLNAME="Steve McIntyre" KDEB_PKGVERSION=buildd23 Annoyingly, that wouldn't work when cross-compiling either so I had to build the kernel natively. To make the resulting kernel image package install properly (and, just as importantly, allow for future easy upgrades for the DSA folks), I also needed the following tweaks to the Debian system:

• depmod:
  • Need to make sure that depmod is run so the new kernel can find and load modules at boot. Added trivial script in /etc/kernel/postinst.d/depmod to do this.
• initramfs-tools:
  • Needed to copy the file /etc/kernel/postinst.d/initramfs-tools into place from my amd64 machine; I'm guessing this would be there automatically on a new-enough version of initramfs-tools on the armel machines, but we're still using Lenny as a base system for now even if I'm using a Squeeze-based kernel.
• flash-kernel:
  • #594878: support for these boards. Hector did most of the work, and I've worked on it a little more.
  • #550584: kernel postinst hook script (/etc/kernel/postinst.d/zz-flash-kernel) to create uImage and uInitrd files from the kernel zImage and the initramfs.

Finally, I've tweaked the uboot config on the machines to use the uImage and uInitrd files that are generated:

Marvell>> setenv IDE ide reset
Marvell>> setenv loadkernel ext2load ide 0:1 0x2000000 /uImage
Marvell>> setenv loadinitramfs ext2load ide 0:1 0x3000000 /uInitrd
Marvell>> setenv bootboth bootm 0x2000000 0x3000000
Marvell>> setenv bootcmd setenv bootargs \$\(bootargs\)\;$(IDE)\;$(loadkernel)\;$(loadinitramfs)\;$(bootboth)
Marvell>> saveenv

And that's it, as far as I can see. I'll now wait for people to tell me what I've got wrong above... :-)

I finally found the time to port the scripts generating these statistics to use the Ultimate Debian Database (and especially its bugs webinterface). Parsing the HTML output of bts.turmzimmer.net was quite insane and slow, but it worked... kind of. However it's now done: The script now uses not that insane SQL queries and UDD, of which I have been told has more accurate numbers as bts.turmzimmer.net, which uses to the best of my knowledge the obsoleted ldap gateway. Well, so much for the talk, here are the actual numbers, created with the new script:

In Total:	799
Affecting Squeeze:	429
Squeeze only:	110
Remaining to be fixed in Squeeze:	319

Of these 319 bugs, the following tags are set:

Pending in Squeeze:	22
Patched in Squeeze:	57
Duplicates in Squeeze:	35
Can be fixed in a security Update:	12
Contrib or non-free in Squeeze:	18
Otherwise fixed in Squeeze:	40

Ignoring all the above (multiple tags possible), 193 bugs need to be fixed by Debian Contributors to get Debian 6.0 Squeeze released. However, with the view of the Release Managers, 260 need to be dealt with for the release to happen. You'll note, that the numbers got quite higher. Sorry, for that, but bts.turmzimmer.net seems to be kind of buggy :( You'll also note, that there is no longer a row for claimed and fixed in delayed bugs, as UDD doesn't support these numbers as of now. But I think you'll agree with me, that having more accurate numbers is better than having these rows.

Brian announced it on r-help and r-sig-finance and I have since updated the R/Finance website and Call for Papers page. And as David Smith already outblogged me about it, without further ado our Call for Paper for next spring's R/Finance conference:

Call for Papers: R/Finance 2011: Applied Finance with R
April 29 and 30, 2011
Chicago, IL, USA
The third annual R/Finance conference for applied finance using R will be held this spring in Chicago, IL, USA on April 29 and 30, 2011. The two-day conference will cover topics including portfolio management, time series analysis, advanced risk tools, high-performance computing, market microstructure and econometrics. All will be discussed within the context of using R as a primary tool for financial risk management, portfolio construction, and trading. One-page abstracts or complete papers (in txt or pdf format) are invited to be submitted for consideration. Academic and practitioner proposals related to R are encouraged. We welcome submissions for full talks, abbreviated "lightning talks", and for a limited number of pre-conference (longer) seminar sessions. Presenters are strongly encouraged to provide working R code to accompany the presentation/paper. Data sets should also be made public for the purposes of reproducibility (though we realize this may be limited due to contracts with data vendors). Preference may be given to presenters who have released R packages. Please send submissions to: committee at RinFinance.com. The submission deadline is February 15th, 2011. Early submissions may receive early acceptance and scheduling. Submissions will be evaluated and submitters notified via email on a rolling basis. Determination of whether a presentation will be a long presentation or a lightning talk will be made once the full list of presenters is known. R/Finance 2009 and 2010 included attendees from around the world and featured keynote presentations from prominent academics and practitioners. 2009-2010 presenters names and presentations are online at the conference website. We anticipate another exciting line-up for 2011 including keynote presentations from John Bollinger, Mebane Faber, Stefano Iacus, and Louis Kates. Additional details will be announced via the conference website as they become available. For the program committee:

Gib Bassett, Peter Carl, Dirk Eddelbuettel, Brian Peterson,
Dale Rosenthal, Jeffrey Ryan, Joshua Ulrich

So see you in Chicago in April!