This was meant to echo Jeff Bailey s Out and about!, where Jeff wrote about blood transfusion. Every country has its own values, rules, and methods for blood donation (be it about anonymity, retribution, etc.), but please consider getting informed, and donate. According to the tablissement Fran ais du Sang (roughly translated to: French Blood Institute), the key point is to donate again, possibly on a regular basis. Various possibilities in France: donate full blood (2 months delay between each, takes about 10 minutes), or selectively (plasma or platelets, 2 to 4 weeks delay between each, takes about a full hour). You can save lives. Will you do it? Many thanks to Helen for reminding me to write a note about important things.

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.

(tl;dr: if you have a few minutes, please add information here) Joss, the problem with the new package formats is that there is nothing that actually uses the additional information in a way that adds significant new functionality, so the net result of the change was that we throw away the information at a different layer in our software stack, and one of the interfaces got a lot more complicated in the process. One possible application would be a "poor man's patch tracking" inside the BTS, perhaps with a new state "fixed in patch". I can see two ways of implementing that:

1. by extending the interface of the "new" package formats that Debian,Ubuntu bug numbers are attached to the actual patch files and having the archive maintenance software extract and process that information (reject packages that add a patch for a bug without closing it in the changelog, notify the BTS), or
2. by leaving the package format untouched and simply adding a regex matching "Fixes: #nnnnnn" that is reported to the BTS as "we have added a patch", so the submitter is notified that the bug is gone for him/her; the bug is then closed in the changelog of the upload removing the patch.

The former approach also allows us to link to patches from BTS pages, which the latter doesn't, so there could be actual benefit here if we believe it is worth the additional complexity. (Update: Rapha l thinks it is. I like the idea of a package format with separate patches a lot more in this context than I did without it, but still my fear that it will actually be perceived as sanctioning large patchsets still remains.) About mandatory co-maintenance: the problem isn't "helping". We have plenty of people with commit access to packages they don't even remotely understand who are really helpful (not). The problem is that someone needs to actually read all the commit logs and understand what the changes do in this context. In most cases, that person or group would be upstream, not a DD. My first impression after reading the patch was "adding uninitialized data to the entropy pool is pointless/harmful as it is not random, so this patch makes sense", because the loop around it was not contained in the patch. Obviously I'm not an OpenSSL developer. There is nothing Debian could have done internally to verify the correctness of this patch that would properly scale to the entire archive, even if we put "more emphasis on security". The only solution I see is reporting every patch to upstream immediately and getting affirmation that it is correct. This, however means that we need to produce patches that upstream can accept. For obvious code bugs, that is simple, but for integration patches like paths it is not sufficient to replace one string with another, but rather make it configurable in some place that can be reached from debian/rules. In an ideal world, we end up with very few Debian specific patches, so essentially we are talking about adding functionality to dpkg that we don't want to use. I've started a page in the Debian Wiki, Getting Packaged with an outline of a possible document aimed at upstream developers that should list the typical problems we run into and how to avoid them.

Hey! I have my 3-month update with my surgeon on Tuesday. We'll be hopefully reviewing my movement restrictions and getting the final all-clear to return to work at the beginning of next month. I don't expect that I'll be able to lift Leif, but even if I can twist and bend a little bit and reach out with both my arms at once it would be a huge improvement for me.

Do any of you have any questions? I'm going to ask for some clarification on the photo that I posted before (and hopefully will get another one). But if there's anything that other people want to know, I'll ask as much as I can.

Yesterday my wife's (Angie) father's (Ernie) wife's (Janet) mother (Lydia) died from a heart attack. I've only met her a few times, so I'm not really shaken by it, but she was a really nice lady. Something I think about is that with Janet marrying into the family after Angie and her siblings had all moved out means that there's a large chunk of Leif's family now that Angie and I can't really teach him about. So, I worry about Henry, and I'm thinking a lot about Janet. Since we're going up to Vancouver at the end of the week, we should hopefully be in town for any memorial service.

It's crazy to think back over the past 3 months. Various family members health problems; Leif learning to walk, and getting his first words; Leif moving to his own room and his own bed; Going from where I needed a walker and a trip to the mailbox was far, to where a ~1km to a park pushing a stroller makes me tired, but I can do the trip back easily enough; Going through the work to change to a new work visa; almost completing one of my master's courses; and importantly: I've got 30 of the songs finished on "Hard" in Guitar Hero 2.

It'll be fun to get back to work and regular life, though. =)

Whoa, this security bug exposed by Luciano Bello (Ola!) is one of the worst I’ve ever seen. Time to regenerate your key with the updated openssl 0.9.8c packages. This seems to be Debian specific patch that caused this bug. Further instructions should be posted on a special Debian key rollover page and the Debian wiki. Update: key rollover is hard. :/ ssh-vulnkey was missing for awhile and only recent updates to openssh-server seem to regenerate the keys for me.

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.

Here in this library, next to a couple computers available to query the catalog, a sign reads:

Do not connect your laptop to these jacks. You may loose all data in your computer.

If I wasn’t a computer-savy person, I’m completely sure I would’ve thought: “They’re bluffing.” And then shit happens, because they’re not. (Oh, but then of course the sign is not 100% honest either.)

Free software finally gets significant coverage on BBC TV's Click show this week, but I think it's very much Linux rather than GNU/Linux and free cost rather than freedom. They mentioned free security software and even raised the possibility of trojans, but didn't mention how free (as in freedom) software allows any random end-user to check or have it checked. Quite a missed opportunity! However, Click has a regular letters section, so watch it (times below), email click@bbc.co.uk and see if we can get the free software view across. The letters section this week seemed to be flaming proprietary SaaS social network site facebook for their pathetic default-permit approach to security of user details. I really think there's a role for something like noserub in free software social networking. Click-UK is shown on BBC News Channel Saturday 1130, Sunday 0430 and 1130, Monday 0030 and Sunday 0430 on BBC-1 (times BST) Click-World is shown Thursday 19:30 GMT, Repeated Friday 09:30 and 12:30 (Asia Pacific only), Saturdays 06:30, Mondays 15:30, Tuesdays 01:30 (not Asia Pacific, Middle East or South Asia) and 07:30 GMT Anyone else see this?

I believe that the Red Hat process which has Fedora for home users (with a rapid release cycle and new versions of software but support for only about one year) and Enterprise Linux (with a ~18 month release cycle, seven years of support, and not always having the latest versions) gives significant benefits for the users. The longer freeze times of Enterprise Linux (AKA RHEL) mean that it often has older versions of software than a Fedora release occurring at about the same time. In practice the only time I ever notice users complaining about this is in terms of OpenOffice (which is always being updated for compatability with the latest MS changes). As an aside, a version of RHEL or CentOS with a back-port of the latest OpenOffice would probably get a lot of interest. RHEL also has a significantly smaller package set than Fedora, there is a lot of software out there that you wouldn’t want to support for seven years, a lot of software that you might want to support if you had more resources, and plenty of software that is not really of interest to enterprise customers (EG games). Now there are some down-sides to the Red Hat plan. The way that they run Fedora is to have new releases of software instead of back-porting fixes. This means that bugs can be fixed with less effort (simply compiling a new version is a lot less effort than back-porting a fix), and that newer versions of the upstream code get tested. With some things this isn’t a problem, but in the past I have had problems with the Fedora kernel. One example was when I upgraded the kernel on a bunch of remote Fedora machines only to find that the new kernel didn’t support the network card, so I had to talk the users through selecting the older kernel at the GRUB menu (this caused pain and down-time). A problem with RHEL (which I see regularly on the CentOS machines I run) is that it doesn’t have the community support that Fedora does, and therefore finding binary packages for RHEL can be difficult - and often the packages are outdated. I believe that in Debian we could provide benefits for some of our users by copying some ideas from Red Hat. There is currently some work in progress on releasing packages that are half-way between Etch and Lenny (Etch is the current release, Lenny will be the next one). The term Etch and a half refers to the work to make Etch run on newer hardware [1]. It’s a good project, but I don’t think that it goes far enough. It certainly won’t fulfill the requirements of people who want something like Fedora. I think that if we had half-way releases of Debian (essentially taking a snap-shot of Testing and then fixing the worst of the bugs) then we could accommodate user demand for newer versions (making available a release which is on average half as old). Users who want really solid systems would run the full releases (which have more testing pre-release and more attention paid to bug fixes), but users who need the new features could run a half-way release. Currently there are people working on providing security support for Testing so that people who need the more recent versions of software can use Testing, I believe that making a half-way release would provide better benefits to most users while also possibly taking less resources from the developers. This would not preclude the current “Etch and a half” work of back-porting drivers, in the Red Hat model such driver back-ports are done in the first few years of RHEL support. If we were to really follow Red Hat in this regard the “Etch and a half” work would operate in tandem with similar work for Sarge (version 3.1 of Debian which was released in 2005)! In summary, the Red Hat approach is to have Fedora releases aimed at every 6 months, but in practice coming out every 9 months or so and to have Enterprise Linux releases aimed at every year, but in practice coming out every 18 months. This means among other things that there can be some uncertainty as to the release order of future Fedora and RHEL releases. I believe that a good option for Debian would be to have alternate “Enterprise” (for want of a better word) and half-way releases (comparable to RHEL and Fedora). The Enterprise releases could be frozen in coordination with Red Hat, Ubuntu, and other distributions (Mark Shuttleworth now refers to this as being a “pulse” in the free software community [], while the half-way releases would come out either when it’s about half-way between releases, or when there is a significant set of updates that would encourage users to switch. One of the many benefits to having synchronised releases is that if the work in back-porting support for new hardware lagged in Debian then users would have a reasonable chance of taking the code from CentOS. If nothing else I think that making kernels from other distributions available for easy install is a good thing. There is a wide combination of kernel patches that may be selected by distribution maintainers, and sometimes choices have to be made between mutually exclusive options. If the Debian kernel doesn’t work best for a user then it would be good to provide them with a kernel compiled from the RHEL kernel source package and possibly other kernels. Mark also makes the interesting suggestion of having different waves of code freeze, the first for the kernel, GCC, and glibc, and possibly server programs such as Apache. The second for major applications and desktop environments. The third for distributions. One implication of this is that not all distributions will follow the second wave. If a distribution follows the kernel, GCC, and glibc wave but not the applications wave it will still save some significant amounts of effort for the users. It will mean that the distributions in question will all have the same hardware support and kernel features, and that they will be able to run each others’ applications (except when the applications in question use system libraries from later waves). Also let’s not forget the possibility of running a kernel from distribution A on distribution B, it’s something I’ve done on many occasions, but it does rely on the kernels in question being reasonably similar in terms of features.

• [1] http://wiki.debian.org/EtchAndAHalf


• [2] http://www.markshuttleworth.com/archives/150

Share This

One of the proudest moments I had as a Canadian was sitting in the Senate visitor's gallery watching the debates on same-sex marriage that led to the full legalisation in Canada. In coming down to the US for work, I was sad to come to a place that not only didn't allow it, but had actually had a number of ballots in states voting specifically that the marriage referred to "One Man, One Woman".

I found a transcription of the Hansard of Prime Minister Paul Martin's introduction of Bill C-38 (The Civil Marriage Act). The logic in there for why Canada needed to legalise same-sex marriage is quite specific to Canada, but he talks about why it's important for the issue not to come to a vote:

The Charter was enshrined to ensure that the rights of minorities are not subjected, are never subjected, to the will of the majority. The rights of Canadians who belong to a minority group must always be protected by virtue of their status as citizens, regardless of their numbers. These rights must never be left vulnerable to the impulses of the majority.

I don't really understand the US system of rights. I hope that the protection of the right to love another consenting adult and make a commitment to them becomes the law of the land throughout the United States.

I love being married. I get the joy of being able to come home to my belle and share my day, spend time, and know that to the best of our ability, we're going to try to grow old together. I'm so happy that this ruling has come down and that in California the debate is now over.

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.

After recent not so funny thing with OpenSSL in Debian, I realized that I will have to regenerate most of keys and certificates, because last big changes I did in networking/vpn/ssh setup which involved generating keys are not older than broken OpenSSL appeared in archives. First obvious thing was SSH keys and cleanup of ~/.ssh/authorized_keys on all hosts. While doing that, I realized that I still have there several keys, which are more or less gone (not that I'd lost them, but I simply stopped to use them). So it was good opportunity to do cleanup here. While I was at these changes, cleaning up ~/.ssh/known_hosts was also good idea, because I still had there lot of hosts I collected during some of my previous jobs and I definitely won't (and can not) access these machines anymore. So good, big cleanup in SSH configuration was forced :-). Next and harder step was to found out where else I use certificates generated by vulnerable OpenSSL. Server certificates for sure were also generated by OpenSSL, so let's regenerate web and email certificates and hope I did not miss anything. All this happened yesterday, but today I realized that I missed other even more important thing - OpenVPN certificates. While regenerating certificates, I also found some machine keys which are not really used anymore, so I again could drop some of them. So that was task for this evening and now I'm hopefully really done with this issue and I really hope that this won't happen again in near future, I don't need to cleanup that often ;-).

Anyone seen this before? Today, I went to an event about the Sub-National Review Consultation (as a substitute for someone else AIUI). I'd not heard about this before, but if you're in England and you've any interest in our regional planning system (which I think you should, if you have your main home here or run a business here), you have six weeks left to comment on the UK Government's suggested changes. As I understand it, it will move the second-highest tier of planning control from democratically-accountable regional bodies to the business-led Regional Development Agencies, with some oversight by MPs and the very- indirectly-accountable council leaders. I've posted more detail on Co-opNet. When I asked about local involvement and cooperatives, I was directed towards Local Strategic Partnerships, but I'm pessimistic about how easy it will be to influence regional planning through those: a few weeks ago, I was at the launch of the North Somerset Partnership Sustainable Community Strategy for 2008-2026. It's a 72-page A4 glossy book which I've still not found time to read properly. I think the size says something about its sustainability. I've posted a little more detail on WsMForum. I'll try to answer questions about either of them on this blog or those forums...

Dear Daniel, It looks like you are referring to my post, though you got my name wrong so that wasn’t immediately obvious. Of course this is far worse than the 2003 compromise in terms of the direct, known and quantifiable impact it has on our users. I don’t think I stated otherwise, so I hardly see why your post starts with “I disagree”.

I wasn't going to comment on the recent openssl security update, because too many people have already done so. Personally I thought that Aigars Mahinovs made the best writeup I've seen so far. However I would like to say that having 20+ people all mailing security[at]debian.org to say the webpage we referenced in the security advisory is currently blank is not useful, or ask for details already released in the advisory they replied to, or ask for even more details is not so much fun. Having people immediately start mailing questions like "Huh? What can I do" is only natural, but you can't expect a response when things are as hectic as they have been recently. Ideally people would sit on their hands and bite their tongues. Realistically that isn't going to happen, and realistically this post will make no difference either... Had the issue not leaked to unstable so quickly (and inappropriately IMHO) then we'd have had a little more time. But once an issue is reported you need to coordinate with other distributions, and etc. Handling something as severe as this is not fun, and random mails from users are a distraction, and a resource-hog. I should say I was not in any way involved in the discovery, the reporting, the preparation of the fix(es), or the releasing of the update. I knew it was coming, but everybody else seemed to have it well in hand. When there are mails going back and forth for 5+ days with ever-growing Cc: lists, and mailing lists being involved I figure one more cook wouldn't be useful. So in conclusion:

a. Bad hole. b. Fixing this will take years, probably. c. 50+ mails to the security team within an hour of the advisory going public complaining of missing information is not helpful, not useful, and quite irritating. (Albeit understandable). d. People who don't know the details of an attack, or issue, shouldn't speculate and start panic, fear, and confusion. Esp. when details are a little vague. e. I still like pies.

Once again thanks to everybody who was involved and put in an insane amount of work. Yes this is only the start - our users have to suffer the pain of regenerating everything - but we did good. Really. Debian did good. It might not look like it right now, but it could have been so much worse, and Debian did do good. ObQuote: X-Men: The Last Stand

Ok, so it seems that the whirlwind on OpenSSL has settled down a bit. Posts about it are coming from everywhere, ranging from rants on package maintenance to blame-pointing on both upstream and packager sides. And, of course, Slashdot. Where does all this leave the end user with? Well, probably not much except to regenerate weak SSH keys with the new openssh-server (now enhanced with openssh-blacklist, see the new advisory) and hope to $DEITY all gets well soon. And maybe, just maybe, a minor suspicion that other Debian-packaged software may be "tainted" with a similar blemish (that being having patches that are supposed to fix something, applied with upstream's blessing, and yet not really audited enough to ensure functionality AND security of the system is maintained.) Obviously, there's going to be some adjustments to be made on the Debian side. But I do hope to $DEITY that major revamps ought to happen on the OpenSSL side as well, in particular on clarifying their public channels to reaching upstream developers (read: publish openssl-team@openssl.org in a legitimate way, being the legitimate upstream contact endpoint it is,) and keeping a closer eye on the vendors who package their software (yeah, it may not be an obligation at all for OpenSSL, but heck, their vendors are users, too!) Upstream may be free not to partake on a social contract like Debian's, but it shouldn't escape from them the fact that vendors nevertheless aggregate continuing and potential users (aside from being users themselves) for their benefit. More importantly though, is that delivering FOSS is a community effort. Sure, its easy to put blame now, but in the end, the blame isn't as important as the real cause and effects of the problem/bug/issue are. Better to move on and work together towards a real fix, rather than the bickering that currently passes as FOSS entertainment.

I won't repeat it here, but there's DSA-1571-1 waiting for your attention, especially if you made some material out of openssl over the last couple of years or so. Yes, you read it right: COUPLE. Upgrading to the new OpenSSL is easy. Generating new keys is another story. To save (or add to, depending on how you handle this) your pain, there is a simple checker that can currently see if your OpenSSH or OpenVPN public keys are weak enough to warrant replacement. I await a version that can handle X.509 certificates too (though I only just generated a new one today, before the announcement, so that means I have to do it again (and get its CSR to CACert for signing, etc.) And yeah, if you're running openssh-server, consider regenerating your host RSA and DSA keys, e.g.:

# mv /etc/ssh/ssh_host_ dsa,rsa _key* /some/place/else
# dpkg-reconfigure -plow openssh-server

That should regenerate your keys and restart openssh-server once the new keys are installed to /etc/ssh. The hard part (of making sure all the keys of your systems are updated and tested) is still up to you, however. UPDATE: The Debian wiki has up-to-date information regarding other packages that generate SSH/SSL keys at postinst. Please refer to that while the key-rollover page isn't up yet. UPDATE 2: openssh-server is updated (with corresponding DSA-1576-1) that is linked to the updated OpenSSL library. Be sure to upgrade! The new package also pulls in openssh-blacklist, a new package that contains the database needed by the new ssh-vulnkey for checking SSH public keys.

NOT. Also see #363516. Genius. Now regenerating every single SSH key, SSL certificate and whatever else I can identify that’s been produced by one of the Valgrind-clean openssl. Also expiring and changing every single password I’ve ever typed in a vulnerable SSH session (be it at login or in the session). Updating the packages on the machines was fun already. Worst Debian day ever since the 2003 compromise. And that was a BAD one. I guess we need a new openssl maintainer, we obviously cannot trust the current one(s).

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.