While I have been a little quiet with ftpmaster posts lately - I am still alive. I just had some other bits to do and didn’t get large enough changes done that would warrant an own post. Since my last post earlier this months there have only been 3 notable changes, namely

• fixing a bug in the transitions feature. Or better - working around one in python-syck which was inserting random “—” when it dumped a data structure. Which does break stuff.
• Changed the Maintainers name of the ftp.debian.org pseudopackage.
• Merged a little branch from Frans that enables automated byhand processing for the tasksel data.
• Started the last discussion on the data section/archive/component thingie and will end that soon with an implementation.

And only a few minutes ago I sent a “Bits from” mail to our debian-devel-announce mailinglist, which includes a summary of the recent activities and changes in our team, with the addition of Thomas and Kalle, me getting FTPMaster and Anthony and James resigning. We also ask for volunteers which we might add to the team later on. See, I write might. We keep the right to reject people, for whatever reason. Hopefully there won’t be many rejects, but still. And we will see how the volunteers get the tasks done we plan to assign to them. You can expect to see a little more in the near future from me again, I don’t plan on staying that quiet forever.

---

And in other news - I recently got another group added, mirroradm, as it did help to fix some mirror issues with packages.debian.org. With that I also got the mirrors@ alias additionally routed into my INBOX. Thats a nicely spammed role address and my tip for you, if you should ever get offered access to (any) role address - run as fast as you can, unless you have very good spam filters! :) Luckily my filters are pretty good, as I’m on a good number of role addresses for a long time already, only a few dozen spams getting through a day (and a thousand filtered away). Comments: 0

Michelle’s post‡ today on laptops in the classroom (in a similar vein to this article I read last month on the suggestion of Glenn Reynolds) reminded me that I had a few items from the past few weeks still in my Google Reader queue of “things to blog about” related to Margaret Soltan’s continuing crusade against the use of PowerPoint* and its ilk, and specifically Timothy Burke’s partial rebuttal:

What’s the difference between bad usage of PowerPoint in lectures and bad lectures that involve hand-outs, overhead transparencies and writing on the chalkboard? Are we just complaining about old wine in new bottles here? Is the real culprit professorial droning at classrooms of 200+ students followed by recite-repeat-and-forget examinations? I think it’s at least plausible that the technology is just giving us a new reason to pay attention to a pedagogy whose effectiveness has been suspect for two generations.

I dare say I’m among the last doctoral students who was “trained”—and I use that word loosely—to teach prior to the widespread use of PowerPoint. Four years of full-time in-classroom experience, mostly with small lectures and seminars, has brought me basically to agreement with Burke on this point—complaints about PowerPoint essentially boil down to complaints about either instructional laziness or the whole nature of lecturing, or as a Burke commenter puts it, ”[e]xactly how does one teach even 80† students at once without succumbing to passive data transfer?” The non-use of PowerPoint or some other form of instructional technology seems to me to be a luxury confined to those who only teach small seminars and graduate students, and while my personal career aspirations lean in that direction the reality is that I’m several years away (in terms of research productivity) from being there—if I ever get there. Burke in his comments hits the nail on the head, I think, when it comes to any sort of visual presentation in class:

It seems to me that the absolutely key thing is to avoid speaking the slides literally. They’re best as definitions, key concepts, images: the kind of thing you’d stop your flow of lecturing to write on the chalkboard. They’re not the lecture itself.

I think there are three useful aspects to a lecture: what you put on the board (or slides), what you say, and the general outline. If you’re preparing a handout or something to stick on Blackboard for students, the outline or outline-plus-slides is what they need, along with space to fill in the gaps. An alternative approach is to make the slides/board material the outline; several of the more effective teachers I had (my high school history teacher and a political science professor at Rose-Hulman) took that approach. But you can’t shovel your script into PowerPoint and expect that to work well, any more than you’d expect that writing it up on the board, or for that matter reading a paper verbatim at a conference would be a good presentation, to work. All this discussion leaves aside the question of teaching anything that involves symbols (chemistry, mathematics, statistics) which I think requires a different approach than bullet-points. In class, mathematics and statistics (and, by extension, social science research methods courses) lend themselves to a combination of “passive” PowerPoint-style presentation and more spontaneous problem-solving and brainstorming; for example, one of my early activities is to have the class try to operationalize (define in terms of a measurable quantity or quality) a concept like “globalization,” which you can’t really do with a static slideshow even though you can define terms like “operationalization” that way. Similarly, while you can step through the process of solving a problem in a slideshow I think it’s more effective to demonstrate how to step through the process on the board. Unfortunately, many classrooms aren’t set up to allow you to present and use a board simultaneously; some of TAMIU‘s lecture halls have a nice design where the projection screen is above the board, so you can write on the board without having to do anything special with the slideshow, but rooms most places are designed for “either-or” which can be a real pain—fiddle with the control system to blank the screen, raise the screen, write on the board, then lower the screen, switch the screen back on. After a few iterations of that in a single class, you’ll never do it again. I freely admit I haven’t figured everything out yet; my current methods slides are pretty good lecture notes but pretty rotten for projection. One of my projects for this summer (postponed from last summer after I learned I wouldn’t be teaching any methods courses this year) is to work on my research methods lectures to incorporate advice from Andrew Gelman’s book so I can lay the groundwork for my plot to take over the world effort to produce a workable, but rigorous, methods curriculum at both the undergraduate and master’s levels for political science, sociology, and (at the grad level) public administration. More on this theme from Laura at 11D, who takes note of some of the more positive technological developments associated with academe. And, another of Burke’s commenters links this hilarious example of what not to do with your slides.

* I use “PowerPoint” as shorthand for the use of a computer-projector based slideshow-style sequential presentation of items associated with a lecture, a technique obviously made famous by the Microsoft software package but also available with many other software packages such as Apple’s Keynote, OpenOffice.org Impress, and several PDF viewers including Adobe Reader, xpdf, and GNOME‘s Evince.
† I’d put the cutoff significantly lower, at around 30–40 students. Beyond that point, one might as well just blow the cap off the class.
‡ By the way, it’s nice to see Michelle’s blog back from haïtus! (Where else would I keep up with current Mexican politics?)

I was at two geek events in Zurich this week: At the Google Open Source Jam Zurich on Thursday evening and at the first Webtuesday Hackday on Saturday. Somehow I expected both events to be quite similar, but they weren’t. Google Open Source Jam When I read “Jam” or “Jam Session” I think of Jazz musicians spontaneously playing together. So for me “Open Source Jam” sounded like a hack session where some spontaneous coding is done. But there was no spontaneous collaboration at Open Source Jam at all. It’s just (more or less spontaneous) talks about different topics and chatting. So I was quite disappointed from that event. There were though quite a lot of people I knew from e.g. Webtuesday, Chaostreff or Debian. I even met some people I just knew from IRC until then. Half of the talks were sole propaganda talks though, e.g. for Webtuesday Hackday, OpenExpo and Soaring as a geek sport. Not really wrongly placed talks, but not what I expected in talks at Open Source Jam. The few rooms and floors I saw reminded me very much to IKEA Children’s Paradies, just even more motley. Though it felt all sterile and wasn’t by far as cool as I expected after what I read elsewhere of Google offices. I also think that several of the Google employees showed some contrived friendlyness, and questions I asked e.g. why I have to give them my e-mail address and employer’s name (what do unemployed or self-employed people do?) got answered with answers I do not really believe – like “for security”. A leopard doesn’t change its spots. A data squid probably neither, even not at events labeled with OSS and said to be for the community. I suspect that finding new employees is one of the reasons behind such events at Google. But after my first visit at one of their locations, this company still makes me feel uncomfortable. And I’m even more sure than before that I wouldn’t want to work there. Not sure if I’ll attend the Google Open Source Jam a second time. Webtuesday Hackday Webtuesday Hackday also was not as I expected, but still more close to my expectations: the Webtuesday crowd gathers for hacking instead of having long talks. :-) There were surprisingly many people from outside Zurich, from Munich and Belgium, from Lake Constance and Lausaunne – not only the usual suspects (who were there anyway ;-). The event took place at Liip’s new office. They still look a little bit empty and steril, but all the toys (mini rugby balls, Wii, plush figures on floor lamps) and people around made them very alive. And they had very cool lamps in the form of their company logo in the office. They sure have a good interior designer. :-) Although most participants found time to do some hacking, many found less time than they expected so we hope that we can glue the talks a little bit more together in regards of timing to cause less interruptions of the hacking. The food was also better at Hackday, too, but mostly because we ate outside. ;-) For lunch we were at Lily’s Stomach Supply at Langstrasse (very recommendable!) and in 6he evening we were at Pizzeria Grottino 79 near Helvetiaplatz. Had a Pizza Vesuvio with Gruyère cheese there. Hackday also had a surprise for me: The IRC channel at Hackday was but when I entered the channel there were someone in I didn’t expect there: tklauser aka Tobias Klauser aka tuxedo. Even more surprising, he read about my project idea for Hackday – a semantic feed cache proxy – and liked it, so he decided to come over to Zurich and join the project. We didn’t came that far until Tobias had to leave again, but the progamming language and partially also libraries had been nailed: Ruby and it’s WEBrick framework. After the Hackday I worked on it a few more hours and it now already saves feeds to a cache. The Mercurial repository is at http://noone.org/hg/sfc-proxy. There were several reasons which spoke for using Ruby instead of Perl (my favourite progamming language and the one I’m most experienced in): Ruby brings HTTP and RSS support already in it’s standard classes and Tobias is more experienced in Ruby than Perl. I started to learn Ruby a few years ago to look beyond my own nose and to get my hands dirty on some object-oriented and nice programming language, but I hadn’t found an appropriate project until now, so this was one more reason to not do it in Perl. I also worked on my Debian package of Conkeror during Hackday. It’s already usable and I now use Conkeror as primary web browser on my EeePC, but e.g. the man page is still missing. As soon as I have the minimum in necessary documentation ready I’ll let it upload to Debian Experimental (since its dependency XULRunner 1.9 is also only in Debian Experimental yet). The Mercurial repository for the Debian packaging of Conkeror is at http://noone.org/hg/conkeror/debian Those who were still at Hackday in the evening decided that the Webtuesday Hackday should become a regular institution and should take place approximately every two months, but stay a one day event (for now). I already look forward to the next Webtuesday Hackday.

This week I've been at UDS in Prague, and looking at some possible ways to deploy bzr for packaging (which is a hot topic: developers don't want to change workflows without a concrete benefit, and definitely don't want to pay a cost for doing so - e.g. having to have all of history locally just to make a trivial change). One of the discussions inspired a scalability test for bzr - not how we think we'd deploy bzr for Ubuntu developers, just a test to understand how it would scale *if* we did it this way. Lars Wirzenius has a habit of testing VCS systems capabilities in various ways, including importing the Debian/Ubuntu source archive into them. He kindly ran a test using bzr, creating a single shared repository, with one branch in it per source packages. This took a few hours to generate (I'm not sure of the exact figure, we forgot to time it, but it was started in the afternoon and finished in the morning). The resulting repository has 21GB in its .bzr/repository/packs directory, and 500MB in its .bzr/repository/indices directory. There are 30 pack files, the largest of which is 16GB, and the smallest a few hundred kB. In general VCS terms this repository has 16000 heads, 16000 commits (because we didn't import deep archive history). But what about performance? Its currently copying to a machine where I can do some serious benchmarks using this repository. I do have some quick and dirty figures though. To branch a single package (libyanfs-java) from its branch within the repository to a new standalone branch with cold cache took ~5 seconds. Branching again from the repository now the needed data is in page cache took 0.6 seconds. Branching from the newly created branch to another new standalone branch took 0.3 seconds. There is a clear slowdown occuring here. Including startup costs the time to make a new branch is doubled by adding the branch to the repository. However as the repository is 16000 times the size, the scaling factor (2/16000) is pretty darn good. I'm stoked at this result, as I think it demonstrates just what the underlying pack store is capable of. We are working on streamlining the upper layers of bzr to make better and better use of the underlying store. For instance, John Meinel has just done this for 'bzr missing' and 'bzr uncommit'. Now I must go, time for breakfast! Woo!

I woke up saturday morning with a pain around my stomach, and rather nauseous. After puking for a number of rounds and passing out each round of puking (Thanks for the help Sarah), Sarah suggested we stop by the emergency room to see why I would be passing out, so we did.

Well, I finally got out of the hospital today. I ended up having my appendix removed since it was causing problems and seemed to be why I was puking on saturday. To verify that I was doing well enough to go home from the hospital I had to do two things:
1) Fart
2) Take a dump

Now, if this could be the exit criteria for other things in life, then life would be very good. The other part of this is that I get to feel proud of myself for every fart this week!

gnupg (1.4.6-3) unstable; urgency=low * Adopt package. Thanks to James Troup for his work in the far past.
Thanks to NMU'ers Bastian and Thijs. (Closes: #476418)
* Co-maintainers wanted.
* Don't build-dep on pcap on non-linux-archs. (Closes: #357267) -- Sune Vuorela Sat, 17 May 2008 15:42:55 +0200 TODO:

• Coordinate with release-team and d-i what changes can still be done before lenny
• Look at the new upstream version
• Get a alioth project and host stuff in a version control system
• Decide on version control system
• Get a team and figure out team workflow
• Look at this newfangled packaging thing called debhelper
• Make all bugs either closed or forwarded

So - anyone interested?

I mentioned on my switch to Movable Type post that there were a few things that were hopefully going to happen RSN and that I'd talk about them if they did.

Well, one of them did, and Steve helpfully dropped me in it earlier in the week - I was granted write access to the debian-keyring. It's worth pointing out that while Steve did some prodding around this the process started quite some time ago; back in November James Troup (the other current keyring maintainer, and at the time the only one) contacted me regarding an offer I'd made to help out in whatever way I could. As a result I got involved in the keyring RT queue and did some basic triage and trying to point people in the right direction, where such help didn't require any keyring privileges. I also started thinking about how keyring maintenance could be shared in a trackable fashion. I made some suggestions to James and he was largely in favour with a few suggestions and wishlists.

I'll get into discussing exactly how it goes at a later point in time, but for the moment I want to get a better feel for the process and procedures to fine tune things. To that end I've been working my way through the keyring RT queue, and have removed quite a few keys of retired developers, as well as doing a handful of replacements for developers who'd lost or had their key compromised. There's still a few more tickets in progress and I'm trying my best to work through them in a timely manner - if you have an outstanding ticket and haven't heard from me then please do feel to ping it.

So qwerty was designed to avoid having two keys beside each other typed in a row. This was to avoid jamming keyboards. Dvorak decided this wasn't a useful design goal, so made his own keyboard. Anyway, this criteria to avoid jamming also makes qwerty better for small keyboards, since the jamming is now done between my fingers instead of the keys on a typewriter.

A little off-topic exercise conducted in the "eye of the storm", when Ilenia and Helen were still in the hospital: A post on Seth Robert's blog brings up the idea that many Chinese restaurants were opened as a way to go into business without competing with native male workers. The post made the rounds of several other online journals. That was the push I needed to get up and go collect a few statistics of my own, regarding an idea I've been kicking around for a while. My theory is that the number of restaurants of a given type, divided by the number of immigrants from that country might be an interesting way of guaging the popularity of the cuisine in question. In order to simplify things just a bit, I actually used data from Italy, for the following reasons:

• Most immigration to Italy is pretty recent, so it's not necessary to account for the length of time different immigrant groups have been present, and the effects that may have had on the diffusion of a given cuisine.
• Immigration statistics were readily available: http://demo.istat.it/str2006/index.html
• Italian the language almost completely corresponds to Italy the country (outside of a chunk of Switzerland, San Marino, and the Vatican), something that makes things that much easier.
• I speak Italian, so it was easy to find out all the information I needed

Unfortunately, finding out the number of restaurants of various types is far from an exact measurement, and since this is a quick fun project, I just went for Yahoo search (they deserve credit for keeping their search API open when Google's was closed) results on terms like "Ristorante Turco" (Turkish), "Ristorante Messicano" (Mexican), and so on. This was the most expedient means of gathering information quickly, but this approach does present a number of obvious problems, listed here in the hope that someone without diapers to change and a business to run might come up with some good answers:

• Some hits likely come from people talking about a restaurant that happens to be in a country, like "ristorante americano". "Nel tipico ristorante americano, ...." or in other words, "In a typical American restaurant", rather than an American-style restaurant in Italy, which is what we were looking for in the first place. This is probably also true of countries close to Italy, where people go on vacation and thus have occasion to write about their experiences in a "ristorante tedesco" (German), rather than going to eat in a German restaurant in Italy. Perhaps the search query could be improved in an attempt to eliminate this sort of false positive.
• Some restaurants probably are not known as, nor brand themselves with a country name, but instead utilize titles like "Middle Eastern", "Arab", "South American", "African", or others that do not correspond with any one country in particular. It would be possible to group countries together with other adjectives, and get statistics for these clusters as well.
• Measuring hits is measuring what people are talking about, rather than simply restaurants that exist, so if restaurants from a certain country are more talked about than others, that would muddy the statistics a bit. However, it seems reasonable that people would mostly talk about restaurants in proportion to their popularity, and I don't see a particular reason why there would be more talk of Vietnamese restaurants, say, than Thai restaurants, compared to the actual numbers.

That said, for a quick project, this approach seemed to work out ok, and the results appear credible. Obviously, the results also reflect people discussing certain cuisines, rather than an actual number of restaurants, but since it does reflect interest, we'll use the number in any case. Since the number of restaurants/interest in a type of restaurant was clearly not correlated directly with the number of immigrants, other factors must come into play. For instance, "ristorante giapponese" turns up 125,000 hits, but the stats say only 6873 Japanese nationals live in Italy. As above, hits don't mean actual restaurants, but clearly Japanese cuisine is not being popularized through immigration. Here's my guess: these statistics show, to some degree, what people in the host country actually like to eat. Food that tastes good means more restaurants. Things that aren't that popular mean few restaurants, even if there are many immigrants. To pick on one country, there are many Philippino immigrants in Italy, but very few search hits - and anecdotally, I've never seen a Philippino restaurant in Italy either, whereas even smaller towns like Padova have Chinese, Mexican (well, it's called that, even if it's a shadow of the real thing), Japanese, various Arab and middle eastern restaurants, and even a few less common things like Eritrean. And I know that many native and foreign restaurants employ Philippino cooks. Below is the chart I whipped up showing the number of Yahoo hits per immigrant. The Italian names shouldn't be too hard to figure out. A few tricky ones: Giordano-Jordanian, Giamaicano-Jamaican, Spagnolo-Spanish. If you're interested in numbers or source code, contact me.

I bought an HCL MiLeap X for Shruti (who is in the tenth standard) and the IMSc purchased an eeePC for "general use". Now that I have both machines in front of me, it seems like a good time to review them.

SimilaritiesLet's be clear that we are not comparing "jamun" to "aam" (or apples to oranges, if you prefer); these machines have quite a few similarities. Both are aimed at young students who are starting to use the computer for "real work" for the first time. Both the machines run GNU/Linux, and have similar dimensions and features --- even the prices are close. However, we are here to "raise the differences and not bury them"!

Physical appearanceThe eeePC is marginally lighter and more compact. The MiLeap appears to be more rugged though I didn't dare drop either machine to check!The eeePC has a rectangular touchpad which appears to have only one button but in fact this button has a left and right! The MiLeap has two regular buttons and a circular(!) touchpad.The MiLeap is bulkier but has a nice handle to lift it by. The eeePC can be carried like a book and has a matt finish.Both were proclaimed "cute" by Shruti and Sudeshna; I depend on their opinions in such matters!

Hardware featuresThe eeePC scores over the MiLeap X in terms of hardware features. The former has a web camera, a VGA out and one additional USB port. At the same time, the remaining features of both devices are likely to be adequate for most users --- 900 MHz low power processor, graphics adapter, wireless, ethernet, smart card reader. The eeePC has 4GB storage to the 2GB on the MiLeap, but the larger base software install on the eeePC means that the user has about the same amount of working area on both machines.The extra hardware features on the eeePC do give value for the 10% extra that one pays for the eeePC; the latter costs Rs. 17K to the MiLeap's Rs. 15.5K.

SoftwareThis is where the difference between the two is most striking. The MiLeap comes with a pre-installed "classmate" version of EduBuntu. The net result is that this looks and feels like a regular GNU/Linux system configured with software appropriate for educational use.The eeePC on the other hand has a completely icon-driven interface where even getting a terminal is not easy (Ctrl+Alt+T). However, this is just the icing on top of a regular icewm cake. The applications that actually run are just the regular ones --- not customised to fit in with the point-and-click interface.The eeePC terminal has really small fonts and is a regular xterm so that fonts are not as easy to fix as they are for the Gnome terminal used by EduBuntu on the MiLeap. Overall, EduBuntu applications which are based on Gnome are more consistent with the interface than the mix and match between KDE, Gnome and icewm that has been attempted by Xandros; the latter has a lot of promise but needs more work!It was easier to install software on the MiLeap since the EduBuntu repository is significantly larger than Xandros' repository as used by eeePC. In particular, on the MiLeap we installed nethack-qt since that is Shruti's favourite game and openvpn which is needed for us to connect to IMSc from outside the LAN.The installation of the MiLeap is that of Intel's ClassmatePC on which it is based. The entire installation is on a squashfs filesystem image. The base system is used via unionfs at run time on both machines. This makes for easy "reset to default".Suspend-to-ram does not work on the MiLeap; it should be fixed by installing the Linux 2.6.25 kernel.

PhilosophyI have long believed that un-prejudiced minds (like children) will take more readily to GNU/Linux than the hordes of "experienced" (mostly adult) computer users who have well-formed opinions about "user-friendly" software and how particular applications should behave.The "standard" GNU/Linux interface actually encourages exploration and the "tune-it", "tinker" and "fix-it" approach to learning about computing. It is not a sealed box with a "do-not-tamper" sticker. (This tinkering attitude is further enhanced by the approach taken by the designers of the Sugar interface for the XO Laptop.)Since both the systems are based on GNU/Linux (and Debian derivatives no less!), I am nothing short of thrilled at how far things have come. However, will the interface of the eeePC actually encourage exploration? Perhaps the EduBuntu interface of the MiLeap will prove too daunting for a novice. (Shruti does not classify as one since she used GNU/Linux "forever".) Only time will tell ...As Larry Wall has famously said: "There's more than one way to do it!" These devices certainly prove the truth of that assertion within the GNU/Linux world.Devices like these could push GNU/Linux into mainstream usage much more effectively than the "battle for the desktop". Hence, it is perhaps not surprising the both MicroSoft and Apple are trying hard to get into the game. However, it is only GNU/Linux that can comfortably provide a plethora of applications in less than 2GB! Until small solid state disks become significantly cheaper, those guys will have to wait.

The OpenCores website is down :(

It has been a while since I changed the template I used for blogger. Mostly since I had a couple minor things on my page, I didn't want to remove. However, I changed to using the "Layout" instead of a template, and I must say, I am rather impressed. It is now every easy to change the layout of my blog. So that I am not too positive about Google (it is a fun place to work :), the "Google Profile" available through reader sucks. If my friend adds something with a feed to her profile, it doesn't get automatically added to my subscriptions.

For info, as I've been asked by a couple of people, I've been elected as a city councillor for King's Hedges in Cambridge

Full results:

Candidate	Votes
Neil McGovern (Liberal Democrat)	762
Geri Bird (Labour)	560
Cyril Weinman (Conservative)	419
James Youd (Green)	129

This gave me a majority of 198, a massive improvement of last year's majority of just 18. Huge thank you to everyone who supported me and helped during the campaign period, I'm really grateful.

In the last week, Nicholas Negroponte gave this unfortunate interview decrying "open source fundamentalism" and hinting the possibility of a warmer relationship with Microsoft. Predictably, this has elicited an ongoing response by OLPC News and on the OLPC development mailing lists. Just a few days before Negroponte's statements hit the press, I gave a talk at Penguicon called Laptop Liberation where I talked about why I thought that OLPC's use of a free software operating system and embrace of free software principles was essential for the initiative's success and its own goals of education reform and empowerment. I've been saying similar things for some time. My main point boiled down to something that, appropriately enough, Nicholas Negroponte was fond of saying back when the project was still called the $100 laptop: an extremely cheap laptop is not a matter of if, but of when and how. This technology will define the terms on which students communicate, collaborate, create, and learn. These terms are dictated by those with the ability to change the software -- by those with access to computers, the source necessary to make changes, and the freedom to share and collaborate. Constructionism -- OLPC's educational philosophy -- is about putting powerful tools and control over those tools into the hands of learners. It is about learning through exploration and creation -- about shaping one's own educational environment. Constructionist principles bear no small similarity to free software principles. Indeed, OLPC's stated commitment to free software did not happen by accident. OLPC convincingly argued that a free system was essential for creating a learning environment that could be used, tweaked, reinvented, and reapplied by its young users. Through these processes, the XO becomes a force for learning about computation and an environment through which children and their communities can use technology on their terms and in ways that are appropriate and self-directed. We know that laptop recipients will benefit from being able to fix, improve, and translate the software on their laptops into their own languages and contexts. Much more importantly, however, are all of the uses for the laptops that OLPC has not -- and can not -- think up. OLPC is a powerful tool for learning, but ultimate power is only in the hands of those that can freely use, change, and collaborate in defining the terms of their learning environments. In its commitment to software freedom, OLPC chose not to be arrogant by assuming that it knows how its users will use their laptops. Flexible environments designed for constructionist learning and a free software platform protect against this arrogance. Constructionism and free software, implemented and taught in a classroom, offer a profound potential for exploration, creation, and learning. If you don't like something, change it. If something doesn't work right, fix it. Free software and constructionism put learners in charge of their educational environment in the most explicit and important way possible. They create a culture of empowerment. Creation, collaboration, and critical engagement becomes the norm. OLPC does not get to choose if educational technology happens. If we work hard at it though we might get to influence the "how" and the "who." Proprietary software vendors like Microsoft want the "who" to be them. With free software, users can be in power. What's at stake is nothing less than autonomy. We can help foster a world where technology is under the control of its users, and where learning is under the terms of its students -- a world where every laptop owner has freedom through control over the technology they use to communicate, collaborate, create, and learn. This, to me, is the promise of OLPC and its mission. It is the reason I've been involved and in support of the project since nearly day one. It is the reason I left Canonical and Ubuntu to come back to school at MIT to be closer to the then nascent unincorporated project. It is the reason that OLPC's embrace of constructionist philosophy is so deeply important to its mission and the reason that its mission needs to continue to be executed with free and open source software. It is why OLPC needs to be uncompromising about software freedom. As an adviser and sometimes contractor to OLPC, OLPC does not need to listen to me. But I hope, for all our sake, that they do.

Update: Richard Stallman and the FSF have published another essay on the same topic focused more on pure free software (i.e., less education specific) objections.

In the last leg of what has been marathon traveling over the last two months, I'm going to be heading back to San Francisco to give two talks at CommunityOne. CommunityOne is a new one-day conference that Sun is putting on -- along side it's massive JavaOne conference -- that focuses on free software, open source, and non-Sun projects. I'm going to be there talking about free software and free culture. I will be giving updated versions of the two talks that I have at the FSF members meetings over first two years. In the first talk, I'll be making the case for a strong free culture movement and in the second I'll be talking about liberating network services. If you will be at the conference, or just in the Bay area, and would like to meet up, I'll be in the area for most of a week and would love to arrange something. Just get in contact.

Thanks to Matt Lee for helping SVGizing my drawing.

I’ve noted in the past that Debian has deliberately enshrined in its constitution some rather serious principal-agent problems. By and large this isn’t a bad thing, since there isn’t the consensus within the Debian community to support the “benevolent dictator for life” model of decision-making—if you want that, well that’s what Ubuntu and Daddy Warbucks is for. But it does mean that sometimes the caca hits the fan when a Debian project leader does exercise his powers, as our now-former DPL did earlier this week just before the end of his term of office (by my estimate, just over one hour and 27 minutes before). John Adams would be proud. So we have three related issues in my mind:

• As a matter of general principle, lame-duck DPLs shouldn’t be making appointments. This issue is ameliorated somewhat because DPL delegations—unlike “midnight judges”—can be revoked at any time, but it strikes me that whatever legitimacy a DPL has from the developers evaporates once a new DPL-elect has been designated. I can only speculate why this happened in this case, so I won’t bother.
• Second, while Debian has a very strong tradition of developer sovereignty, with many aspects of the project being self-organized rather than originating with appointments from upon high, it seems to me that certain aspects of core infrastructure can’t be managed in this way.
• Third, the appointment does little to relieve the excessive concentration of power in the core of Debian; if anything, Anthony Towns’ apparent resignation in the wake of Jörg’s appointment worsens the situation. Ensuring there is proper vetting of people with access to important infrastructure is important, but at the same time I find it difficult to believe that there are only a half-dozen or so Debian developers who are trustworthy enough to be system administrators, account managers, or archive maintainers (several of them occupying overlapping positions). That, rather than a lack of technical tools, has been a problem of note within Debian since, oh, the days of my youthful vigor within Debian (which are long since past).

In any event, congratulations to all the new Debian developers—and I’ll avoid pondering for too long why one person’s appointment to an unrelated group would suddenly break the logjam of developer application approvals.

I've been on the road quite a bit lately. During my manic travel, I have been rather lax about blogging many of my recent talks. After a talk at CHI in Florence on the 7th and a talk at LUG Radio Live USA last Sunday, I'm in Troy, Michigan for Penguicon. It's an incredible combination of a science fiction and a free software/open source conference and it's a huge amount of fun. This morning I gave my Laptop Liberation talk and tonight I'll be helping judge the Open Source-ry Masquerade costume contest -- the very contest were Tron Guy premiered his now famous costume! Tomorrow I'll be giving my Revealing Errors talk which I premiered last Sunday at the LUG Radio event and which I'm really excited about. If you're around and at the event please find me and introduce yourself! If you're in the area, I may have some free time tomorrow night. Don't hesitate to get in contact.

Yay! A big fat thank you to:

zobel for advocating me

aba for being a great (and thorough) AM

HE for checking my application so fast

DSA, DAM and the Keyring Maintainer for pushing the right buttons and especially for doing so on a friday, so nothing gets in the way of a proper celebration tonight!

Tolimar for moral support

Pia for her invaluable support with T&S2

PS: Independently from recent events my account and also the other 18 where not created by Jörg, but on James' initiative. Just to put things straight.

I am very happy that 19 contributors who were waiting for their accounts, sometimes for a very long time, became Debian Developers today. This is great news for them, and for the project as a whole. Many thanks to all people involved for making this possible, including Joerg Jaspert, Steve McIntyre and James Troup. And congratulations to (using their account names) kibi, plessy, gregoa, goneri, tincho, akumar, filipe, miriam and the others I haven’t had the chance to work with yet. It also seems that the various pending issues (updating keys that expired, etc.) have been resolved, which is great news for several of our current DDs. But this doesn’t solve the DAM problem on a permanent basis. Something interesting about today’s events is that the account manager asked the system administrators to create the accounts, which is a nice way to offload part of the process. But the keyring maintainance is still a SPOF. A tool has been developed to allow multiple people to collaboratively edit the same keyring (and it’s used to maintain the Debian Maintainers keyring), but I’ve heard that some people weren’t satisfied with it, unfortunately. Let’s hope that this is solved soon, so the next ones to go through NM won’t have to wait that long!