Last Thursday, and the few days after, were quite intense. A series of events made me feel really loved by a lot of people, which is always a good reminder of what kind of friends you are surrounded by. I could talk about Pep's gift at work, Visenteta, a goldfish which now lives in an aquarium at home, which in turn was donated by Cristina and Brande. While I still have mixed feelings about keeping animals in cages, my choices were give it a better place than the small bowl where it initially lived, give it away to someone who could properly take care of Visenteta, or sacrifice it. I unsuccessfully tried #2, can't do #3 myself, so I accepted Brande's offer to have a decently-sized aquarium at home. Visenteta seems happy today, and I've learned all about aquarium maintenance the hard way. During the day my mobile phone didn't rest for too long intervals; everyone was calling it to congratulate me and so on. But the bigger emotions came after leaving work, when I went to l'Alqueria to hang around with my friends and see if they would go have an orxata with Maria and me. Strangely, they refused, being in the middle of an apparently very important plant transplantation operation. When suggested going for dinner instead, the reaction was pretty cold too, but this was understandable as we'd meet on Friday at my place for a tiny celebration. In the end we headed off to Alboraia alone and had a delicious orxata in Toni's shop. Maria said she had a surprise reservation in a Indo-Pakistani restaurant near my house, so after a while we cycled back to Val ncia. As it was getting dark and cold, we went into my house to get some clothes, and when I opened the living room door, I was scared by a bunch of shadows suddenly shouting at me and was buried in confetti. I couldn't react for the next 10 seconds, while my brain quickly built relations of many details that had happened during the week, all part of the preparations for a secret party at my own place. Wow, the feeling is incredible. I've participated in similar surprise parties, but had never been the target. I hope everyone reading this gets one at least once in their lives, I really loved it! But still, when the party ended, I slowly started to find little gifts all over the place: a book under my pillow, a bicycle bell on my handlebar, a cactus for my computer space... My friends had been planning all of this for the last two weeks, and I never suspected anything. Incredible! It really makes me feel surrounded by people who care about and love me, and went through the hassle of coordinating 10 or 12 persons with me not noticing at all. Thank you, everyone! The book, by the way, is Si no plou, plour , by TV3's M nica L pez, a fun compendium of popular weather proverbs which we discovered in a gas station in Tarragona, during our Easter trip to la Terra Alta.

A while ago I wrote down a goal on a whim, without really understanding how important it was:

Completely change everything I'm working on in Debian at least once per 5 years.

This goal has really grown on me. And I've seen a good way to accomplish it. I've decided to stop being involved in packaging third party software for Debian. There's a bunch of reasons, but the overarching one is that I've been doing that for 13 years, and I don't feel it's a very valuable way for me to spend my time any more. I think I've done a pretty good job, but there is not much room for growth. And it's not as if I spend much time on it. In Steve's survey I estimated I spend about 1/30th of my Debian work time on packaging. I won't gain a lot of time by not doing that work, but I'll lose one mental burden, and slim down my areas of responsibility. I'll take care of passing packages on to appropriate teams, etc, over the next month. This decision leaves me able to continue to work on teams like d-i and the CD team. I'll also continue to maintain my own software in Debian. Using a distribution as an incubator for new software, with ready-made community, bug tracking, and of course distribution channels, is something that has been a big benefit to my software, and I think also to Debian, and I plan to continue exploring that space. I'm excited! This is going to be interesting..

The recent OpenSSL incident can not be hidden. It was a very important blow to the Debian project's public face and reputation. A major hole slipped under the door in the form of a bugfix - and with all the good intention. This was not a deliberate attack, nor was it the result of a bad or sloppy maintainer - It was a honest, although painful, human mistake.
Several people started laughing at our processes and supposed strengths right away. I do, however, feel this shows how Debian is stronger security-wise than any other system. And it also shows how this saying, with enough eyeballs, all bugs are shallow, not only didn't lose validity, but was reaffirmed. Free Software development was also proved to be better than security through obscurity again.
Why?
Because were it not because of OpenSSL (and in this case in particular, Debian's packaging) being Free and subject to a code audit, this problem would have never been found. I have been asking to some friends who are part of different black-hat groups, and looking for this kind of information on the Web, it seems that -were it not for Luciano's work, we would still be running cryptographically weakened versions of OpenSSL for a long time. After all, 32768 possible keys is still quite a lot for a black-hat group to find as uneven noise, as a lead to showing the undeniable weakness.
It took two years to find the bug, yes. But it was found doing quality assurance work on publicly available source code. It was promptly fixed, mitigating (as far as possible) as much damage as could be caused. Tools for finding and fixing the defective keys were crafted and freed together with the announcement. Yes, there will be some compromises due to this, I'm sure, but an embarassing hole has been dealt with in the best way possible.
Anyway... I am very happy - I was going over Luciano's NM report, and found something I only suspected but was not sure about. I can now state clearly: I have never been so happy to advocate somebody to become a DD.
Luciano wrote a very good blog post (in Spanish) with his viewpoints on the Debian OpenSSL incident. If you happen to understand Spanish and are reading this blog, please drop over Luciano's.
Luciano: Once again, my hat goes off for you :-)

Mom and I went to Wal-Mart today to pick up two digital converter boxes (specificlly coupon-eligible converter boxes, “CECBs”) as emergency backup for Comcast’s frequently-incompetent cable service in Memphis. It took about 15 minutes for the assorted checkout staff figured out how to ring up the converters and use the government coupons for them, but eventually we escaped with two RCA DTA800B converters. I found the box relatively easy to use and hook up. The boxes included quick start guides in English and Spanish and full user manuals in both languages, as well as a programmable remote control (with batteries) and a short push-on coax (F-type) cable for attaching the box to a TV over the “antenna” TV input. Both boxes worked moderately well in southeast Memphis with a rather lame RCA unpowered indoor VHF/UHF antenna I picked up a while back, which is no Silver Sensor but a bit more compact to haul around, less likely to attract quizzical stares from airport security, and better than nothing at all. Neither box was able to scan WMC‘s rather weak digital signal (authorized at 394 kW but clearly not transmitting at anything close to that power) and there’s no manual tuning option. I’d imagine if I’d brought a decent directional antenna like the Silver Sensor I’d have gotten WMC and a more stable signal on some of the other channels. So, overall, I have no real complaints about the boxes themselves, except for the lack of a manual tuning feature available on other converters, and the SmartAntenna feature will be nice for folks with hard-to-tune channels in multiple directions when you can actually buy one again. I’ll probably examine some of the other CECB models before settling on one, however, particularly now that it appears that the reported Zenith DTT900 audio problem is fixed in newer boxes.

(This post is mostly as a reminder to myself on how I've set up my backup system. It should probably go on a wiki instead so I can keep it up to date.) After the recent OpenSSL debacle in Debian and Ubuntu, I found that all my backups were encrypted with something amounting to a well-known secret key. Ouch. I was not entirely happy with how my old backup system worked either (it was based on boxbackup). In particular, the on-disk format was opaque, the tools needed to access it were not particularly user-friendly and I had to run Yet Another CA for managing the keys for it. After looking around a little, I settled on rdup which is a tool very much written in the unix tradition of "do one thing and do it well". As it reads on the home page:

The only backup program that doesn't make backups!

(which is almost true). It keeps a list of information about which files have been backed up locally on the machine to be backed up, including some meta-information such as file size and permissions, so it can take a new backup if any of those changes. For more details, read the web page and the source. rdup is more of a framework for making your own backup system than a complete system in its own right, so this post is really about how I have customised it. First, I want my backups to be encrypted, and rdup supports encryption (both GPG and mcrypt). I'm lazy, so I settled on what rdup-simple gives me, which is mcrypt. Key generation is easy enough: head -c 56 /dev/random > /root/backup-$(hostname).crypt.key and then a chmod 600 to avoid it being world-readable. In /root/.ssh/config, I put

Host backup-$hostname
Hostname $backupserver.err.no
User backup-$hostname
IdentityFile /root/.ssh/id_rsa_rdup
ProxyCommand pv -L 40k -q   nc %h %p

so as to make it fairly easy to move stuff around and to make it pick up the right identity. The last bit is a trick to rate limit it so it doesn't saturate my DSL. pv has a wonderful -R switch which lets me change the arguments to an already-running pv, if I want to do that. ssh-keygen -t rsa -f /root/.ssh/id_rsa_rdup to generate an ssh key. It got put into /home/backup-$hostname/.ssh/authorized_keys on the backup server, so the line reads like:

command="/usr/local/bin/rdup-ssh-wrapper",no-pty,no-port-forwarding,no-agent-forwarding,no-X11-forwarding ssh-rsa AAAAB3N

The /usr/local/bin/rdup-ssh-wrapper is a small perl wrapper which only allows the rdup commands and sanitises the command line somewhat. Since I don't want to make a backup of all bits on my machines, I have an exclude file, which lives in /root/rdup-exclude. It is just a list of regexes of files to ignore. To actually make a backup, I run something like for p in /etc /home /var; do rdup-simple -v -a -z -E /root/rdup-exclude -k /root/backup-$(hostname).crypt.key $p ssh://backup-$(hostname)/srv/backup/$(hostname)/$p ; done which then goes on for a while. It gives me nice structures with hard-linked files to avoid using more disk space than needed. I can then just have a small find(1) script prunes old backups as I don't need them.

With my server migration I switched from PostgreSQL 8.2 to 8.3. However, I've installed MediaWiki for the awesome wiki on 8.2, but dumping from 8.2 and restoring to 8.3 just failed because of the tsearch2 extension, which is now part of PostgreSQL 8.3. With the help of my friend Dimitri, the pgloader author, I managed to migrate the database from PostgreSQL 8.2 to 8.3. Here is how I did. This was done with MediaWiki 1.12, and I doubt that older version supports PostgreSQL 8.3. Dump the database schema First, you need to dump the database schema, and then, the database data. We need to do it in two steps because we need to change the schema a bit. I assume that MediaWiki is installed in the mediawiki schema:

% pg_dump -s -n mediawiki wikidb > wikidb-schema.sql

Convert the schema Then, edit your wikidb-schema.sql. When you installed tsearch2, you probably did it in the public schema like I did. So it created two or three data types used by MediaWiki wich are named public.datatype. These tsearch2 datatypes are now part of PostgreSQL, so they're in the pg_catalog schema. You just need to replace a few lines with public.datatype with pg_catalog.datatype. For example public.tsvector is now pg_catalog.tsvector. For your information gin_tsvector_ops is now pg_catalog.tsvector_ops. Finished? Good, but that's not all. You need to split up the file in two parts: one with the tables creation, and another one with the constraints creation. Why? Because otherwise the data insertion will fail because of these constraints. That's not so hard, just split your files in wikidb-schema.sql with all CREATE TABLE and so one, and then you see that the SQL file begins to do some ADD CONSTRAINTS, just put this in another file, named wikidb-constraints-schema.sql. You'll also need to set the namespace before executing command in your second file, so do not forget to add a SET search_path = mediawiki, pg_catalog; line at the beginning. Dump the database data That's easy:

% pg_dump -a -n mediawiki wikidb > wikidb-data.sql

Create your new database That's easy too:

% createuser -S -D -R -P -E wikiuser #(then enter the password)
% createdb -O wikiuser wikidb
% createlang plpgsql wikidb

Restore the database That's even easier, but you need to respect this order, otherwise it will fail:

# Restore schema first
% psql wikidb < wikidb-schema.sql
# Then restore dat
% psql wikidb < wikidb-data.sql
# Then restore constraints
% psql wikidb < wikidb-constraints-schema.sql

Run update.php Just go the the maintenance directory. Then you can try to run update.php, but it'll fail.

% php update.php
[...]
Could not open "/var/www/awesome.naquadah.org/wiki/maintenance/postgres/archives/patch-tsearch2funcs.sql".

Well it seems that MediaWiki people just forgot this file in the 1.12 archive.. You can grab it on the SVN repository here. When you've put it in the good directory, really run:

% php update.php
[...]

You should see no error. And now it works. Give us some kudos This is the last and hardest part of this tutorial. Since everything works, you should give kudos to Dimitri and me.

The Japanese post-rock band Mono delivered an amazingly powerful album in 2006: You Are There. It features beautiful and spacious sound scenes produced with real instruments (as opposed to electronic music), in some ways much more so than Mono s other, earlier albums, which I adore as well. This album captivates me to the point that I can t really to work to it; yet, it s also just too good to turn off. I am stuck between a rock and a hard place, it seems. On a related note: I am going to see Explosions in the Sky in Zurich s Abart club next week. The music is very similar, not only because both bands are published by the same label, Temporary Residence (along with many other really good artists). And I am excited about this for two reasons: first, because they rock. And second, because I ll be with a certain someone then, whereas now I d have to say that you are there . NP: Mono: You Are There

As I said a month ago, my main server Delmak was dying. Well it still runs (proof: you could read this blog some days ago). Thanks to friends I host for free, they've kindly given enough money to buy a brand new server (C2D E8400, 4 GB RAM, 2x500 GB RAID 1) in order to replace the good old Delmak. This new box has been named Prometheus after the only BC-303 class battleship ever built. Delmak was used to mainly run as a Web, mail and databases server. I decided to do use this server switch to change the server software I use. The first mail server I setup was based on Exim 3, courier- imap,pop -ssl, with userdb files. That was... rough. Later I switched to Exim 4, using vexim, and MySQL as a back-end. That was something like 3 years ago I guess. Since then I never really touched that back. I added spamassassin and clamav filtering some months after, because some users asked for it. That's all. So this week, I decided to switch away from this configuration. I do not understand Exim anymore anyway, so I decided to use Postfix which I often use and administrate at work. Obviously, I also now use PostgreSQL as database back-end, since it rocks, and since Postfixadmin supports it. By the way, be aware that the Debian package of postfixadmin is crappy (the configuration file is readable by anyone by default, with the database password in it). I also set up postgrey which is quite nice and efficient. Well, then was time for amavisd-new installation, but I did not do it. Seriously, amavisd-new configuration is a bloody mess, as the language it is written in (yes, Perl). So I switched to dspam which I heard is nice. Well, it seems to be for now, since it even supports clamav daemon usage directly, which is very very nice because that means I do not have to set up another thing for that. I also switched from courier to dovecot, mainly because the latter seems to be faster and lighter. I then changed the default virtual_transport to Dovecot LDA. The main advantage of this is that the LDA updates the Dovecot index while delivering. It also supports quota, which I do not use and plug-ins, like the Sieve language for mail filtering. So I decided to change my procmailrc to a new Sieve filter. My procmailrc is quite small since I only use regex to match lists and some mail address, so it has only something like 12 rules. And well, I did not do it since I discovered after some googling that Dovecot implementation of Sieve is grabbed from Cyrus which does not support variables for now. That means that the following procmailrc code:

:0:
* ^X-Mailing-List: <debian-.+@lists.debian.org>
* ^X-Mailing-List: <debian-\/[^@]+
list-debian-$MATCH/

which will translate to:

require [ "regex", "variables", "fileinto" ]
if header :regex "X-Mailing-List" "<debian-(.+)@"
 
    fileinto "lists.debian.$ 1 ";
    stop;
 

But that won't work since Dovecot Sieve implementation does not support "variables". Well, since I'm not ready to list all the lists I'm subscribed to, Sieve is a no-go for now. I'll stick with procmail.

It has recently been announced that Debian had a serious bug in the OpenSSL code [1], the most visible affect of this is compromising SSH keys - but it can also affect VPN and HTTPS keys. Erich Schubert was one of the first people to point out the true horror of the problem, only 2^15 different keys can be created [2]. It should not be difficult for an attacker to generate 2^15 host keys to try all combinations for decrypting a login session. It should also be possible to make up to 2^15 attempts to login to a session remotely if an attacker believes that an authorized key was being used - that would take less than an hour at a rate of 10 attempts per second (which is possible with modern net connections) and could be done in a day if the server was connected to the net by a modem. John Goerzen has some insightful thoughts about the issue [3]. I recommend reading his post. One point he makes is that the person who made the mistake in question should not be lynched. One thing I think we should keep in mind is the fact that people tend to be more careful after they have made mistakes, I expect that anyone who makes a mistake in such a public way which impacts so many people will be very careful for a long time… Steinar H. Gunderson analyses the maths in relation to DSA keys, it seems that if a DSA key is ever used with a bad RNG then it can be cracked by someone who sniffs the network [4]. It seems that it is safest to just not use DSA to avoid this risk. Another issue is that if a client supports multiple host keys (ssh version 2 can use three different key types, one for the ssh1 protocol, one for ssh2 with RSA, and one for ssh2 with DSA) then a man in the middle attack can be implemented by forcing a client to use a different key type - see Stealth’s article in Phrack for the details [5]. So it seems that we should remove support for anything other than SSHv2 with RSA keys. To remove such support from the ssh server edit /etc/ssh/sshd_config and make sure it has a line with “Protocol 2“, and that the only HostKey line references an RSA key. To remove it from the ssh client (the important thing) edit /etc/ssh/ssh_config and make sure that it has something like the following: Host *
Protocol 2
HostKeyAlgorithms ssh-rsa
ForwardX11 no
ForwardX11Trusted no You can override this for different machines. So if you have a machine that uses DSA only then it would be easy to add a section: Host strange-machine
Protocol 2
HostKeyAlgorithms ssh-dsa So making the default configuration of the ssh client on all machines you manage has the potential to dramatically reduce the incidence of MITM attacks from the less knowledgable users. When skilled users who do not have root access need to change things they can always edit the file ~/.ssh/config (which has the same syntax as /etc/ssh/ssh_config) or they can use command-line options to override it. The command ssh -o “HostKeyAlgorithms ssh-dsa” user@server will force the use of DSA encryption even if the configuration file requests RSA. Enrico Zini describes how to use ssh-keygen to get the fingerprint of the host key [6]. One thing I have learned from comments on this post is how to get a fingerprint from a known hosts file. A common situation is that machine A has a known hosts file with an entry for machine B. I want to get the right key in machine C and there is no way of directly communicating between machine A and machine C (EG they are in different locations with no network access). In that situation the command “ssh-keygen -l -f ~/.ssh/known_hosts” can be used to display all the fingerprints of hosts that you have connected to in the past, then it’s a simple matter of grepping the output. Docunext has an interesting post about ways of mitigating such problems [7]. One thing that they suggest is using fail2ban to block IP addresses that appear to be trying to do brute-force attacks. It’s unfortunate that the version of fail2ban in Debian uses /tmp/fail2ban.sock for it’s Unix domain socket for talking to the server (the version in Unstable uses /var/run/fail2ban/fail2ban.sock). They also mention patching network drivers to add entropy to the kernel random number generator. One thing that seems interesting is the package randomsound (currently in Debian/Unstable) which takes ALSA sound input as a source of entropy, note that you don’t need to have any sound input device connected. When considering fail2ban and similar things, it’s probably best to start by restricting the number of machines which can connect to your SSH server. Firstly if you put it on a non-default port then it’ll take some brute-force to find it. This will waste some of the attacker’s time and also make the less persistent attackers go elsewhere. One thing that I am considering is having a few unused ports configured such that any IP address which connects to them gets added to my NetFilter configuration - if you connect to such ports then you can’t connect to any other ports for a week (or until the list becomes too full). So if for example I had port N configured in such a manner and port N+100 used for ssh listening then it’s likely that someone who port-scans my server would be blocked before they even discovered the SSH server. Does anyone know of free software to do this? The next thing to consider is which IP addresses may connect. If you were to allow all the IP addresses from all the major ISPs in your country to connect to your server then it would still be a small fraction of the IP address space. Sure attackers could use machines that they already cracked in your country to launch their attacks, but they would have to guess that you had such a defense in place, and even so it would be an inconvenience for them. You don’t necessarily need to have a perfect defense, you only need to make the effort to reward ratio be worse for attacking you than for attacking someone else. Note that I am not advocating taking a minimalist approach to security, merely noting that even a small increment in the strength of your defenses can make a significant difference to the risk you face. Update: based on comments I’m now considering knockd to open ports on demand. The upstream site for knockd is here [8], and some documentation on setting it up in Debian is here [9]. The concept of knockd is that you make connections to a series of ports which act as a password for changing the firewall rules. An attacker who doesn’t know those port numbers won’t be able to connect. Of course anyone who can sniff your network will discover the ports soon enough, but I guess you can always login and change the port numbers once knockd has let you in. Also thanks to Helmut for advice on ssh-keygen.

• [1] http://www.debian.org/security/2008/dsa-1571


• [2] http://blog.drinsama.de/erich/en/linux/2008051401-consequences-of-sslssh-weakness.html


• [3] http://changelog.complete.org/posts/714-Thoughtfulness-on-the-OpenSSL-bug.html


• [4] http://blog.sesse.net/blog/tech/2008-05-14-17-21_some_maths.html


• [5] http://www.phrack.org/issues.html?id=11&issue=59


• [6] http://www.enricozini.org/2008/tips/ssh-host-key-fingerprint.html


• [7] http://www.docunext.com/blog/2008/05/14/my-security/


• [8] http://www.zeroflux.org/cgi-bin/cvstrac.cgi/knock/wiki


• [9] http://www.ducea.com/2006/07/05/how-to-safely-connect-from-anywhere-to-your-closed-linux-firewall/

Share This

There is an article on TechCrunch on Windows on the OLPC. This article started out as a comment below lots of comments that were missing the point, but eventually grew too large. The entire discussion circles around the question whether it would be beneficial to give the users the same view and behaviour that is on 90% of machines worldwide, so they can start out prospective jobs with a minimum of training. Learning your way around the UI is only a significant part of training if that actual work you will do is trivial — so this argument basically boils down to "I don't expect the African kids to do anything but grunt work during their lifetime anyway, so we better start training them early", which is the wrong approach not only to education. To make a bad car analogy, roads are usually made of several layers, from the foundation providing the stability up to the paint defining lanes. Operating systems are similarly layered, with a core that applications (cars) never touch directly, and several other layers on top of that that are not really required for basic functionality, but that add safety (process separation) or comfort (standard functions). The minimum standard of things is a "platform definition", which all car (or application) makers can expect — all roads have a minimum width and there are no dangerous spikes (if that is not true, you can get a steamroller or respectively format your harddisk). Railways use the same kind of foundation (operating system), but the platform (heh) is quite different. You cannot drive a car on a railway, or a train on a road, just as you cannot run a Windows application on a Linux system or vice versa (there are special wagons you can place your car on, and special trucks with rails on them if you feel like it, but these are heavier and need more energy to pull). Now in this discussion, people have been comparing Windows (the platform) to Linux (the operating system). That doesn't work. On Linux, there are several platforms available, the most prominent being GNOME and KDE for the desktop and POSIX utilities on the command line, but there are lots of others as well. Part of most platform definitions is an user interface, which abstracts what is really happening to something comprehensible to the user, using analogies (a tachometer displays our speed as an angle usually, but other representations are possible). The "desktop" idiom happened to be the first graphical UI some thirty years back, and was perpetuated into today's computers (just like the width of roads hasn't changed from the days of the Roman empire, where it was "two horses and then some"), however this doesn't mean it is the best choice available — it's just what we are used to. If you look at the screen contents on the day traders' computers (lots of that on the TV right now thanks to the market crisis), you will notice the vast majority does not use overlapping windows or standardized "rising-edge" buttons to click on, but rather, they have a tightly-packed grid layout with high-contrast information displays that also color-code certain messages. I think that is the most important point here: to achieve optimal results, the presentation idiom needs to be chosen in a task specific way. With children as the target audience, we lose one of the key requirements behind the adoption of the windowed view: the need for side-by-side presentation of data from multiple unrelated sources (which is also a problem given the lack of screen space). With the introduction of ad-hoc mesh networking and collaborative applications, the "desktop" analogy begins to break down. The project's mission also defines requirements on the platform. If we want to keep the requirement "users should be able to build and share their own stuff", then we want a framework where it is hard to make mistakes, especially those that can be spotted only after an interesting failure, and more importantly impossible to write code that makes unrelated components fail, because these components might be your way back out of the situation. Windows has an excellent event model with fairly good isolation of components (to the point where a problem in an event handler can be handled by the event loop rather than terminating the program, so for example Internet Explorer can shut down broken plugins rather than crashing), but the detail knowledge required to really work with the API (how to build a message loop that also runs queued I/O completion handlers correctly) leads to a fairly steep learning curve, and would teach implementation details rather than concepts. The normal "linuxy" approach of going low level whenever higher-level approaches fail is not the answer either as we want to truly empower people rather than just training them to be a cheap replacement for the tech support Indians (no offence), so it is vital that the "real" applications use the same framework that people implementing new things would use, and thus all the complexity that we want in our "official" applications needs to be taken care of by the platform, with all the safety features in place too. So no existing platform provides what we want. — hence Sugar. And that is the problem for Windows advocates: Sugar replaces those bits that make Windows a platform and not just a kernel, so porting Sugar to Windows doesn't make sense from a technical point of view, since we already replaced the bits that we didn't have free software for before. Other than that, the "Linux vs. Windows" kernel choice is secondary; in fact both kernels are very similar in design and function, the various advantages and disadvantages of either aren't that relevant really. The only technical reason in favour of Linux is the virtual memory management — the Windows VMM behaves erratically in the absence of a swap device, but I believe that is not something that cannot be fixed. The reason why I believe Linux is the better choice here is long-term support. Since these devices will be used in basic education (which hasn't changed that much in the past years as 1 plus 1 still equals 2), there is hardly any need for radical changes after the initial rollout — why add instability when you don't have to? With Microsoft as a for-profit company, there needs to be a business model sustaining that behind it, and I believe it will be very hard to find one. "Subscription" falls down in that it is a long-term recurring expense, which governments tend to be pretty wary of. The alternative is to upgrade several million computers' OS every few years. Lots of companies are skipping entire Windows releases because of the migration cost, and even with the "console bonus" (all hardware is the same) and bootloader support for software upgrades over a mesh network, this is still a massive endeavour. That each machine would have to reserve enough memory for the entire "upgrade pack" so it can transition "in one go" also makes this model unworkable. To summarize, using Windows on the OLPC does not make sense at all. If you use just the kernel, you don't gain anything over Linux, and if you use the entire platform (and by extension, the UI), you add unnecessary complexity that is not only not required for the actual task, but also distracting. If you add restrictions and extensions to make it work, you invent a new platform, which is precisely what Sugar did. The argument that it is important for pupils to use the same thing that the rest of the world is using to ease their entry into the workforce is bogus at best, and racist at worst.

For a recent university seminar, I wrote a haskell program to render and edit iterated function systems (IFS), which generates a certain class of fractals, namely self-similar sets. I think the result is quite nice, so I m sharing the code. With FrakView you can view a rendering of the attraktor of the IFS, whith a choice of two algorithms (a straight forward, and a probabilistic), configurable depth and anti-aliasing. You can also modify the IFS by dragging the colored boxes with arrows you see on the screenshot. For the academically inclined, there is also support to visualize cylinder sets and otherwise explore the coding space of the IFS a bit.The program is written in haskell and uses gtk2hs, the gtk bindings for haskell. It might be interesting for other gtk2hs programmers to see how FrakView solves some issues: For example, it uses the CoroutineT monad transformer I recently blogged about check out the pausingForM_ function in GUI.hs. Also, the current state of the screen is in one algebraic data type (ScreenConfig) that supports equality checks, so when the user interacts, the code recomputes the new ScreenConfig (using getRenderer), but only redraws the screen if it differs from the previous. This is much easier and more robust than having to decide for each possible user interaction whether it changes what s on the screen.You can get the source from the FrakView darcs repository.

To follow this little screencast tutorial on editing Web applications:

• apt-get install vim curl subversion on a Debian install
• Letterly source I use for an example
• .vimrc see CleverTab()
• HTML5 VIM script for validator.nu

Recorded with recordmydesktop—follow-mouse -width 256 -height 256. I had to record it on my Thinkpad X40 as my X61 sound setup suffers from some sort of overrun. Couldn’t figure out jackd. Validator.nu is for helping find problems with HTML not PHP, so sorry for the sideline 2:30 mins in the video. :) Finally also “checkout” Google doctype.

For a project I was looking for a way to use GNU Mailman for mailinglist management (especially its powerful web based moderation, bounce handling and attachment scrubbing features) but storing the mailinglist member information in a SQL database. That's useful when you want to relate mailinglist members to extra information already in a database and functionality on an interactive website, and it's possible on a per-mailinglist basis. This turned out to be not very difficult but just not that clearly documented. What I used:

• Mailman. I used the 2.1.x version packaged in Debian etch: an "open" system is just one apt-get away!
• The MySQL Member Adaptor available from rezo.net. There are several versions of MySQLMemberAdaptor around the web, but this one seems the most recent.

This explanation assumes you know how to work with Mailman in a regular setup, and things like creating databases and users under MySQL. Take the following steps:

1. Install and set up mailman as you would otherwise.
2. Put the MysqlMemberships.py file into the dir that is Mailman's base, this normally already has files like MemberAdaptor.py in it. For Debian this is /usr/lib/mailman/Mailman. You only need to add MysqlMemberships.py, the other files from rezo.net are not needed.
3. The create table query in MysqlMemberships.py does not work with MySQL 5, I had to apply this patch which I've sent to MySQLMembership's author in the meantime. This patch has been applied by Fil.
4. Create a database and a MySQL user, and add that information into your mm_cfg.py, like this:

   MYSQL_MEMBER_DB_NAME = "mailman"
   MYSQL_MEMBER_DB_USER = "mailman"
   MYSQL_MEMBER_DB_PASS = "somethingrandom"
   MYSQL_MEMBER_DB_HOST = "localhost"
   MYSQL_MEMBER_TABLE_TYPE = "wide"        # wide means one table per list, flat = one large table

5. Create a mailinglist like your normally would (e.g. via newlist). To enable the MySQL backend for just that list, create a file extend.py under /var/lib/mailman/lists/listname with the following content:

   from Mailman.MysqlMemberships import MysqlMemberships
   def extend(list):
           list._memberadaptor = MysqlMemberships(list)
   

   (whitespace is significant in Python).
6. It should work now! Upon receiving the first request for your list, the database table will be created automatically, which you can then populate. You may need to restart the mailman qrunner after you make further changes to your setup.

When an emergency occurs in a critical piece of your infrastructure, problems are to be expected. I don't think anyone can argue with that. If you do have a piece of infrastructure so critical that the use of your services all over the country will be affected by it not being there anymore, you'll want to have emergency procedures in place; one of these procedures could be having a backup copy of your infrastructure standing by, allowing it to take over should the primary break down. If you have multiple instances of almost-but-not-quite the same thing, allowing another instance of said thing to take over your functioning should you break down might be a good idea, too. If the emergency that sparks the problem in the first place turns out to be "fire", it might be a good idea to investigate your infrastructure for fire safety; you wouldn't want the same thing to happen all over again in te near future on a different site. And if things go really bad, you will want to inform your users as much as humanly possible: in today's day and age, that would include posting something on your website, even if that's only reference to a phone number which people can call for more information. Welcome to the real world. Long live the NMBS... Not. Last year or so, some critical piece of infrastructure in the Brussels South trainstation burned down. As a result, trains were delayed and often cancelled for months afterwards. This clearly shows they did not have any emergency procedures in place; if they did, train services would have returned to normal after, at most, a few days. Granted, the piece of infrastructure that burned down last year was a power transfer station, which might be hard to replace, but still. Today, another fire burned down another piece of infrastructure; this time, it was the signalling station in Brussels North. The fire itself occurred around 16:30, and from 17:30 onwards, not a single train could enter or leave Brussels anymore. Right now, more than 7 hours later, it is still impossible to get from or to Brussels. Even here, in Mechelen, it seems impossible to get to Antwerp—the opposite site, but because almost all trains to Antwerp come from Brussels, well... And of course, the NMBS website mentions none of this. The only thing it mentions is the fact that there are "extra trains to the coast", because of the hot weather. As if anyone would be interested in taking the train right now... Huge companies. A PITA, that's what they are.

Gabl (the incredible indie no-longer-one-man band/art collective from back home) have released their new video: Drunk Fox in London . As you might have guessed it features an intoxicated fox, which I like to think has a passing resemblance to Firefox's mascot. Check it out!

So one of the amazing things about the net is not so much how it makes lots of data available (actually that can be the nightmare of the net) but how it makes it available. And one of the more powerful forms of availability is in the form of visual mapping. So this new tool theNNDB Mapper is just one such visualization tool that I have to say, is pretty niftfy, though still a little green and beta at least in terms of its data. Take for example, the hacker map, which is pretty sparse right now but the great thing about it is 1) one can add data 2) and it generates useful data and links, for example, to profiles, such as this this one of Kevin Mitnick. Apparently, he is not linked to anyone, which is ironic (and just wrong) because he it is more correct to say was linked like to an entire generation of hackers, especially those who participated in the Free Kevin movement (and that could perhaps be another field?)..

The configuration of this blog has been explained earlier. There was one thing still missing from this blog --- comments.The comments plugin that comes in the contrib tarball from the pyblosxom web site is well-documented and easy enough to install. One modification I made is to remove all the javascript stuff since I don't understand the latter.After all this one still needs some sort of authentication to prevent complete rubbish from cluttering the comments section. The natural candidate was openid which is supported by a plugin from snarfed.org.This seemed easy enough to configure except that there is no version of these libraries in Debian "etch" (which is what people.imsc.res.in runs). So I downloaded the latest 2.x.x version of these libraries. Since I rarely install my own python libraries, it took me a while to figure out that I need to run

python setup.py install --home $HOME

in order to install it in my home directory. This also needed the codebase variable to be set in config.py.Unfortunately, this still did not work. The plugin comments_openid.py actually uses the API from the older 2.0.x version of the python-openid libraries.Some error messages from our web server led me onto a completely different track and I thought that the rewrite rules from the .htaccess file were in error. This was a McGuffin and I had to revert to the comment-free version in order to clean-up the mess. Thank goodness for git!The plugin currently works with the 2.0.x version of the libraries which may be mildly worse than the 2.1.x version.Some other things which are not working are e-mail/rdf notification of comments. I don't know if I will bother to fix that.

I am affiliated with a project whose origin is the northern parts of Canada, although whose members span the globe called What Sort of People Should There Be?. The idea behind this nifty and catchy title is to get a bunch of researchers in various fields, from disability studies to philosophy and everything that comes in between to start asking a series of questions about the role of human enhancement today and eugenics in the past, all within the context of thinking about the experience and politics of disability. I am super excited about the project because it spans the past and present to confront what it means to be human, how we value variation, how we seek to support or erase difference, and lastly something close to my academic heart, the role of technology in facilitating and dampening the politics of possibility and hope when it comes to disability. The project has recently launched an multi-author blog and I will be posting there from time to time. If you are interested in this topic, do come by for a visit. I am sure you won’t be disappointed. My most recent post is here and it covers an interesting article in the New York Times on Mad Pride, which oddly enough is in the Fashion & Style section.

So far, if you want to use KDE 4 under Debian, you need to install them from experimental. Under the ground, we prepared up-to-date packages from trunk (soon uploaded) and I took a snapshot of my current desktop: We didn’t know yet if Lenny will be shipped with KDE 4 but we hope it will be in good shape to have it. Everyday, improvements are done and the desktop is enough stable/solid to be used on a day to day basis. On other side, I reported a bug on plasma panel alignment isn’t saved and some hours later, Marco Martin (mart) fixed the issue \o/ Tips: if you want to have a transparent panel, you need to enable compositing.