Today was my first day as the new executive director at the Free Software Foundation. I'm really excited about the opportunity to do more at the FSF -- but also sad that I won't have the pleasure of working with Peter Brown any more, as he is moving on to more challenges. Peter's been an amazing mentor and boss to me in the eight years I've been with the FSF, and it's not going to be the same without him. Along with the change in job positions, I have relocated from Seattle back to Boston. This continues to be my personal space, not an official FSF channel -- but this is big personal news for me so I wanted to share :).

... or don't shoot yourself in the foot. This is not a big secret, Debian Squeeze has been released. Right after this event, the OCaml Debian Task force was back in action -- with Stephane in the leading role. He has planned the transition to OCaml 3.12.0. We will proceed in two steps: a small transition of a reduced set of packages that can be transitioned before 3.12 and then the big transition. The reason for the small transition, is to avoid having to dep-wait (waiting for dependencies) of package upload by human. In -- a not so far -- past, the OCaml Debian Task force members were uploading packages by hand and waited for a full rebuild to go to the next step. This was long and cumbersome. We use now binNMU: it is binary only uploads -- with no source changes -- processed automatically by the release team and its infrastructure. This is far more effective and helps us to reduce the delay of the transition... The small transition is happening now!!! Don't update/upgrade your critical Debian installations with OCaml packages, you'll get a lot of removal if you do so. N.B. these removal are part of the famous Enforcing type-safe linking using package dependencies paper. As a side note, I am happy to announce that a full round of new OCaml packages has landed in Debian unstable:

• caml2html
• camlmix
• camltemplate
• cppo
• easy-format
• mikmatch
• atd
• ocaml-data-notation
• deriving
• ocaml-expect
• ocaml-extunix
• ocaml-inifiles
• ocaml-sqlexpr
• ocamlify
• tophide
• xstrp4
• yojson
• atdgen
• biniou

People aware of my current work, should notice that all the dependencies of OASIS are now in Debian unstable: ocaml-data-notation, ocamlify, ocaml-expect. This is a hint about the next OCaml Debian package, I will upload. You can also have a look at OASIS enabled packages (all the OASIS dependencies, ocaml-sqlexpr and ocaml-extunix). These packages have been generated using oasis2debian a tool to convert _oasis into debian/ packaging files. After these transition we will continue proceeding with standard upgrade work (e.g. camomile to 0.8.1). Sylvain Le Gall is an OCaml consultant working for OCamlCore SARL

Continuing my series about a desktop in a shell, today I will present you my mutt setup. I use mutt because it has no bugs and is a really good MUA for people loving consoles ;)First of all you have to know, that all my mail is forwarded to my server and sorted into Maildirs via maildrop, so I do not care about sorting on my desktop , which just fetches the mail via IMAP from the server ;)I m running mutt-patched from Debian Squeeze, so not all options may be available for you if you do not have the same patchset as I do.First, tell mutt to fetch mail from imap.die-welt.net via IMAP:

set imap_user=username
set imap_pass=password
set folder="imaps://imap.die-welt.net/INBOX"
set spoolfile="imaps://imap.die-welt.net/INBOX"

Now, enable IMAP-IDLE, list subscribed folders, reconnect to the server if needed and mark mail as read when you open it:

set imap_idle
set imap_check_subscribed
unset imap_passive
unset imap_peek

Let mutt save sent mail to the Sent directory on the IMAP server, and postponed mail to Drafts:

set record=+Sent
set postponed=+Drafts

Read mail should stay where it is:

set mbox="!"

We use IMAP-IDLE, thus check for new mail manually only every 90 seconds:

set mail_check=90

Instead timeout after 15 seconds if no user input is given:

set timeout=15

Set default mail from address to my default mail address:

set from=evgeni@golov.de

And send mail via mstmp (see below for mstmp configuration):

set sendmail="/usr/bin/msmtp"

Tell mutt which addresses I recieve mail to (danger, ugly regex!):

alternates (evgeni@(debian.org golov.(de eu)) sargentd@(die-welt sargentd).net evgeni.golov@uni-duesseldorf.de)

As mutt knows where I receive mail, let it set From accordingly:

set reverse_name

Let mutt cache some stuff and find its certificates:

set header_cache="~/.mutt/cache/headers"
set message_cachedir="~/.mutt/cache/bodies"
set certificate_file=~/.mutt/certificates
set ssl_ca_certificates_file=/etc/ssl/certs/ca-certificates.crt

Show only interesting headers in an useful order:

ignore headers *
unignore headers from to subject date cc
hdr_order from to cc subject date

Fix stupid MUAs behaviour (e.g. filenames like =?iso-8859-1?Q?file=5F=E4=5F991116=2Ezip?=):

set rfc2047_parameters

Beep on new mail, will generate a ! in the window name in screen:

set beep_new

mutt-patched has the great sidebar patch, assign ctrl-n, ctrl-p to select next, prev folder, ctrl-o to open selected folder:

bind index \Cp sidebar-prev
bind index \Cn sidebar-next
bind index \Co sidebar-open

And toggle sidebar visibility with ctrl-b:

macro index \Cb '<enter-command>toggle sidebar_visible<enter><refresh>'
macro pager \Cb '<enter-command>toggle sidebar_visible<enter><redraw-screen>'

Since 1.5.20-2, mutt patched contains my sidebar-dotted and sidebar-sorted patches.
Let mutt shorten the displayed path (e.g. debian-devel instead of INBOX.ml.debian-devel) and sort the folders (the are returned in random order when using imap_check_subscribed):

set sidebar_shortpath
set sidebar_sort

Now let s set some colors (that match the rest of my desktop ):

color sidebar_new yellow default
color normal white default
color hdrdefault brightcyan default
color signature green default
color attachment brightyellow default
color quoted green default
color quoted1 white default
color tilde blue default

And add some useful macros for marking new and old messages as read:

macro index .n "<tag-pattern>~N<enter><tag-prefix><clear-flag>N<clear-flag>*" "Catchup all new messages"
macro index .o "<tag-pattern>~O<enter><tag-prefix><clear-flag>O<clear-flag>*" "Catchup all old messages"

When forwarding mail, I like it to be forwarded as an attachment (YMMV):

set mime_forward=yes

I m using goobook in mutt to fetch my addressbook from Google. As there is no Debian package for goobook (yet), you have to install it yourself (via easy_install):

apt-get install python-argparse python-gdata python-simplejson python-keyring python-nose
easy_install goobook

Configuration is easy via ~/.goobookrc:

[DEFAULT]
# If not given here, email and password is taken from .netrc using
# machine google.com
email: me@gmail.com
password: password

And then add the following to your .muttrc:

set query_command="goobook query '%s'"
bind editor  complete-query
macro index,pager a "<pipe-message>goobook add<return>" "add the sender address to Google contacts"

That s all for mutt, but We are running mutt in a screen, so let s add the following to .screenrc to fix transparency and cut&paste (see http://wiki.mutt.org/?MuttFaq/Appearance):

 defbce on
 term screen-bce

And as mutt uses mstmp (yes, I know, mutt can handle SMTP itself ), this is my .msmtprc:

defaults
domain dorei.kerker.die-welt.net
tls on
account die-welt.net
host smtp.die-welt.net
from sargentd@die-welt.net
auth on
user username
password password
tls_starttls on
tls_certcheck off
# Set a default account
account default : die-welt.net

C est tout! That is my personal mutt configuration, you can download it as one file here: my .muttrc. And as everyone loves screenshots, here is one:Oh, the next chapter will be about irssi, but not before next Sunday (March 6th) as I ll be offline for a week, skiing in Austria :)

Short version: Dear FSF, thanks for your appreciation of Debian Squeeze achievements in getting rid of non-free firmware blobs. We still disagree on the overall freeness assessment of Debian, but I'm positive that steps like this one can further future collaboration, in the interest of both projects. Long version follows.

---

Historically, the relationships among Debian and the FSF have gone through mixed fortune (and that's quite an euphemism). On the one hand, Debian is committed to 100% Free Software, is an open project explicitly inspired by "the spirit of GNU", has been sponsored by FSF in its infancy, and properly calls itself "GNU/Linux" (or even "GNU/kFreeBSD"). On the other hand, Debian is the project who considers the GNU FDL license to be only conditionally free and which is not considered to be an entirely Free system according to FSF.
So much for the history corner. As a long time member of the Debian Project, as well as an FSF(E) fellow, I've always felt a bit sad about this state of affairs. Not because the two projects should have aligned goals; they clearly focus on different aspects of the quest for a Free (Software) world. Not even because they should agree on how to build a Free distribution: history has shown that FSF technical positions do not always get along with Debian's more "pragmatic" style, as embodied by point 5 of the Social Contract. Rather, my sadness is rooted in the belief that not getting along have encouraged duplication of efforts which could have been easily avoided (e.g. multiple distributions concurrently freeing up kernels). Furthermore, I'm more and more convinced that Debian nowadays enjoys a rather privileged position among Free Software vendors. Indeed, even though GNU/Linux distributions have reached a popularity we didn't dare to imagine 15 years ago or so, most distributions are under the direct or indirect control of commercial vendors. Those commercial vendors play a very important role in the promotion of Free Software. For instance, they are structured in ways that enable them to seal OEM deals with hardware manufacturers to sell computers with GNU/Linux pre-installed. Commercial vendors, by their own nature, are also in general better at marketing than non-commercial vendors. On the flip side however, commercial vendors are not yet relevant enough to drive proprietary drivers out of the market and, as a consequence, cannot yet afford not to support hardware which need such proprietary bits to work. Among mainstream GNU/Linux distributions[1] Debian is one of the very few vendors if not the only one that is both very relevant and, thanks to its independence, can afford taking Free Software's side: no commercial urgency can force Debian to negotiate on that. That is quite an asset to be used in the promotion of Free Software, especially to a public that is interested in and willing to understand what Free Software really is about. Such an "aware" public is on the rise as of lately, together with the general awareness increase of risks entailed by living a digital life, when that life is not under our control (think, as an example, at how often the "Facebook privacy debate" has hit mainstream medias in the last year). The "aware" public is the natural target of both Debian and the FSF. Dividing it would not serve well the cause of Free Software. With all that in mind, last August I took the chance of being on the "right" side of the Atlantic Ocean for DebConf10, to discuss possible venues of collaboration among Debian and the FSF. I sat down and discussed at length with John Sullivan, who I happen to know for his Debian involvement, in his capacities of FSF representative and operations manager. We discussed various topics, with the intention of bringing them up to the respective communities[2]. Then, inevitably, we ended up talking about the overall freeness of Debian and his exclusion from FSF listing of Free systems. (FSF is of course entitled to such judgements, pretty much as Debian is entitled to its own judgements on FSF licenses. Nevertheless those judgements contribute to dividing our public and might lead to wasteful duplication of efforts, where Free Software could better be served by collaboration.) The main ground for exclusion from that list used to be the compromises Debian has made in the past about non-free firmware blobs. But, as I pointed out back in August, those compromises would have been gone starting with Squeeze, making that argument moot. Today 6 months later I'm delighted to cheer at FSF's decision to publicly recognize the achievements Debian has delivered with Squeeze.
Thanks! It's a nice gesture that I've very much appreciated. I'm confident steps like this one will help future collaboration if, on both sides, we will be able to spot actual venues for collaboration. Needlessly to say, I still disagree with the overall FSF assessment of Debian non-freeness. Apparently, it still stands on the basis that Debian also provides a repository of nonfree software [ ] [which] is not part of the Debian system. [ ] but users would be hard-pressed to make a distinction and that people can readily learn about software available through it by browsing Debian's online package database. I respect the principle of non advertising non-free software and I even agree that it is a good principle. But unfortunately it's also a very blurry principle on which, in my opinion, Debian actually scores very well. No non-free software is offered to users by Debian; it's just for users that really want to have non-free software (or need to, in order to run a Free OS on their computers), that Debian tries to stay out of their way. For the "aware" public discussed above, I think it's much better to draw the line where software freedom ends and use that line to explain what does crossing it entails, than locking them up pretending non-free software do not exist. But fair enough: for the time being, I guess, we will need to agree to disagree on this one. Getting a little bit closer in the occasion of the Squeeze release is still an important step forward. It's up to each of us now to seek out initiatives which attract the interest of both projects and that can benefit from synergies.

---

[1] Sorry, I've no decent definition of "mainstream distribution" to offer, besides folklore and well-established distribution review sites. (Heck, I don't even have a decent definition of "well-established distribution review site" to offer!).
[2] which hasn't happened yet, due to the proverbial amount of available spare time.

In Bits from the Security Team a few weeks ago, Thijs Kinkhorst wrote:

Since a couple of years we ve been handing off security issues of minor or
theoretical impact but for which a fix would be desirable at some point, like
certain classes of denial-of-service attacks, off to stable point updates.
We re looking for a person that wants to coordinate this: monitor the Security
Tracker for issues classified as such by the Security Team, converse with
maintainers to get such updates done and coordinate with the stable release
managers on this.

I m happy to confirm, now that it s been announced, that I am that person: point release security co-ordinator. Affected packages If your package fulfils these criteria:

• it had a security problem reported in the past (that is, it was allocated a CVE number);
• it didn t get a Debian Security Advisory, but it wasn t marked unimportant in our tracker;
• it has been fixed in unstable, but the version in stable or oldstable is still vulnerable

it is a candidate for updating in stable or oldstable, and you ll probably receive a mail from me at some point asking you to do so. You can pre-empt this mail of course, by backporting your fix to the affected versions and contacting the release team to get your fix into stable, without waiting for me. In such a case, please drop me a note with the details so I can tick your off on my hit^W candidate list. Making a stable/oldstable upload This is documented in the Developer s Reference, but to summarise:

1. Prepare your fix, targetting stable or oldstable, and build it in an up-to-date chroot for that release
2. Send a diff of the new package to the release team, asking for permission to upload
3. Upload as normal, and wait for it to be included in the next point release. Meanwhile, notify the security team of your upload, if it fixes a CVE.

Tracking candidate packages I m going to start off tracking filed bugs for SPU candidates and OSPU candidates with usertags in the BTS, under my own address. In time that might be merged into an address used by the security team, but for now I m still finding a good workflow so it s much easier this way.

---

Point Release Security Co-ordinator is a post from: jwiltshire.org.uk Flattr

My FSF colleague Brett Smith and I will be making the case against software patents on a panel at the Churchill Club in Mountain View, CA, the evening of February 16th. Hope to see End Software Patents supporters in the audience! More information: Churchill Club Panel Discussion on Software Patents Free Software Foundation working together for free software

... yet it is not a Belgian final. How is this possible? Answer: An-Sophie Mestach just won the juniors singles title, while Kim Clijsters will compete for the singles titles in the main event in about half an hour. While not as impressive as winning the main event, it's certainly great! Especially since she also won the Doubles title, together with the Dutch Demi Schuurs Congratulations, An-Sophie!

(Update: Link to Tomeu s blog post, repost for planet.gnome.org) Last week I was in Prague to attend the GNOME/Python 2011 Hackfest for gobject-introspection, to which Tomeu Vizoso kindly invited me after I started working with PyGI some months ago. It happened at a place called brmlab which was quite the right environment for a bunch of 9 hackers: Some comfy couches and chairs, soldering irons, lots of old TV tubes, chips, and other electronics, a big Pirate flag, really good Wifi, plenty of Club Mate and Coke supplies, and not putting unnecessary effort into mundane things like wallpapers. It was really nice to get to know the upstream experts John (J5) Palmieri and Tomeu Vizoso (check out Tomeu s blog post for his summary and some really nice photos). When sitting together in a room, fully focussing on this area for a full week, it s so much easier to just ask them about something and getting things done and into upstream than on IRC or bugzilla, where you don t know each other personally. I certainly learned a lot this week (and not only how great Czech beer tastes )! So what did I do? Application porting After already having ported four Ubuntu PyGTK applications to GI before (apport, jockey, aptdaemon, and language-selector),
my main goal and occupation during this week was to start porting a bigger PyGTK application. I picked system-config-printer, as it s two magnitudes bigger than the previous projects, exercises quite a lot more of the GTK GI bindings, and thus also exposes a lot more GTK annotation and pygobject bugs. This resulted in a new pygi s-c-p branch which has the first 100 rounds of test, break, fix iterations. It now at least starts, and you can do a number of things with it, but a lot of functionality is still broken. As a kind of finger exercise and also to check for how well pygi-convert works for small projects now, I also ported computer-janitor. This went really well (I had it working after about 30 minutes), and also led me to finally fixing the unicode vs. str mess for GtkTreeView that you got so far with Python 2.x. pygobject and GTK fixes Porting system-config-printer and computer-janitor uncovered a lot of opportunities to improve pygi-convert.sh, a big perl -e kind of script to do the mechanical grunt work of the porting process. It doesn t fix up changed signatures (such as adding missing arguments which were default arguments in PyGTK, or the ubiquitous user_data argument for signal handlers), but at least it gets a lot of namespaces, method, and constant names right. I also fixed three annotation fixes in GTK+. We also collaboratively reviewed and tested Pavel s annotation branch which helped to fix tons of problems, especially after Steve Fr cinaux s excellent reference leak fix, so if you play around with current pygobject git head, you really also have to use the current GTK+ git head. Speaking of which, if you want to port applications and always stay on top of the pygobject/GTK development without having to clutter your package system with make install s of those, it works very well to have this in your ~/.bashrc:

export GI_TYPELIB_PATH=$HOME/projects/gtk/gtk:$HOME/projects/gtk/gdk
export PYTHONPATH=$HOME/projects/pygobject

Better GVariant/GDBus support The GNOME world is moving from the old dbus-glib python bindings to GDBus, which is integrated into GLib. However, dbus-python exposed a really nice and convenient way of doing D-Bus calls, while using GDBus from Python was hideously complicated, especially for nontrivial arguments with empty or nested arrays:

from gi.repository import Gio, GLib
from gi._gi import variant_type_from_string
d = Gio.bus_get_sync(Gio.BusType.SESSION, None)
notify = Gio.DBusProxy.new_sync(d, 0, None, 'org.freedesktop.Notifications',
    '/org/freedesktop/Notifications', 'org.freedesktop.Notifications', None)
vb = GLib.VariantBuilder()
vb.init(variant_type_from_string('r'))
vb.add_value(GLib.Variant('s', 'test'))
vb.add_value(GLib.Variant('u', 1))
vb.add_value(GLib.Variant('s', 'gtk-ok'))
vb.add_value(GLib.Variant('s', 'Hello World!'))
vb.add_value(GLib.Variant('s', 'Subtext'))
# add an empty array
eavb = GLib.VariantBuilder()
eavb.init(variant_type_from_string('as'))
vb.add_value(eavb.end())
# add an empty dict
eavb = GLib.VariantBuilder()
eavb.init(variant_type_from_string('a sv '))
vb.add_value(eavb.end())
vb.add_value(GLib.Variant('i', 10000))
args = vb.end()
result = notify.call_sync('Notify', args, 0, -1, None)
id = result.get_child_value(0).get_uint32()
print id

So I went to making the GLib.Variant constructor work properly with nested types and boxed variants, adding Pythonic GVariant iterators and indexing (so that you can treat GVariant dictionaries/arrays/tuples just like their Python equivalents), and finally a Variant.unpack() method for converting the return value of a D-Bus call back into a native Python data type. This looks a lot friendlier now:

from gi.repository import Gio, GLib
d = Gio.bus_get_sync(Gio.BusType.SESSION, None)
notify = Gio.DBusProxy.new_sync(d, 0, None, 'org.freedesktop.Notifications',
    '/org/freedesktop/Notifications', 'org.freedesktop.Notifications', None)
args = GLib.Variant('(susssasa sv i)', ('test', 1, 'gtk-ok', 'Hello World!',
    'Subtext', [],  , 10000))
result = notify.call_sync('Notify', args, 0, -1, None)
id = result.unpack()[0]
print id

I also prepared another patch in GNOME#640181 which will provide the icing on the cake, i. e. handle the variant building/unpacking transparently and make the explicit call_sync() unnecessary:

from gi.repository import Gio, GLib
d = Gio.bus_get_sync(Gio.BusType.SESSION, None)
notify = Gio.DBusProxy.new_sync(d, 0, None, 'org.freedesktop.Notifications',
    '/org/freedesktop/Notifications', 'org.freedesktop.Notifications', None)
result = notify.Notify('(susssasa sv i)', 'test', 1, 'gtk-ok', 'Hello World!',
            'Subtext', [],  , 10000)
print result[0]

I hope that I can get this reviewed and land this soon. Thanks to our sponsors! Many thanks to the GNOME Foundation and Collabora for sponsoring this event!

The easiest way to compress the data that is being served to the visitors of your web application is to make use of mod_deflate. Once you have enabled that module and provided it with a suitable configuration file, it will compress all releant files on the fly as it is serving them.

Given that I was already going to minify my Javascript and CSS files ahead of time (i.e. not using mod_pagespeed), I figured that there must be a way for me to serve gzipped files directly.

"Compiling" Static FilesI decided to treat my web application like a c program. After all, it starts as readable source code and ends up as an unreadable binary file.

So I created a Makefile to minify and compress all CSS and Javascript files using YUI Compressor and gzip:

all: build

build:
     find static/css -type f -name "[^.]*.css" -execdir yui-compressor -o  .css   \;
     find static/js -type f -name "[^.]*.js"  -execdir yui-compressor -o  .js   \;
     cd static/css && for f in *.css.css ; do gzip -c $$f >  basename $$f .css .gz ; done
     cd static/js && for f in *.js.js ; do gzip -c $$f >  basename $$f .js .gz ; done

clean:
     find static/css -name "*.css.css" -delete
     find static/js -name "*.js.js" -delete
     find static/css -name "*.css.gz" -delete
     find static/js -name "*.js.gz" -delete
     find -name "*.pyc" -delete

This leaves the original files intact and adds minified .css.css and .js.js files as well as minified and compressed .css.gz and .js.gz files.

How browsers advertise gzip supportThe nice thing about serving compressed content to browsers is that browsers that support receiving gzipped content (almost all of them nowadays) include the following HTTP header in their requests:

Accept-Encoding = gzip,deflate

(Incidently, if you want to test what non-gzipped enable browsers see, just browse to about:config and remove what's in the network.http.accept-encoding variable.)

Serving compressed files to clientsTo serve different files to different browsers, all that's needed is to enable Multiviews in our Apache configuration (as suggested on the Apache mailing list):

<Directory /var/www/static/css>
 AddEncoding gzip gz
 ForceType text/css
 Options +Multiviews
 SetEnv force-no-vary
 Header set Cache-Control "private"
</Directory>

<Directory /var/www/static/js>
 AddEncoding gzip gz
 ForceType text/javascript
 Options +Multiviews
 SetEnv force-no-vary
 Header set Cache-Control "private"
</Directory>

The ForceType directive is there to force the mimetype (as described in this solution) and to make sure that browsers (including Firefox) don't download the files to disk.

As for the SetEnv directive, it turns out that on Internet Explorer, most files with a Vary header (added by Apache) are not cached and so we must make sure it gets stripped out before the response goes out.

Finally, the Cache-Control headers are set to private to prevent intermediate/transparent proxies from caching our CSS and Javascript files, while allowing browsers to do so. If intermediate proxies start caching compressed content, they may incorrectly serve it to clients without gzip support.

The Free Software Foundation is in the last week of its annual fundraiser and has still has a bit of ground to make up. The FSF needs members and donations to merely sustain its basic activity protecting free software and engaging in minimal outreach. So as I've done in the last couple years, I've written a fundraising appeal for the organization. That why today my face is plastered, Jimmy Wales style, all over the FSF website. (For the record, the last bit was not my idea and I find it a little embarrassing.) My appeal this year begins with my feeling that as our lives become increasingly mediated by technology, the question of who controls technology becomes another way of asking "Who controls us?" Read the appeal for more. That statement, like much of the FSF's work, is not going to get very far with most users today. Most people don't think of technology as the source of control, power, or autonomy. They don't understand why software should be free or even what that might mean. Making this argument widely is something the FSF works hard to do. But supporting this work is a bit of a chicken-egg problem. The users we most need to reach have never heard our message and it can take some time to turn even the most receptive into supporters. For those of us that do care about technology and the power it has over its users, it's hugely important that we take action to support software freedom and organizations like the FSF that play a key place in this struggle. If we don't, nobody else will. The pool of people who might support the FSF today is small -- there are currently about 3,000 members -- but the stakes are huge: A choice between a world of DRM, locked down mobile phones, and non-free network services on one hand, and the possibility of a world where there are free alternatives on the other. The FSF won't win this fight alone, but it plays a critical role in it. The FSF is a small, humble, and responsible non-profit and a little money can have a big impact. If you are not an FSF associate member, now would be a great time to join. Membership is $120 per year ($60 for students) and payable monthly. In preparing this appeal, I realized that my membership had lapsed a couple months ago and that my partner Mika was still donating at the reduced student price. We've personally fixed both these things and made an addition donation. If you are a member, you can check your status or make a donation. If you are not yet, Please consider joining us.

For a course at the IIT Bombay on functional programing, I was preparing a presentation on Alonzo Church s theorem, based on his original 1936 paper An Unsolvable Problem of Elementary Number Theory where he first showed that the Entscheidungsproblem is not solvable. In that paper, he states a theorem (Theorem II) If a formula has a normal form [ ] any sequence of reductions of the formula must (if continued) terminate in the normal form . This seems to be wrong. Consider the lambda expression KI , where K=( xy.x), I=( x.x) and =( x.xx)( x.xx). This has a normal form I. But because reduces to , there is a non-terminating sequence KI KI , in contradiction to Church s claim. The same example contradicts his Theorem III: If a formula has a normal form, every well-formed part of it has a normal form. , which is used in the very proof of his main result, Theorem XVIII. There is no proof for Theorem II in this paper. He cites it from the then forthcoming paper Some properties of Conversion by him and J. B. Rosser. There, proofs are given (see Theorem 2 and its Corollary) but they are quite impenetrable to me. So I was searching for some correction paper, or any other discussion of this issue, but could not find any. Does any reader of this blog know more? What happened in that times when a paper had an error in some proof? What would happen now? Or is this not an error after all, but just a subtle difference between the definitions of -calculus as we know and as they introduced it? Unrelated to this question: The professor asked me to write down a summary of (my interpretation of) the importance and impact of Church s paper with regard to G del and Hilbert s program, and how that relates to B hm s theorem. In the spirit of sharing, I have uploaded my thoughts on Church and B hm, comments are welcome. Update: Christian von Essen solved the riddle in a comment to this post: Church only considers lambda abstractions as well-formed when the bound variable actually occurs (freely) in the abstracted term. This does not allow for the K combinator and thus there is no problem.

If you convert a docbook document in a chunked HTML form, it would presumably be very useful for you to place one of the various available javascript based trackers on each of your pages to see what is most popular, linked to etc. I'm assuming you've already got to the point where you have your DSSSL stylesheet going (see something like my prior entry). It doesn't appear you can get arbitrary output into the <head> tag -- the %html-header-tags% variable is really just designed for META tags and there doesn't appear to be anything else in the standard stylesheets to override. So the trick is to use $html-body-start$. But you have to be a little bit tricky to actually get your javascript to slip past the SGML parser. After several attempts and a bit of googling I finally ended up with the following for a Google Analytics tracker, using string-append to get the javascript comment filtering in:

I had some hope when I read Girish Ramakrishnan's blog post that starts with To my knowledge, there are 3 Qt based JSON parsers out there . But I was really disappointed: instead of trying to get a consolidation going or at least highlighting the need for three different parsers, he announces yet another implementation. And, to make matters worse, it is intended to be statically linked whenever it is used. A friendly wave to all security conscious engineers who will now have to hunt down and kill security issues in various places wherever this json parser was used, in various different versions, possibly with local modifications. Girish, please do not take this as a personal attack, but what you're doing is just bad engineering practice. I don't claim qjsonparser is buggy. I haven't even looked at the code. But let's face it: bugs happen, and json is often passed over the net, so any parser is attack surface. So it should be as easy as possible to get fixed versions of the code out to the users. The means to do this is by allowing distribution builders to be aware of where the code in question was used, and to get fixed versions of it distributed easily. In other words: such code should always be in a shared library. Take, for example, the history of xpdf/poppler: many people spent countless hours chasing copies of xpdf code in many applications before they finally had enough, forked xpdf (if I have the history correctly) and created the poppler library which is now widely used. Now security issues with the PDF parser require one security fix, not 10.

Dear lazy web, I am writing a library that implements the Units Policy of Ubuntu. This library can be used to format sizes (of files, disks, memory, etc.) for displaying them and the other way around. For example, the size 12345 bytes can be formatted to 12.3 kB, 12.1 KiB, or 12.1 KB depending on the configuration. An other function will give you the possibility to convert 12.3 kB, 12.1 KiB, or 12.1 KB back to 12345 bytes. The preferred binary unit can be configured by an text file (per system and per user) and by an environment variable. The library is written in C and doesn t have any dependency. Therefore it can be used by any program on any desktop environment. Binding to other languages like C++, Python, Java are planned. Before creating a project for this library, I need a name for the library. The current prototype is called libdisplayunits, but this name reflect only the half of the project. It does not indicate that the library can be used for inputting sizes. What do you think? What is the best name for the library? Please poll and/or comment below.

<script charset="utf-8" language="javascript" src="http://static.polldaddy.com/p/3972978.js" type="text/javascript"></script> <noscript> View This Poll
survey software </noscript>

I made smoky grilled tofu (based on the recipe in Veganomicon) on a bed of collard greens and maple-glazed roasted beets and carrots. Bigger pictures are here.

I have a Samsung CLP-315 printer. It works will with CUPS and foo2qpdl driver. Just ignore all the anti-distro junk written at driver s homepage, run aptitude install foo2zjs, and enjoy working printer on consistent system. But since the beginning there was a strange problem printing worked from everywhere, but not from iceweasel. If tried to print from the browser, error page was printed instead. So had to print to a pdf file, open it in kpdf, and print from there. Working but annoying. At last decided to do something with this. A quick search shows that problem is known, is not new, and as such has little chance to be quickly resolved. But then I found this hint. I immediately checked paper size in iceweasel s print dialog and yes, it was Letter! But the setting was greyed out, so unchangeable I ve tried to play with about:config (searching for print there), then tried to remove all printer setup from prefs.js no result, still Letter without option to change. But a web search helped again. Someone pointed that iceweasel has a separate menu item for page setup, at File::Page setup! That is where paper size has to be configured, tab within print dialog does not work! Mozilla people are wonderful UI designers. Many thanks to them for months of non-working printing. I ve told myself zillion of times that I should perform active steps to get rid of bugs on computers I use search the web for solutions, report bugs, fix code myself if nothing helps. That s the very point of using free software, after all. But still laziness lack of free time random real-life issues make me not to do so too often. So also many thanks to myself for months of non-working printing. But now printing from browser works, and that s good news . Update: full thanks above should be directed to, in order:

• Samsung firmware developers, who coded firmware that, when printing error page (btw wasting paper and toner), doesn t print what is actually wrong (paper size mismatch),
• Mozilla developers, who don t read default paper parameters from CUPS, but instead use own broken scheme,
• myself, for living with problem and not looking for solution for months,
• foo2qpdl upstream, who, by his anti-distro junk, turns people looking for solutions into wrong direction,
• Mozilla developers, who use braindead page setup UI.

And real thanks to the person (link above) for the hint about page size in applications that are unable to print

CLEMSON, S.C. (CBS/WSPA/AP) A man was struck by an SUV in Clemson Monday evening after police say he was playing a real-life version of the video game "Frogger" on a highway.

Game Over: Man Playing Real-Life Frogger Struck by SUV, Say S.C. Cops - Crimesider - CBS News ...as it always does.

Streaming JSON objects with python Dear Lazyweb, Suppose I'd like to create an HTTP service that gives you a looong list of JSON objects. For example, one JSON object for every package in Debian. One way I could do that is to just transfer a big, dozens of megabytes JSON array with one element per package. With the standard json module in python, this requires the client to buffer all the data in memory for decoding, as the JSON result would be something like this:

[
    info for package 1  ,
    info for package 2  ,
  ...dozens of megabytes...
    info for package 30000  ,
  ...
]

However, it would be reasonable to engineer things so that the client can process packages one at a time, as they are produced. This can dramatically reduce client memory usage, as well as remove a large latency between the start of the request and the start of processing. One trivial idea would be to just send JSON objects one after the other, and sort of call load multiple times. It doesn't work:

import json
from cStringIO import StringIO
a = StringIO()
json.dump( 1:3 , a)
json.dump( 2:4 , a)
a.reset()
print a.getvalue()
print json.load(a)

gives:

$ python z1.py 
 "1": 3 "2": 4 
Traceback (most recent call last):
  File "z1.py", line 8, in <module>
    print json.load(a)
  File "/usr/lib/python2.6/json/__init__.py", line 267, in load
    parse_constant=parse_constant, **kw)
  File "/usr/lib/python2.6/json/__init__.py", line 307, in loads
    return _default_decoder.decode(s)
  File "/usr/lib/python2.6/json/decoder.py", line 322, in decode
    raise ValueError(errmsg("Extra data", s, end, len(s)))
ValueError: Extra data: line 1 column 8 - line 1 column 16 (char 8 - 16)

And the json module documentation does not provide any way of telling the "stream" decoder to just stop parsing after the first valid object. An alternative can be to use chunked transfer encoding and transfer each JSON object in a separate HTTP chunk. It would add the overhead of a little HTTP header per JSON object, which could be significant when generating lots of small JSON objects, but it would be an implementation that strictly follows HTTP and JSON standards to the letter in a clean way. Except:

1. How do you stream HTTP chunks in WSGI? The WSGI specification's only mention of chunks is that if you produce a result as a generator of "chunks", they are just sent one after the other (effectively, concatenated) in the response stream.
2. How do you read and process one chunk at a time with urllib/urllib2? I searched on Google but I only found people in tears.

Another alternative is to wrap the JSON objects in some custom container protocol, but then we are not talking standards anymore. Is this all you can do with the standard python library? Can this only be done by adding a dependency on a C library with two obscure separately maintained bindings, or by writing my own JSON parser? Ideas? Please mail enrico@enricozini.org and I'll add them here. Updates Wouter van Heyst mentions that he heard of ijson, which indeed has my exact use case in the synopsis, but after some research looks like a third binding for yajl. Aigars Mahinovs suggests using YAML instead of JSON. Indeed YAML supports streaming very well (it's even already supported in DDE, but last time I tried to do anything serious with it, PyYaml was slooow. Of course, this being the Python ecosystem, There Are Lots Other Ways To Do It And You Shall Be Patronised For Not Chosing The Proper One, but Debian only has PyYaml. Another itch with YAML is that there is no YAML parser in the standard python library, which requires clients to add an extra dependency. Jyrki Pulliainen has so far mailed my favourite solution: disable formatting in the encoder and separate JSON objects with newlines:

we built a streaming JSON app as a part of our platform. However, we
didn't stream a single JSON object as that was a bit cumbersome. When
having syntax like:
[
  <json-obj1>,
  <json-obj2>,
  ....
  <json-objN>
]
The reader has some problems. Should it read the whole stream to find
the closing bracket ] even if the stream would me tens of megabytes?
Should it try to split on , and parse single objects? What if the
objects contain , so should there be some regexp magic?
We ended up streaming separate JSON objects separated by newlines
(\n). This way the reader can read until hitting \n or end of stream
and then split the result on newlines. The new stream looked like
this:
<json-obj1>\n
<json-obj2>\n
...
<json-objN>\n
This way we could efficiently stream hundreds of thousands of JSON
objects from server to client without reserving a load of memory. For
the WSGI part how to do this, the best would probably to do a
generator that would yield a single JSON object with the newline (we
didn't use WSGI back then). Reading can be done using any reader
capable of handling streams. We used pycurl for reading, but I can't
really recommend it as it is way too complicated for a simple task
like this :p
Hopefully this helps!

This means that if the client has no access to a JSON reader that supports a stream of concatenated toplevel objects, they can still trivially code it on top of any JSON library. This means that working clients can be written based just on Squeeze's python standard library. That's what I'm going to do; I'll probably implement it as a separate 'jsons' output format for DDE, because producing a JSON response with multiple toplevel obejcts somehow breaks the JSON standard. Thanks to all who provided this excellent information!

This week:

• #607958 (apt): replied and tagged moreinfo ; jmm later downgraded it to normal
• #606951 (nsca): agreed with the submitter and reverted the change, uploaded straight to unstable
• #605784 (nagios-statd): thanks to the great debugging work of the submitter, uploaded a fix to DELAYED/2 (giving the maintainer time to make his own planned upload)
• #598588 (json-glib): cannot reproduce; reduced severity and emailed the submitter

The remaining bugs are either removal candidates or no longer low-hanging-fruit, so I don t expect to keep squashing very many more before Squeeze is released.