After having used mutt for about a decade, I decided it's time I move away from it, for various reasons that I won't go into here. I've been evaluating thunderbird^Wicedove now for a few weeks, but I can already see I won't keep using it forever, because I find too many issues with it:

1. I can't tell the thing that I never ever ever want to write HTML-formatted emails. While there is an option "Compose messages in HTML format" in the "Account settings" dialog, that only seems to impact the behaviour of the client upon "new mail", not its reply behaviour, forcing me to go to Options->Format and switch it off.
2. To make matters worse, the HTML editor and the plain-text editor are not the same dialog. That means it is not possible to switch on HTML formatting if it wasn't on originally (not a problem for me, but I can imagine it being a problem for others), but also that the fugly quoting style (vertical line next to the text) of the HTML editor is not removed when you switch from HTML to plain-text. Further on, it has issues when you want to remove white space, where it will remove entire quoting levels rather than just an empty line. This is horrible, horrible behaviour.
3. While there is support for multiple email addresses connected to the same IMAP account, it does appear that there is no support for automatically choosing the right email address based on user-defined rules, such as "which mail folder are we currently in". Having to remember that I need to select the right mail address is tiresome and error-prone; e.g., when I'm in a Debian-related mail folder, I want my mail client to use my Debian mail address automatically. It appears the only way in which icedove can automatically select sender addresses is by checking the recipient list in the To: and Cc: headers for any of its configured mail addresses, and using that to decide what to put in the from: header.

Any one of the above would eventually be enough for me to grow tired of icedove and switch to something else; but the three combined mean that I'll be looking for something else fairly soon. Suggestions are, of course, welcome.

Review: An Election, by John Scalzi

Publisher:	Subterranean
Copyright:	2010
Printing:	2012
ISBN:	1-59606-496-X
Format:	Kindle
Pages:	24

This is another story from the Subterranean Scalzi Super Bundle that probably doesn't justify a full review, particularly since this time it's a short story and not even a novelette, but as with the others it's been independently published on the Kindle (and is still available that way for 99 cents). So by my obsessive internal consistency that matters only to me, it gets a full review anyway. I was mildly surprised to find that this was actually my second reading, and now vaguely remember that Subterranean had actually sponsored the story's appearance on Scalzi's blog as an advertising experiment. So I originally read the story from Scalzi's blog, and if you don't really want to pay money for it, you still can as well. Along with a couple of ads that appear to have bit-rotted. The chief feature of An Election is the background: a world in which aliens and humans are intermingled in a political district, going about their lives against a background of rather extreme multispecies diversity. The protagonist, David, decides to run for the upcoming city council special election, despite living in a district that's minority-human and that hasn't seen a human councilor in forty-four years. (David also happens to be a gay man, which goes entirely unremarked in the story and is, in fact, entirely unremarkable given the excitingly diverse characteristics of his alien neighbors. I thought that was a nice touch.) He of course appears to stand no chance, particularly when one of the city bosses decides to run as well, but ends up with a campaign advisor almost by accident and determinedly attempts to connect with his neighbors and earn their votes. This felt quite typical to me of Scalzi's humor writing. The protagonist is a good-hearted person who gets in rather over his head but is still determined to do the right thing, while not taking anything too seriously. The background humor is never particularly threatening and tends towards slapstick and banter. I found it similar in tone to most of Agent to the Stars, although of course much shorter. As usual, Scalzi's grasp of conversational banter is probably the strongest part of the story; the dynamic between David, his husband James, and his campaign advisor brought several chuckles for me. This is slight but enjoyable. I wouldn't go out of my way to read it, but it's a good story to toss into a bundle of other work, and I remember it holding my interest when reading it on-line. (Which is rare; usually I fail to finish any fiction I try to read in a browser unless it's extremely short.) Rating: 6 out of 10

Review: Echo, by Jack McDevitt

Series:	Alex Benedict #5
Publisher:	Ace
Copyright:	November 2010
Printing:	November 2011
ISBN:	1-937007-00-6
Format:	Mass market
Pages:	367

This is the fifth book in the ongoing Alex Benedict series, but reading the previous volumes is generally optional. While there are references to earlier events (and indeed I resorted to Wikipedia at one point to refresh my memory of the plot of the the first book in the series), they aren't critical to the plot. They mostly are background for the reactions of other characters to Benedict and his firm. Echo opens with the now-familiar prologue, giving us a fleeting and limited glimpse into the mystery that Benedict and Chase Kolpath will be pursuing for the rest of the book. This time, it features the explorer Somerest Tuttle, who has spent most of his life looking for intelligent alien life. (In the far future setting of these books, humanity has spread through a large region of the galaxy but has only encountered one other alien race.) In the twilight of his career and life, a friend who works as a tour guide for astronomical tours comes to him with a story about something she saw. What, we don't know, and won't for most of the book. But, whatever it is, Tuttle never goes public with it, which is directly contrary to what everyone would expect him to do with any news about alien life. Benedict and Kolpath get involved some years later, after Tuttle's death, when a stone slab with unknown markings that was part of his estate shows up on the future equivalent of Craigslist, free to the first person who will haul it away. Benedict finds that interesting enough to go pick up, but then is really hooked when someone else goes to considerable lengths to try to make the slab disappear before anyone can get a good look at it. This, slowly, leads into poking around Tuttle's life and connections, the star tour industry, and the possible origins of the slab. If you've read any of the previous books in this series, Echo is more of the same, and I mean that in a good way. I think McDevitt is at his best when writing this sort of cross between scientific puzzle, mystery, and non-military adventure, full of people who care deeply about knowing and understanding things and don't like to be thwarted in their efforts. There is McDevitt's trademark halting and red-herring-ridden investigation that succeeds in being engrossing and compelling, plenty of opportunities to guess what's really going on (a bit easier this book than in some others), and a bit of action that I thought was better-handled than the somewhat strained action scenes of The Devil's Eye. The book moves right along, despite multiple reversals in the progress of the investigation, and the final revelation does indeed justify the strange behavior of the various people Benedict encounters. As with McDevitt in general and this series in particular, there is one caveat: the astronomical details are often interesting, but the world building in general is not terribly believable. Despite supposedly taking place millennia into the future, the society is a straight transplant (projection would imply more change than exists) of middle-class American culture, with bonus air cars, space ships, and slightly better computers. Similarly, alien ecologies suffer from severe Star Trek problems: all the planets feel like copies of Earth with a few minor tweaks. This just goes with the territory, and if you're up to the fifth book of the series, you've probably gotten used to it, but the unrealistic lack of divergence is actually used as a plot point here. That strained my suspension of disbelief a bit. That said, this sort of extremely familiar social context does give the books an oddly calm, comfortable feeling. It's tempting to describe McDevitt as cozy science fiction. There's a bit of danger, a bit of suspense, but one is fairly certain that everything will work out in the end and the reader will leave the book knowing the solutions to most of the mysteries raised without having to work very hard at understanding the society or the puzzle. If that's what you're in the mood for (and I was when I read Echo), McDevitt delivers reliably. If you like the Alex Benedict series in general, recommended, as this is an excellent example of the type. Rating: 8 out of 10

After moving from a hard drive to an SSD on my work laptop, I decided to keep the hard drive spinning and use it as a backup for the SSD. With the following setup, I can pull the SSD out of my laptop and it should still boot up normally with all of my data on the hard drive.

Manually setting up an encrypted root partition Before setting up the synchronization between the two drives, I had to replicate the partition setup. I used fdisk, cfdisk and gparted to create the following partitions:

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *        2048      499711      248832   83  Linux
/dev/sdb2          501760   500117503   249807872    5  Extended
/dev/sdb5          503808   500117503   249806848   83  Linux

and then loosely followed these instructions to create an encrypted root partition on /dev/sdb5:

$ cryptsetup luksFormat /dev/sdb5
$ cryptsetup luksOpen /dev/sdb5 sdb5_crypt
$ pvcreate /dev/mapper/sdb5_crypt
$ vgcreate akranes2 /dev/mapper/sdb5_crypt
$ vgchange -a y akranes2
$ lvcreate -L247329718272B -nroot akranes2
$ lvcreate -L8468299776B -nswap_1 akranes2
$ mkfs.ext4 /dev/akranes2/root

Finally, I added the new encrypted partition to the list of drives to bring up at boot time by looking up its UUID:

$ cryptsetup luksUUID sdb5_crypt

and creating a new entry for it in /etc/crypttab.

Copying the boot partition Setting up the boot partition was much easier because it's not encrypted. All that was needed was to format it and then copy the files over:

$ mkfs.ext2 /dev/sdb1
$ mount /dev/sdb1 /mnt/boot
$ cp -a /boot/* /mnt/boot/

The only other thing to remember is to install grub on the boot loader of that drive. On modern Debian systems, that's usually just a matter of running dpkg-reconfigure grub-pc and adding the second drive (/dev/sdb in my case) to the list of drives to install grub on.

Sync scripts To keep the contents of the SSD and the hard drive in sync, I set up a regular rsync of the root and boot partitions using the following mount points (as defined in /etc/fstab):

/dev/mapper/akranes-root /           ext4    noatime,discard,errors=remount-ro 0       1
/dev/mapper/akranes2-root /mnt/root  ext4    noatime,errors=remount-ro         0       2
UUID=0b9109d0-... /boot              ext2    defaults                          0       2
UUID=6e6f05fb-... /mnt/boot          ext2    defaults                          0       2

I use this script (/usr/local/sbin/ssd_boot_backup) for syncing the boot partition:

#!/bin/sh
if [ ! -e /mnt/boot/hdd.mounted ] ; then
    echo "The rotating hard drive is not mounted in /mnt/boot."
    exit 1
fi
if [ ! -e /boot/ssd.mounted ] ; then
    echo "The ssd is not the boot partition"
    exit 1
fi
nice ionice -c3 rsync -aHx --delete --exclude=/ssd.mounted --exclude=/lost+found/* /boot/* /mnt/boot/

and a similar one (/usr/local/sbin/ssd_root_backup) for the root partition:

#!/bin/sh
if [ ! -e /mnt/root/hdd.mounted ] ; then
    echo "The rotating hard drive is not mounted in /mnt/root."
    exit 1
fi
if [ ! -e /ssd.mounted ] ; then
    echo "The ssd is not the root partition"
    exit 1
fi
nice ionice -c3 rsync -aHx --delete --exclude=/dev/* --exclude=/proc/* --exclude=/sys/* --exclude=/tmp/* --exclude=/boot/* --exclude=/mnt/* --exclude=/lost+found/* --exclude=/media/* --exclude=/var/tmp/* --exclude=/ssd.mounted --exclude=/var/lib/lightdm/.gvfs --exclude=/home/francois/.gvfs /* /mnt/root/

To ensure that each drive is properly mounted before the scripts run, I created empty ssd.mounted files in the root directory of each of the partitions on the SSD, and empty hdd.mounted files in the root directory of the hard drive partitions.

Cron jobs The sync scripts are run every couple of hours through this crontab:

10 */4 * * *                root    /usr/local/sbin/ssd_boot_backup
20 0,4,8,12,16,20 * * *     root    /usr/local/sbin/ssd_root_backup
20 2,6,10,14,18,22 * * *    root    /usr/bin/on_ac_power && /usr/local/sbin/ssd_root_backup

which includes a reduced frequency while running on battery to avoid spinning the hard drive up too much.

A proposal to solve gender imbalance in Debian We've done all we can so far: Debian Women, the Diversity Statement, the anti-harassment contact, gender neutral language, lots of education all round, but we still suffer from a strong gender imbalance in Debian. I think that the reason is that the majority group of cisgender men in the project, although they don't actively work /against/ the rest, still have /no incentive/ to be inclusive, and generally do not understand what bearing a female name online is like. I think it is about time we addressed that, and after a lot of thinking and discussing with many other concerned debianers, I think I have just the right proposal, which is twofold. The first part is this: since the goal is to have an equal gender perception in Debian, we can just decide to only approve one obviously-male-named DD for every obviously-female-named one. That's right: no new obviously-male-named DD unless an obviously-female-named DD has just been approved. It may sound like affirmative action gone wild, but please stop a moment to think about it: this would create precisely the right incentive for the currently dominant group of developers to be inclusive! People shouldn't just assume they can get a Debian account regardless of what happens around them. We already ask NM candidates to fix RC bugs and, well, gender imbalance should be treated as an RC bug, and everyone should feel compelled to join the effort to fix it! Now, of course since there currently are many male names in NM but not a single female name, it would not be reasonable to just stop the flow of new developers into the project: that would just have the effect to make us starve on personpower. So here is the second part of the proposal: the one-female-name-one-male-name policy will not be enforced for, say, a year. But during this year, everyone currently in NM or joining NM will be asked to adopt a female identity. Crazy? No, genius! It's about time people understood what it means to get advances in private every time they make a public contribution! What better way than just trying it out for themselves? On top of that, as more and more female names appear in Debian changelogs, fake or not, people will finally start to understand that it does not matter what name is used to sign the contribution, but the contribution itself. I don't know if this will give us a community where people realise female or male contributions are equally valuable, which is what I hope, or a community where people will think that everyone is a cisgender man even if they have female names. In the end, really, it does not matter. Either way, we finally get to have a community where everyone is /guaranteed/ to be treated the same. But gender imbalance isn't the only imbalance we have in Debian. People accrue a reputation over time, good or bad, and this reputation tends to stick on you for years, regardless of how you may change, for better or for worse. When we evaluate the merit a contribution, we should not be biased by the reputation of the contributor! How can new contributors be taken seriously otherwise? I believe we are loosing lots of fresh, good ideas this way. And how much damage could be wrecked on the project by a well-respected contributor, like a Debian Account Manager, who is having a funny day? I think we can address this just as I propose to address gender imbalance: let's swap identities from time to time, like it usually happens with nametags at the end of Debconfs. Let's see gregoa upload a patched versions of python3.2, and enrico upload a new upstream version of eglibc! See if we won't finally have some peer review at last! Reputation and real identities have many merits, but we have come to rely too much on them, and it is hurting us. It is time we did something about it, before it is too late!

Russ Allbery wrote an informative post about how to determine which charities are worth donating to [1]. He has a link to another article about the charities to which he donates and concentrates on ways of analysing the effectiveness of charities. So someone who has different ideas about which types of charity are worthy of donation could still learn a lot from his post. Adam Green wrote an interesting article for The New Yorker about Apollo Robbins who is one of the world s best pick-pockets [2]. Apollo picks pockets as a magician to entertain people and always returns what he steals. Now he is working with neuroscientists who are devising experiments to determine why his tricks work. Rick Falkvinge wrote an insightful article describing the way that the copyright monopoly is in direct opposition to the freedom to make contracts [3]. It s a good rebuttal of a common argument in favor of copyright law. Seth Godin gave an interesting TED talk about the problems with the education system, how and why it teaches conformity and little else [4]. One of his suggestions for improvement is to have students spend their evenings watching lectures by experts and class time asking questions. He also says that everything should be open book and that there is no value in memorising anything it s a bit of an overstatement but it s essentially correct. Cory Doctorow wrote an interesting article for The Guardian about positive externalities and copyright law [5]. I think that he didn t choose the best way of framing this issue, but he makes some very interesting points anyway. Andrew Norton wrote an interesting article about how to reduce corruption in the police force and other government agencies [6]. A large part of this is based on making them subject to the same laws as everyone else, which seems to be a radical idea. Valerie Aurora wrote an insightful blog post about suicide [7]. Emily Oster gave an interesting TED talk about the factors that determine the spread of AIDS in Africa [8]. It s quite different to what you probably expect.

• [1] http://www.eyrie.org/~eagle/journal/2012-12/006.html
• [2] http://www.newyorker.com/reporting/2013/01/07/130107fa_fact_green
• [3] http://tinyurl.com/apovrka
• [4] http://www.youtube.com/watch?v=sXpbONjV1Jc
• [5] http://tinyurl.com/a7rutft
• [6] http://tinyurl.com/a227fvg
• [7] http://tinyurl.com/a5zo6tn
• [8] http://tinyurl.com/3f7283s

So you probably heard that I have that little new project of mine: QiFi the pure JavaScript WiFi QR Code Generator. It s been running pretty well and people even seem to like it. One of its (unannounced) features is a pretty clean stylesheet that is used for printing. When you print the result will be just the SSID and the QR code, so you can put that piece of paper everywhere you like. That works (I tested!) fine on Iceweasel/Firefox 10.0.12 and Chromium 25.0. Today I tried to do the same in Opera 12.14 and it failed terribly: the SSID was there, the QR code not. And here my journey begins First I suspected the CSS I used was fishy, so I kicked all the CSS involved and retried: still no QR code in the print-out. So maybe it s the QR code library I use that produces a weird canvas? Nope, the examples on http://diveintohtml5.info/canvas.html and http://devfiles.myopera.com/articles/649/example5.html don t print either. Uhm, let s Google for opera canvas print And oh boy I should not have done that. It seems it s a bug in Opera. And the proposed solution is to use canvas.toDataURL() to render the canvas as an image and load the image instead of the canvas. I almost went that way. But I felt that urge need to read the docs before. So I opened http://www.w3.org/html/wg/drafts/html/master/embedded-content-0.html#dom-canvas-todataurl and https://developer.mozilla.org/en-US/docs/DOM/HTMLCanvasElement and started puking:

When trying to use types other than image/png , authors can check if the image was really returned in the requested format by checking to see if the returned string starts with one of the exact strings data:image/png, or data:image/png; . If it does, the image is PNG, and thus the requested type was not supported. (The one exception to this is if the canvas has either no height or no width, in which case the result might simply be data:, .)

If the type requested is not image/png, and the returned value starts with data:image/png, then the requested type is not supported.

Really? I have to check the returned STRING to know if there was an error? Go home HTML5, you re drunk! Okay, okay. No canvas rendered to images then. Let s just render the QR code as a <table> instead of a <canvas> when the browser looks like Opera. There is nothing one could do wrong with tables, right? But let s test with the basic example first: Yes, this is 2013. Yes, this is Opera 12.14. Yes, the rendering of a fucking HTML table is wrong. Needles to say, Iceweasel and Chromium render the example just fine. I bet even a recent Internet Explorer would That said, there is no bugfixworkaround for Opera I want to implement. If you use Opera, I feel sorry for you. But that s all. Update: before someone cries ZOMG! BUG PLZ!!! , I filled this as DSK-383716 at Opera.

0 comment(s) this blog is flattr enabled

The goal of this article is to illustrate how to manage Python code which includes comments in UTF-8 characters inside a latin-1 source org-mode for LaTeX export. Note that I ve pasted in wordpress the HTML generated by org-mode, so I hope it isn t broken too much. My typical use case is a french lecture on Python where the text is written in french, as well as some of the code comments and examples We ll use org-mode s babel module to include and manage the Python
examples. The goal is to write the source of the Python programs
directly in the same org source as the class book s text, and to extract them into a subdir (with the tangle feature), so that they can be shipped to the students to experiment with. The minted LaTeX environment is used, for babel, to make the Python syntax highlighting.

God hates people that are I heard a sentence that began that way on an interview with a protestor outside the Supreme Court yesterday. It is a deeply sad, and deeply wrong, statement. If someone reads the Bible, and can come up with a word, any word, that completes that sentence, they re doing it wrong. If someone thinks that there is anyone God hates, then I have this to say: No. Just no. I saw an article today, taking pages and pages to assess what the Christian response to gay marriage should be. I don t need pages. It s very simple. It s this: God is the God of love. That is all. Where people are doing good, there is God. Where people care about each other, there is God. Where there are flowers blooming and trees shading and birds singing, there is God. Where people marvel in the beauty of the landscape or of another person, there is God. And where people love, there is God. There is too much hate in the world already. Instead of adding more, let s celebrate compassion, devotion, and peace. People that say that God is the God of hate look at the spring landscape and see only last year s thistles. One day soon, I hope to see everyone s hearts set free. What a day of joy that will be! And I hope, too, that those that hate will find the peace of freed hearts, freed from hate and from fear.

A month ago, Mark Donfried from the Institute for Cultural Diplomacy (ICD) an organization dedicated to promoting open dialogue sent me this letter threatening me with legal action because of contributions I ve made to Wikipedia. Yesterday, he sent me this followup threat. According to the letters, Donfried has threatened me with legal action because I participated in a discussion on Wikipedia that resulted in his organization s article being deleted. It is not anything I wrote in any Wikipedia article that made Donfried so upset although Donfried is also unhappy about at least one off-hand comment I made during the deletion discussion on a now-deleted Wikipedia process page. Donfried is unhappy that my actions, in small part, have resulted in his organization not having an article in Wikipedia. He is able to threaten me personally because unlike many people I edit Wikipedia using my real, full, name. Donfried s letter is the latest step in a saga that has been ongoing since last June. It has been a frustrating learning experience for me that has made me worried about Wikipedia, its processes, and its future. In Wikipedia, debates can be won by stamina. If you care more and argue longer, you will tend to get your way. The result, very often, is that individuals and organizations with a very strong interest in having Wikipedia say a particular thing tend to win out over other editors who just want the encyclopedia to be solid, neutral, and reliable. These less-committed editors simply have less at stake and their attention is more distributed. The ICD is a non-profit organization based in Berlin. According to its own website, a large part of the organization s activities are based around arranging conferences. Its goals peace, cultural interchange, human rights are admirable and close to my heart. Its advisors and affiliates are impressive. I had never heard of the ICD before their founder, Mark Donfried, emailed me in April 2012 asking me to give a keynote address at their conference on The 2012 International Symposium on Cultural Diplomacy & Human Rights. I replied, interested, but puzzled because my own research seems very far afield of both cultural diplomacy (which I had never heard of) and human rights. I replied saying:

What would you like me to talk about I ask because I don t consider myself an expert in (or even particularly knowledgeable about) cultural diplomacy. Did someone else refer you to me?

Donfried replied with a long message seemingly copy and pasted thanking me for considering attending and asking me for details of my talk. I replied again repeating text from my previous email and asking why he was interested in me. Donfried suggested a phone call to talk about details. But by this point, I had looked around the web for information about the ICD and had decided to decline the invitation. Among things I found was a blog post by my friend James Grimmelmann that suggests that, at least in his case, the ICD had a history of sending unsolicited email and an apparently inability to take folks off their email lists even after repeated requests. I also read the Wikipedia article about the ICD. Although the Wikipedia article was long and detailed, it sent off some internal Wikipedian-alarm-bells for me. The page read, to me, like an advertisement or something written by the organization being described; it simply did not read to me like an encyclopedia article written by a neutral third-party. I looked through the history of the article and found that the article had been created by a user called Icd_berlin who had made no other substantive edits to the encyclopedia. Upon further examination, I found that almost all other significant content contributions were from a series of anonymous editors with IP addresses associated with Berlin. I also found that a couple edits had removed criticism when it had been added to the article. The criticism was removed by an anonymous editor from Berlin. Criticisms on the article included links to a website called Inside the ICD which was a website that mostly consisted of comments by anonymous people claiming to be former interns of the ICD complaining about the working conditions at the organization. There were also many very positive descriptions of work at the ICD. A wide array of pseudonymous users on the site accused the negative commenters of being liars and detractors and the positive commenters of being ICD insiders. I also found that there had been evidence on Wikipedia also removed without discussion by an anonymous IP from Berlin of an effort launched by the youth wing of ver.di one of the largest trade unions in Germany to campaign for good internships at the ICD. Although details of the original campaign have been removed from ver.di s website, the campaigned ended after coming to an agreement with the ICD that made explicit a set of expectations and created an Intern Council. Although the article about ICD on Wikipedia had many citations, many were to the ICD s own website. Most of the rest were to articles that only tangentially mentioned the ICD. Many were about people with ICD connections but did not mention the ICD at all. As Wikipedia editor, I was worried that Wikipedia s policies on conflict of interest, advertising, neutrality, and notability were not being served by the article in its state. But as someone with no real experience or knowledge of the ICD, I wasn t sure what to do. I posted a request for help on Wikipedia asking for others to get involved and offer their opinions. It turns out, there were several editors who had tried to improve the article in the past and had been met by pro-ICD editors reverting their changes. Eventually, those editors lost patience or simply moved on to other topics. By raising the issue again, I kicked off a round of discussion about the article. At the termination of that discussion, the article was proposed for deletion under Wikipedia s Articles for Deletion policy. A new Wikipedia editor began working enthusiastically to keep the article by adding links and by arguing that the article should stay. The new user edited the Wikipedia article about me to accuse me of slander and defamation although they removed that claim after I tried to explain that I was only trying to help. I spent quite a bit of time trying to rewrite and improve the article during the deletion discussion and I went link by link through the many dozens of citations. During the deletion discussion, Mark Donfried contacted me over email and explained that his representatives had told him that I was working against the ICD in Wikipedia. He suggested that we meet. We had a tentative plan to meet in Berlin on an afternoon last July but, in the end, I was too busy trying to submit my thesis proposal and neither of us followed up to confirm a particular time within the time window we had set. I have still never met him. My feeling, toward the end of the deletion discussion on Wikipedia, was mostly exasperation. Somewhat reluctantly, I voted to delete the article saying:

Delete This AFD is a complete mess for all the reasons that the article itself is. Basically: there are a small number of people who seem to have a very strong interest in the Institute for Cultural Diplomacy having an article in Wikipedia and, from what I can tell, very little else. Hessin fahem, like all the major contributors to the page, joined Wikipedia in order to participate in this issue. This article has serious problems. I have posted a detailed list of my problems on the article talk page: primary sources, conflict of interest for nearly all substantive contributions and reading like an advert are the biggest issues. My efforts to list these problems were reverted without discussion by an anonymous editor from Berlin. I have seen no evidence that the Institute for Cultural Diplomacy satisfies WP:ORG but I agree that it is possible that it does. I strongly agree with Arxiloxos that articles should always be fixed, and not deleted, if they are fixable. But I also know that Wikipedia does not deserve this article, that I don t know to fix it, and that despite my efforts to address these issues (and I ll keep trying), the old patterns of editing have continued and the article is only getting worse. This ICD seems almost entirely based around a model that involves organizing conferences and then calling and emailing to recruit speakers and attendees. A large number of people will visit this Wikipedia article to find out more about the organization before deciding to pay for a conference or to join to do an internship. What Wikipedia shows to them reads like an advert, links almost exclusively to of pages on the organizations websites and seems very likely to have been written by the organization itself. We are doing an enormous disservice to our readers by keeping this page in its current form. If somebody wants to make a serious effort to improve the article, I will help and will happily reconsider my !vote. But after quite a bit of time trying to raise interest and to get this fixed, I m skeptical this can be addressed and my decision reflects this fact. mako 05:18, 12 June 2012 (UTC)

I concluded that although the organization might be notable according to Wikipedia s policies and although the Wikipedia article about it might be fixable, the pattern of editing gave me no faith that it could be fixed until something changed. When the article was deleted, things became quiet. Several months later a new article was created again, by an anonymous user with no other edit history. Although people tend to look closely at previously deleted new pages, this page was created under a different name: The Institute of Cultural Diplomacy and was not noticed. Deleted Wikipedia articles are only supposed to be recreated after they go through a process called deletion review. Because the article was recreated out of this process, I nominated it for what is called speedy deletion under a policy specifically dealing with recreated articles. It was deleted again. Once again, things were quiet. In January, it seems, the Inside the ICD website was threatened with a lawsuit by the ICD and the maintainers of the site took it down with the following message:

Apparently, the ICD is considering filing a lawsuit against this blog and it will now be taken down. We completely forgot about this blog. Let s hope no one is being sued. Farewell.

On February 25, the Wikipedia article on ICD was recreated once again out of process and by a user with almost no previous edit history. The next day, I received an email from Mark Donfried. In the message, Donfried said:

Please note that the ICD is completely in favor of fostering open dialogue and discussions, even critical ones, however some of your activities are raising serious questions about the motives behind your actions and some even seem to be motives of sabotage, since they resulted in ICD not having any Wikipedia page at all. We are deeply concerned regarding these actions of yours, which are causing us considerable damages. As the person who initiated these actions with Wikipedia and member of the board of Wikipedia [1], we would therefore request your answer regarding our questions below within the next 10 days (by March 6th). If we do not receive your response we will unfortunately have to consider taking further legal actions with these regards against you and other anonymous editors.

I responded to Donfried to say that I did not think it was prudent to speak with him while he was threatening me. Meanwhile, other Wikipedia editors nominated the ICD article for deletion once again and unanimously decided to delete it. And although I did not participate in the discussion, Donfried emailed again with more threats of legal action hours after the ICD article was deleted:

[A]s the case of the ICD and its presentation on the Wikipedia has seriously worsened in recent days, we see no alternative but to forward this case (including all relevant visible and anonymous contributors) to our legal representatives in both USA and Europe/Germany as well as to the authorities and other corresponded organizations in order to find a remedy to this case.

Donfried has made it very clear that his organization really wants a Wikipedia article and that they believe they are being damaged without one. But the fact that he wants one doesn t mean that Wikipedia s policies mean he should have one. Anonymous editors in Berlin and in unknown locations have made it clear that they really want a Wikipedia article about the ICD that does not include criticism. Not only do Wikipedia s policies and principles not guarantee them this, Wikipedia might be hurt as a project when this happens. The ICD claims to want to foster open dialogue and criticism. I think they sound like a pretty nice group working toward issues I care about personally. I wish them success. But there seems to be a disconnect between their goals and the actions of both their leader and proponents. Because I used my real name and was skeptical about the organization on discussion pages on Wikipedia, I was tracked down and threatened. Donfried insinuated that I was motivated to sabotage his organization and threatened legal action if I do not answer his questions. The timing of his first letter the day after the ICD page was recreated means that I was unwilling to act on my commitment to Wikipedia and its policies. I have no problem with the ICD and I deeply regret being dragged into this whole mess simply because I wanted to improve Wikipedia. That said, Donfried s threat has scared me off from attempts to improve the ICD articles. I suspect I will not edit ICD pages in Wikipedia in the future. The saddest part for me is that I recognize that what is in effect bullying is working. There are currently Wikipedia articles about the ICD in many languages. For several years, ICD has had an article on English Wikipedia. For almost all of that period, that article has consisted entirely of universally positive text, without criticism, and has been written almost entirely by anonymous editors who have only contributed to articles related to the ICD. In terms of the ICD and its article on Wikipedia, I still have hope. I encourage Donfried and his representatives to create accounts on Wikipedia with their full names just like I have. I encourage them to engage in open dialogue in public on the wiki. I encourage them go through deletion review, make any conflicts of interest they have unambiguously clear, and to work with demonstrably non-conflicted editors on Wikipedia to establish notability under Wikipedia s policies. The result still can be an awesome, neutral, article about their organization. I have offered both advice on how to do this and help in that process in the past. I have faith this can happen and I will be thrilled when it does. But the general case still worries me deeply. If I can be scared off by threats like these, anybody can. After all, I have friends at the Wikimedia Foundation, a position at Harvard Law School, and am close friends with many of the world s greatest lawyer-experts on both wikis and cyberlaw. And even I am intimidated into not improving the encyclopedia. I am concerned by what I believe is the more common case where those with skin in the game will fight harder and longer than a random Wikipedian. The fact that it s usually not me on the end of the threat gives me lots of reasons to worry about Wikipedia at a time when its importance and readership continues to grow as its editor-base remains stagnant.

[1]	It s a minor mistake but worth pointing out that I am not on the board of Wikipedia ; I am on its advisory board which carries no power or responsbility within the organization. Sometimes, the foundation asks for my advice and I happily give it.

I gave a presentation at Libreplanet this weekend on the topic of Secure Boot and Restricted Boot. There's a copy of the video here - it should be up on the conference site at some point. It turned out to be excellent timing, in that a group in Spain filed a complaint with the European Commission this morning arguing that Microsoft's imposition of Secure Boot on the x86 client PC market is anticompetitive. I suspect that this is unlikely to succeed (the Commission has already stated that the current implementation appears to conform to EU law), and I fear that it's going to make it harder to fight the real battle we face.

Secure Boot means different things to different people. I think the FSF's definition is a useful one - Secure Boot is any boot validation scheme in which ultimate control is in the hands of the owner of the device, while Restricted Boot is any boot validation scheme in which ultimate control is in the hands of a third party. What Microsoft require for x86 Windows 8 devices falls into the category of Secure Boot - assuming that OEMs conform to Microsoft's requirements, the user must be able to both disable Secure Boot entirely and also leave Secure Boot enabled, but with their own choice of trusted keys and binaries. If the FSF set up a signing service to sign operating systems that met all of their criteria for freeness, Microsoft's requirements would permit an end user to configure their system such that it refused to run non-free software. My system is configured to trust things shipped by Fedora or built locally by me, a decision that I can make because Microsoft require that OEMs support it. Any system that meets Microsoft's requirements is a system that respects the freedom of the computer owner to choose how restrictive their computer's boot policy is.

This isn't to say that it's ideal. The lack of any common UI or key format between hardware vendors makes it difficult for OS vendors to document the steps users must take to assert this freedom. The presence of Microsoft as the only widely trusted key authority leaves people justifiably concerned as to whether Microsoft will be equally aggressive in blacklisting its own products as it will be in blacklisting third party ones. Implementation flaws in a (very) small number of systems have resulted in correctly signed operating systems failing to boot, requiring users to update their firmware before being able to install anything but Windows.

But concentrating on these problems misses the wider point. The x86 market remains one where users are able to run whatever they want, but the x86 market is shrinking. Users are purchasing tablets and other ARM-based ultraportables. Some users are using phones as their primary computing device. In contrast to the x86 market, Microsoft's policies for the ARM market restrict user freedom. Windows Phone and Windows RT devices are required to boot only signed binaries, with no option for the end user to disable the signature validation or install their own keys. While the underlying technology is identical, this differing set of default policies means that Microsoft's ARM implementation is better described as Restricted Boot. The hardware vendors and Microsoft define which software will run on these systems. The owner gets no say.

And, unfortunately, Microsoft aren't alone. Apple, the single biggest vendor in this market, implement effectively identical restrictions. Some Android vendors provide unlockable bootloaders, but others (either through personal preference or at the behest of phone carriers) lock down their platforms. A naive user is likely to end up purchasing a device that will, in the absence of exploited security flaws, refuse to run if any system components are modified. Even in cases where the underlying components are built using free software, there's no guarantee that the user will have the ability to assert any of those freedoms.

Why does this matter? Some of these platforms (notably Windows RT and iOS, but also some Android-based devices) will even refuse to run unsigned applications. Users are unable to write their own software and distribute it to others without agreeing to often onerous restrictions. Users with the misfortune of living in the wrong country may be forbidden from even that opportunity. The vendor may choose to block applications that compete with their own, reducing innovation. The ability to explore and tinker with the components of the system is restricted, making it harder for users to learn how modern operating systems work. If I own a perfectly functional phone that no longer receives vendor updates, I don't even have the option of paying a third party to ensure that I can't be compromised by a malicious website and risk the loss of passwords or financial details. The user is directly harmed by these restrictions.

I won't argue that there are no benefits to curated software ecosystems. I won't even argue against devices shipping with a locked down policy by default. I will strongly argue that the owner of a device should not only have the freedom to choose whether they wish to remain within those locked-down boundaries, but should also have the freedom to impose their own boundaries. There should be no forced choice between freedom and security.

Those who argue against Secure Boot risk depriving us of the freedom to make a personal decision as to who we trust. Those who argue against Secure Boot while ignoring Restricted Boot risk depriving us of even more. The traditional PC market is decreasing in importance. Unless we do anything about it, free software will be limited to a niche group of enthusiasts who've carefully chosen from a small set of devices that respect user freedom. We should have been campaigning against Restricted Boot 10 years ago. Don't delay it even further by fighting against implementations that already respect user freedom.

comments

Would you like to help the environment and save money at the same time, without much sacrifice? A small step could be to change the font you use when printing. Three years ago, Ars Technica reported how the University of Wisconsin-Green Bay changed their default front from Arial to Century Gothic to save money. The Century Gothic font uses 30% less toner than Arial to print the same text. In other word, you could cut your toner costs by 30% (or actually, increase your toner supply life time by more than 30%), by simply changing the default font used in your prints. But it is not quite obvious how much one will safe by switching. The University of Wisconsin-Green Bay said it used $100,000 per year on ink and toner cartridges, according to a report from TwinCities.com, and expected to save between $5,000 and $10,000 per year by asking staff and students to use a different font. Not all PDFs and documents are created internally, and those from external sources will most likely still use a different font. Also, the Century Gothic font is slightly wider than Arial, and thus might use more sheets of paper to print the same text, so the total saving depend on the documents printed. But it is definitely something to consider, if you want to reduce the amount of trash, decrease the amount of toner used in the world, and save some money in the process.

We were lazy and wrote a simple PostgreSQL monitoring check in shell instead of using some proper language. The code looked about this:

out=$(psql -tAc "SELECT some_stuff, t > now() - '1 day'::interval FROM some_table" some_db 2>&1)
case $out in
    *t) echo "OK: $out" ;;
    *) echo "NOT OK: $out" ;;
esac

If the string ends with 't', all is well, if it ends with 'f' or someting else, something is wrong. Unfortunately, this didn't go that well: OK: psql: FATAL: database "some_db" does not exist

But you can t just tar.gz up the bare repositories on the server and hope for the best. Maybe a given repository will be in a valid state; maybe it won t.

-- Jeff Mitchell in a followup to the recent KDE near git disaster This was a surprising statement to me. I seem to remember that one of (many) selling points for git talked about back in the day was that it avoided the problem that making a simple cp (or backup) of a repository could lead to an inconsistent result. A problem that subversion repositories had, and required annoying commands to work around. (svnadmin $something -- iirc the backend FSFS fixed or avoided most of this issue.) This prompted me to check how I handle it in ikiwiki-hosting. I must have anticipated a problem at some point, since ikisite backup takes care to lock the git repository in a way that prevents eg, incoming pushes while a backup is running. Probably, like the KDE developers, I was simply exercising reasonable caution. The following analysis has probably been written up before (train; limited network availability; can't check), but here are some scenarios to consider:

• A non-bare repository has two parts that can clearly get out of sync during a backup: The work tree and the .git directory.
  • The .git directory will likely be backed up first, since getdirent will typically return it first, since it gets created first . If a change is made to the work tree during that backup, and committed while the work tree is being backed up, the backup won't include that commit -- which is no particular problem and would not be surprising upon restore. Make commit again and get on with life.
  • However, if (part of) the work tree is backed up before .git, then any changes that are committed to git during the backup would not be reflected in the restored work tree, and git diff would show a reversion of those changes. After restore, care would need to be taken to reset the work tree (without losing any legitimate uncommitted changes).
• A non-bare repository can also become broken in other ways if just the wrong state is snapshotted. For example, if a commit is in progress during a backup, .git/index.lock may exist, and prevent future commits from happening, until it's deleted. These problems can also occur if the machine dies at just the right time during a commit. Git tells you how to recover. (git could go further to avoid these problems than it does; for example it could check if .git/index.lock is actually locked using fcntl. Something I do in git-annex to make the .git/annex/index.lock file crash safe.)
• A bare repository could be receiving a push (or a non-bare repository a pull) while the backup occurs. These are fairly similar cases, with the main difference being that a non-bare repository has the reflog, which can be used to recover from some inconsist states that could be backed up. Let's concentrate on pushes to bare repositories.
  • A pack could be in the process of being uploaded during a backup. The KDE developers apparently worried that this could result in a corrupt or inconsistent repository, but TTBOMK it cannot; git transfers the pack to a temp file and atomically renames it into place once the transfer is complete. A backup may include an excess temp file, but this can also happen if the system goes down while a push is in progress. Git cleans these things up.
  • A push first transfers the .git/objects, and then updates .git/refs. A backup might first back up the refs, and then the objects. In this case, it would lose the record that refs were pushed. After being restored, any push from another repository would update the refs, even using the objects that did get backed up. So git recovers from this, and it's not really a concern.
  • Perhaps a backup chooses to first back up the objects, and then the refs. In this case, it could back up a newly changed ref, without having backed up the referenced objects (because they arrived after the backup had finished with the objects). When this happens, your bare repository is inconsistent; you have to somehow hunt down the correct ref for the objects you do have. This is a bad failure mode. git could improve this, perhaps, by maintaining a reflog for bare repositories. (Update: core.logAllRefUpdates can be set to true for bare repositories, but is disabled by default.)
• A "backup" of a git repository can consist of other clones of it. Which do not include .git/hooks/ scripts, .git/config settings, and potentially other valuable information, that strangely, we do not check into revision control despite having this nice revision control system available. This is the most likely failure mode with "git backups". :P

I think that it's important git support naive backups of git repositories as well as possible, because that's probably how most backups of git repositories are made. We don't all have time to carefully tune our backup systems to do something special around our git repositories to ensure we get them in a consistent state like the KDE project did, and as their experience shows, even if we do it, we can easily introduce other, unanticipated problems. Can anyone else think of any other failure modes like these, or find holes in my slightly rushed analysis?

---

PS: git-annex is itself entirely crash-safe, to the best of my abilities, and also safe for naive backups. But inherits any problems with naive backups of git repositories.

Since a while

I am a proud

On the other hand I should probably put up my own, local, list of found caches, considering what happened to me on Open caching. And maybe write intros for people new to geocaching, since it d be virtually no work now had I done it initially. (And for fanfiction readers! I wish I d kept a list of read fics, not just of these I currently read and/or are currently unfinished.)

I've made two new designs for Trunk Tees, my Cafepress store. Thank you to Richard Braakman for suggesting the .* one. Here's all the older designs as well:

I ve been using this process for debugging the installer while launched from a Debian Live desktop. Having a full live environment at your disposal during install is a boon to debugging because you don t have to work within the constraints normally imposed upon you by the limited debian-installer environment. Caveat: running debian-installer from the debian-installer-launcher still has one or two unresolved issues, so unless you re specifically working on live integration issues like I am, compare with a conventional d-i image install to gain the added confidence the install is the same in both environments. There are no longer active maintainers working on debian-installer-launcher and live-installer, and I think it s really important for wheezy to release with solid support for live installs, so I ve been using this setup to try to solve #702335. So far, progress is slow because I m new to this. If anyone is interested in collaborating in this work, give me a shout. I am SynrG @ irc.oftc.net and can be found on #debian-live and #debian-boot if you would like to drop in. Overview:

1. Use images/lxde-desktop config from live-images.git and build your own image with live-build >=3.0.1-1. Just add -b hdd in auto/config before starting your build, as having a read/writable image is handy for this exercise.
2. Boot the live medium. You may prefer to do this in a VM for convenience, having prepared a blank virtual disk image as your target in advance.
3. Make any small changes you want to the installer before launching it. A quick hack I ve used is to sudo vi /usr/sbin/debian-installer-launcher and near the end on the line after prepare right before run , open a new line and add bash so an interactive shell will be opened after the installer is extracted but before it is launched. For larger changes (e.g. inclusion of updated udebs, etc.) add them to your live image configuration before building as described in live-manual.
4. Open two root terminals and do debian-installer-launcher -t debug in one and tail -f /lib/live/installer/var/log/syslog in the other. If you ve added the hack from step 3, don t forget to exit the interactive shell after making changes. Now you can watch debug output as you go through the steps of the installer. If you like, you may append additional boot prompt parameters (e.g. preseeds) to the debian-installer-launcher command.
5. During the install, you may modify other parts of the unpacked installer under /lib/live/installer (e.g. to add set -x to some scripts) prior to executing steps that would call them.

The 2nd Shogi Denousen has began. This is the first cut-throat match between top-notch professional Shogi players(yes, there are such people) and the best crop of computer Shogi engines, 5 on 5. Shogi is a distant cousin of Chess. Unlike Chess, you may re-use captured pieces anywhere on the board anytime. It brings quite lot of additional complexities, and even after the defeat of Garry Kasparov in 1997, many considered that (at least top-level) human Shogi players have a great lead on computer Shogi engines. The situation had changed dramatically when a newcomer Shogi engine called Bonanza, developed by a Japanese chemist Kunihito Hoki, won the 16th World Computer Shogi Championship. Bonanza appeared totally out of the blue Hoki incorporated some new ideas developed in the field of computer Chess, and Bonanza beated existing engines with no mercy. Bonanza could even corner some professional Shogi players in 2007. Later Hoki released(but not strictly open-source) the source code of Bonanza, and the standard of computer Shogi has risen considerably since then. Finally, in the 1st Denousen last year, Kunio Yonenaga, long retired but possibly one of the greatest Shogi players in the history, was defeated by Bonkras, a clustered version of Bonanza developed by Eiki Itoh of Fujitsu. The first match of Denousen this year was held yesterday between Kouru Abe, an 18-year old prodigy from Aomori, and Shueso, which finished in 5th at the 22nd World Computer Shogi Championship. I hoped a close game, but Abe could beat Shueso quite easily. Shueso somehow could not bring its ability into full play, to my great disappointment. Next weekend(Mar. 30), we will see the second match between Shinichi Sato, another young pro, and Ponanza, developed based on Bonanza by Issei Yamamoto of The University of Tokyo. BTW, Debian already has the package of GPS Shogi, which won the 22nd World Computer Shogi Championship and considered by many the strongest Shogi engine available now (there is also gnushogi in Debian, but gnushogi is quite weak). You may have fun with

    $ xshogi -fsp gpsshogi

Unfortunately, we don t have good modern GUI for Shogi yet

A new relase 0.10.3 of Rcpp is now on CRAN and in Debian. This is the fourth release in the 0.10.* series, and further extends and solidifies the excellent Rcpp attributes. A few other bugs were fixed as well, and support for wide character strings has been added. We once again tested this fairly rigorously by checking against 86 of the 100 CRAN packages depending on Rcpp. All of these passed. So we do not expect any issues with dependent packages, but one never knows. The complete NEWS entry for 0.10.3 is below; more details are in the ChangeLog file in the package and on the Rcpp Changelog page.

Changes in Rcpp version 0.10.3 (2013-03-23)

• Changes in R code:
  • Prevent build failures on Windowsn when Rcpp is installed in a library path with spaces (transform paths in the same manner that R does before passing them to the build system).
• Changes in Rcpp attributes:
  • Rcpp modules can now be used with sourceCpp
  • Standalone roxygen chunks (e.g. to document a class) are now transposed into RcppExports.R
  • Added Rcpp::plugins attribute for binding directly to inline plugins. Plugins can be registered using the new registerPlugin function.
  • Added built-in cpp11 plugin for specifying the use of C++11 in a translation unit
  • Merge existing values of build related environment variables for sourceCpp
  • Add global package include file to RcppExports.cpp if it exists
  • Stop with an error if the file name passed to sourceCpp has spaces in it
  • Return invisibly from void functions
  • Ensure that line comments invalidate block comments when parsing for attributes
  • Eliminated spurious empty hello world function definition in Rcpp.package.skeleton
• Changes in Rcpp API:
  • The very central use of R API R_PreserveObject and R_ReleaseObject has been replaced by a new system based on the functions Rcpp_PreserveObject, Rcpp_ReleaseObject and Rcpp_ReplaceObject which shows better performance and is implemented using a generic vector treated as a stack instead of a pairlist in the R implementation. However, as this preserve / release code is still a little rough at the edges, a new #define is used (in config.h) to disable it for now.
  • Platform-dependent code in Timer.cpp now recognises a few more BSD variants thanks to contributed defined() test suggestions
  • Support for wide character strings has been added throughout the API. In particular String, CharacterVector, wrap and as are aware of wide character strings

Thanks to CRANberries, you can also look at a diff to the previous release 0.10.2. As always, even fuller details are on the Rcpp Changelog page and the Rcpp page which also leads to the downloads, the browseable doxygen docs and zip files of doxygen output for the standard formats. A local directory has source and documentation too. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page