=== added file 'posts/obnam-performance-requirement.mdwn'
--- posts/obnam-performance-requirement.mdwn    1970-01-01 00:00:00 +0000
+++ posts/obnam-performance-requirement.mdwn    2010-02-28 05:53:30 +0000
@@ -0,0 +1,11 @@
+[[!meta title="Obnam performance requirement"]]
+[[!tag obnam]]
+
+I don't think I've said this publically yet, so I'll do it
+now: My performance goal with obnam for the 1.0 release
+is to be able to saturate a wifi connection. That means
+that it needs to be able to write at least 3 megabytes
+per second when doing a local backup.
+
+It's not a hugely impressive goal, but it satisfies my
+personal use cases.

=== modified file 'posts/saving-instead-of-bookmarking.mdwn'
--- posts/saving-instead-of-bookmarking.mdwn    2010-02-21 06:32:44 +0000
+++ posts/saving-instead-of-bookmarking.mdwn    2010-02-21 06:42:06 +0000
@@ -1,4 +1,4 @@
-[[!meta title="Living limited Internet access: saving web pages instead of bookmarking them"]]
+[[!meta title="Living with limited Internet access: saving web pages instead of bookmarking them"]]
 [[!tag productivity note-to-self]]
 
 I'm currently touring New Zealand. Internet access here is either very slow, very expensive, or both. Or it's not there at all.

=== added file 'posts/saving-instead-of-bookmarking.mdwn'
--- posts/saving-instead-of-bookmarking.mdwn    1970-01-01 00:00:00 +0000
+++ posts/saving-instead-of-bookmarking.mdwn    2010-02-21 06:32:44 +0000
@@ -0,0 +1,10 @@
+[[!meta title="Living limited Internet access: saving web pages instead of bookmarking them"]]
+[[!tag productivity note-to-self]]
+
+I'm currently touring New Zealand. Internet access here is either very slow, very expensive, or both. Or it's not there at all.
+
+I have long bookmarked pages I want to read, but don't have time to read at the moment I encounter them. For example, if I'm reading reddit, I open all the pages that seem interesting, and if they seem interesting after the first ten seconds, I bookmark them.
+
+This works quite well, when I have good Internet access.
+
+I've now switched to saving pages locally instead. Firefox's "File/Save as" works quite well, except when pages insist on doing things in complicated ways.

=== added file 'posts/gps-urkinta.mdwn'
--- posts/gps-urkinta.mdwn      1970-01-01 00:00:00 +0000
+++ posts/gps-urkinta.mdwn      2010-02-21 05:21:13 +0000
@@ -0,0 +1,32 @@
+[[!meta title="Autojen GPS-urkinta etenee"]]
+[[!tag in-finnish finnish-politics rant]]
+
+YLE uutisoi, että Sunnuntaisuomalainen uutisoi, että
+[Ajokilometreihin perustuva autovero altis huijaukselle](http://yle.fi/uutiset/kotimaa/2010/02/ajokilometreihin_perustuva_autovero_altis_huijaukselle_1466646.html?origin=rss):
+
+> Kilometreihin perustuva autovero ja Helsinkiin kaavailtu ruuhkamaksu ovat alttiita huijaukselle, kirjoittaa Väli-Suomen sanomalehtien Sunnuntaisuomalainen. Molemmat perustuvat autojen satelliittipaikannukseen, mutta internetistä saa tilattua laitteita, joilla paikannuksen voi estää. 
+
+Välineitä GPS-vastaanoton häiritsemiseen saa ostettua mistä tahansa rautakaupasta. Riittää, että antennin ympärille pistää metallipurkin.
+
+YLE kirjoittaa myös:
+
+> Kilometreihin perustuvasta autoverosta ei ole päätöstä, mutta liikenneministeri Anu Vehviläinen (kesk.) on ehdottanut sellaista.
+
+Pelkkien ajokilometrien seurantaan GPS on monimutkainen ja virheherkkä ratkaisu. Kaikissa autoissa on jo valmiiksi paljon yksinkertaisempi väline: kilometrimittari.
+
+Monimutkaisen, virheherkän ja kalliin valvontajärjestelmän rakentamisen sijaan olisi helppoa vaatia, että ajoneuvon vuosittaiset kilometrit rekisteröidään katsastuksen yhteydessä.
+
+Vielä helpompaa olisi nostaa polttoaineveroa. Se ei vaatisi minkään uusien järjestelmien rakentamista.
+
+Tätä ei kuitenkaan tulla tekemään, koska Suomen poliittiset päättäjät ovat joko teknologiayritysten nenästä vedettävissä tai ovat ymmärtäneet kirjan [1984](http://www.effi.org/julkaisut/tiedotteet/lehdistotiedote-2009-06-11.html)
+aivan väärin.
+
+Edelleen YLE:n uutisesta:
+
+> Öörni uskoo, että häirintälaitteiden kitkemiseksi joudutaan rakentamaan tekninen valvontajärjestelmä. Todennäköisin vaihtoehto on rekisterikilpiä kuvaavat liikuteltavat kamerat. 
+
+Totta kai on järkevää ensin rakentaa monimutkainen, virheherkkä, kallis GPS-valvontajärjestelmä ja sen jälkeen toinen monimutkainen, virheherkkä ja kallis järjestelmä valvomaan ensimmäisen toimivuutta. Tämä on järkevää nimenomaan siksi, että _kumpikin järjestelmä_ on omiaan ihmisten valvomiseen.
+
+Tämä on tärkeä pointti: kaikki nämä järjestelmät tähtäävät viime kädessä siihen, että autojen kaikkia liikkeitä valvotaan mahdollisimman tarkasti. Koska melkein kaikki autot ovat yhden tai kahden kuljettajan käytössä, tässä valvotaan siis ihmisten liikkumista.
+
+Jos hallituksessa olisi yhtään yksityisyydestä välittävää henkilöä, nämä hankkeet ja puheet loppuisivat lyhyeen tai ainakin niiden hyödyistä ja haitoista käytäisiin julkista keskustelua. Nyt pelkästään puhutaan siitä, miten mahdolliset järjestelmää huijaavat saadaan kiinni.

=== added file 'posts/obnam-feature-complete-for-now.mdwn'
--- posts/obnam-feature-complete-for-now.mdwn   1970-01-01 00:00:00 +0000
+++ posts/obnam-feature-complete-for-now.mdwn   2010-02-19 02:53:46 +0000
@@ -0,0 +1,12 @@
+[[!meta title="Obnam is feature complete (sort of)"]]
+[[!tag obnam]]
+
+I have recently implemented all Obnam features I think I want before I start using it for real, except encryption. The next step is to re-implement the backup store implementation. The current implementation is the simplest, most stupidest one I could get away with. I did not care at all about performance, so it is rather, er, slow.
+
+I said stupid, right? Yes I did.
+
+I may end up implementing the backup store in several ways, to be able to compare them in semi-real-life benchmarks.
+
+I was going to add support for ACLs and extended attributes, but I decided not to: I do not use them myself, and they're just non-obvious enough that I am going to need to find a collaborator to verify I do the right thing. (Ideally, someone who'll also write the code... I promise to show how.)
+
+In other news, B-trees are surprisingly interesting.

=== added file 'posts/tech-travel-cable-management/comment_2_72f5f3eacc4b98eb25319b6bd31328a3._comment'
--- posts/tech-travel-cable-management/comment_2_72f5f3eacc4b98eb25319b6bd31328a3._comment      1970-01-01 00:00:00 +0000
+++ posts/tech-travel-cable-management/comment_2_72f5f3eacc4b98eb25319b6bd31328a3._comment      2010-02-16 11:14:47 +0000
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="http://liw.fi/"
+ subject="Heh"
+ date="2010-02-16T11:14:46Z"
+ content="""
+liwtopia is a weird place. You're welcome to visit. :)
+"""]]

=== added directory 'posts/tech-travel-cable-management'
=== added file 'posts/tech-travel-cable-management/comment_1_55b7cd32783dd0400602e0f7d5f15411._comment'
--- posts/tech-travel-cable-management/comment_1_55b7cd32783dd0400602e0f7d5f15411._comment      1970-01-01 00:00:00 +0000
+++ posts/tech-travel-cable-management/comment_1_55b7cd32783dd0400602e0f7d5f15411._comment      2010-02-16 10:08:01 +0000
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://wo.uter.be/"
+ subject=""strangled to death""
+ date="2010-02-16T10:08:00Z"
+ content="""
+I think you'll find you can't be waking up if your cables have strangled you to death.
+
+But hey, I don't know what the laws of physics are in liwtopia. For all I know, you could.
+
+(yeah, I just want to be an asshole ;-P )
+"""]]

=== added file 'posts/tech-travel-cable-management.mdwn'
--- posts/tech-travel-cable-management.mdwn     1970-01-01 00:00:00 +0000
+++ posts/tech-travel-cable-management.mdwn     2010-02-05 06:45:12 +0000
@@ -0,0 +1,29 @@
+[[!meta title="Cable management while travelling"]]
+[[!tag travel idea]]
+
+We're travelling and we have several electronic devices
+with us. This means we have many cables. Cables are difficult
+enough at home, but especially so while travelling.
+
+My current best approach is to put each cable in a small
+clear plastic bag (zip lock bag, I think they're called). This
+prevents the cables from getting entangled, but there's so
+many of them that it's still hard to keep them in order.
+
+I wonder if it would be possible to develop a better solution?
+My best idea so far is a long piece of fabric with pieces of
+velcro sewn into it. The velcro would be located so that it
+would be possible to neatly put each cable in place and then
+roll the whole piece of fabric into a neat roll.
+
+When it would be time to get a cable, one would unroll the
+fabric, and then unfasten one or two pieces of velcro to
+get the cable.
+
+Perhaps pockets instead of velcro?
+
+Anyone have better ideas? Anyone have an actual solution?
+I live in mortal dread of waking up one morning and learning
+that my cables have started to breed, and have decided to
+overthrow their master, and have strangled me to death
+while I slept.

=== added file 'posts/computer-driving-license.mdwn'
--- posts/computer-driving-license.mdwn 1970-01-01 00:00:00 +0000
+++ posts/computer-driving-license.mdwn 2010-02-04 22:58:51 +0000
@@ -0,0 +1,15 @@
+[[!meta title="Computer driving licenses"]]
+[[!tag freedom politics rant]]
+
+
+Various countries have a training programme called the "computer
+driving license". The training aims to give basic computer using skills
+(word processing, spreadsheets, the web, etc). It's good for people
+unsure of their skills, but I object to the name.
+
+I think it's worrying that it's called a license of any kind, since that
+implies that there is an entity whose permission people
+need to use a computer. Licenses to own and operate copying machines or
+typewriters have existed, and it's always a sign of political
+oppression. It's just a word, but words have power, or at least they
+give leverage to those in power.

=== added file 'posts/obnam-store-outline/comment_3_f83c66b1f46b14b62f96a34eb00bcae8._comment'
--- posts/obnam-store-outline/comment_3_f83c66b1f46b14b62f96a34eb00bcae8._comment       1970-01-01 00:00:00 +0000
+++ posts/obnam-store-outline/comment_3_f83c66b1f46b14b62f96a34eb00bcae8._comment       2010-02-02 03:57:18 +0000
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://rogerbinns.com/"
+ subject="Deduping"
+ date="2010-02-02T03:57:18Z"
+ content="""
+I've worked on deduping products (network based, not storage).  The way they work is to have a hash function which you apply over a range of data.  To catch shifts in data (insertions, deletions) you calculate hashes over multiple overlapping ranges.  You can also do it for multiple sizes (eg 16kb, 8kb, 1kb).  We went right down to 32 bytes!  The interesting part is that you discard most of the hashes calculated.  For example we discarded any that did not end in some number of trailing zeroes.  This makes storing the hashes smaller since you don't need to store the trailing zeroes while still having enough to provide useful deduping.
+
+There is a tradeoff between how many times you calculate a hash over a range of data and the resulting deduplication efficiency.  (Network has it somewhat easy as the largest chunk of data at once is the size of an ethernet frame, but then also has real time-ish requirements.)  If you design your hash function well you can have multiple output values as you roll through the data.  (Note that you do not need to use this hash in the storage system - a strong sha can be used - the point is to find potential duplicates quickly.)
+
+Somewhat surprisingly we also had the benefit of gzip style compression.  Data is effectively a list of intertwined hashes and literals and gzip on that output gave about another 50% compression much of the time.
+"""]]

=== added file 'posts/obnam-store-outline/comment_2_9d807f449a838d70db6df0e8aa0292f3._comment'
--- posts/obnam-store-outline/comment_2_9d807f449a838d70db6df0e8aa0292f3._comment       1970-01-01 00:00:00 +0000
+++ posts/obnam-store-outline/comment_2_9d807f449a838d70db6df0e8aa0292f3._comment       2010-02-01 05:31:29 +0000
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="http://liw.fi/"
+ subject="comment 2"
+ date="2010-02-01T05:31:28Z"
+ content="""
+I've only looked at it a little, but it seems to me that git's object store isn't suitable for use in encrypted environments or when the bandwidth between the app and the store is very limited.
+"""]]

=== added directory 'posts/obnam-store-outline'
=== added file 'posts/obnam-store-outline/comment_1_e89f9723e2fdec771b1ba5282eb61f3f._comment'
--- posts/obnam-store-outline/comment_1_e89f9723e2fdec771b1ba5282eb61f3f._comment       1970-01-01 00:00:00 +0000
+++ posts/obnam-store-outline/comment_1_e89f9723e2fdec771b1ba5282eb61f3f._comment       2010-02-01 05:00:27 +0000
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="http://madduck.net/"
+ subject="Sounds like the Git object store"
+ date="2010-02-01T05:00:27Z"
+ content="""
+It sounds like you are re-implementing the object store on which the [Git](http://git-scm.com/) version control system is built...
+
+PS: your ikiwiki does not allow Unicode in comments.
+"""]]

=== added file 'posts/obnam-store-outline.mdwn'
--- posts/obnam-store-outline.mdwn      1970-01-01 00:00:00 +0000
+++ posts/obnam-store-outline.mdwn      2010-02-01 03:56:40 +0000
@@ -0,0 +1,210 @@
+[[!meta title="Obnam storage API"]]
+[[!tag obnam]]
+
+The central data structure in Obnam is the way it stores backed up 
+data on disk.
+This is the area I have struggled with most in the four years I've been
+sporadically developing Obnam.
+
+My **initial attempt** was roughly this: everything was put in the backup
+store as a sort of object, which I'll call backup object. This included file 
+contents, deltas between
+versions of a file, file metadata, and filenames. While the representation
+was quite different, essentially each of these objects was a list of
+key-value pairs:
+
+    file:
+        id = 12765
+        basename = "/home/liw/foobar/foobar.c"
+        st_mtime = 32
+        contref = 42
+    
+    contents:
+        id = 42
+        data = "/* foobar.c -- a program to make foo do bar */\n..."
+    
+    generation:
+        id = 105
+        file = "/home/liw/foobar/foobar.c", 12765
+        file = "/home/liw/foobar/README", 32765
+        ...
+
+Each generation consists of a list of filenames and pointers to the
+object that represents the version of the file in that generation. If a
+file has not changed from generation to generation, the pointer (and
+thus the file contents) from the previous generation is reused.
+
+This was pretty simple, but it repeated the entire list of files, 
+with names for each generation. The filenames take a surprising amount 
+of space. Some statistics from my laptop:
+
+    Number of files: 401509
+    Basenames: 6 MiB
+    Pathnames: 27 MiB
+
+It is ridiculous to store the full list of files (whether basenames or
+pathnames) for each generation. Even just the basenames will use more
+than a typical delta between each backup run, for me. This is clearly not
+acceptable.
+
+After I realized this, I set to fix this by storing 
+**only changed filenames.** I got this to work, but for various reasons 
+it was very slow, and the complexity of the code made it hard to improve. 
+
+Instead of using a pathname as an index to a hashtable, as before, I was 
+now building a duplicate of the filesystem's directory tree in my backup 
+store. Each directory and file was represented by by a backup object,
+and the generation only held a list of root objects (essentially, the
+root directory).
+
+When making a new backup, I would carefully do an update from the bottom
+of the filesystem directory tree upwards, doing copy-on-write updates on
+any backup objects that had changed since the previous backup. While this
+is reasonably straightforward to do, it made the code unnecessarily
+complicated. The code to do backups had to worry about functional
+updates to trees, which really isn't its business.
+
+The fundamental cause for this misplaced complexity was that the backup
+store API was using object identifiers as keys, whereas backups (and
+restores and other operations) really want to handle filenames.
+
+My current approach in the second complete rewrite is to
+**return to pathname based indexing**, but keep the copy-on-write
+behavior. I do not yet know how I will implement this, but I do know
+I need to keep all the complexity inside the backup store implementation.
+Right now I am concentrating on finding the best API for the store so
+that the rest of the program will be easy to write.
+
+It's important that the API be non-tedious to use. There's a lot of
+room for exploration in backups for what to back up and when, and in
+which order. There's even further room for exploration in doing stuff
+with backed up data: verification, FUSE filesystems, etc. If the store
+API is tedious, it'll be harder to do all those nice things. If it is
+easy, they'll be that much easier to do.
+
+I have hacked up a first draft of the store API. Before I discuss it,
+I'll give outlines of how the backup is coded, in pseudo-Python:
+
+    def backup(directories):
+        for each directory:
+            backup_directory(directory)
+            
+    def backup_directory(dirname):
+        for each file directory:
+            backup_file(filename)
+        backup_metadata(dirname)
+        
+    def backup_file(filename):
+        if file has changed:
+            backup_file_contents(filename)
+            backup_metadata(filename)
+
+    def backup_file_contents(filename):
+        for each chunk in file:
+            if chunk exists in store already:
+                remember its id
+            else:
+                put chunk into store and remember new id
+        set chunk ids for filename
+    
+    def backup_metadata(pathname):
+        read metadata from filesystem
+        put metadata into store
+    
+That's about as straightforward as one can imagine. The store
+API is starting to emerge (semi-real-Python):
+
+    class Store:
+    
+        def create(self, pathname):
+        def set_metadata(self, pathname, metadata):
+        def set_file_chunks(self, pathname, chunkids):
+        def find_chunk(self, data):
+        def put_chunk(self, data):
+
+However, this is not quite ready yet. There is, for example, no
+concept of generations. After some playing around and discussions
+with Richard Braakman, I've ended up with the following approach.
+
+A new generation is initially created as a clone of the previous
+generation (or empty, if it is the first generation). The new clone
+can be modified, in a copy-on-write fashion, and when all changes
+are done, they can be committed into the store. After that, the
+generation is immutable, and cannot be changed anymore.
+
+This results in small changes to the main backup routine:
+
+    def backup(directories):
+        start new generation
+        for each directory:
+            backup_directory(directory)
+        commit started generation
+
+And a couple of new methods to the Store class:
+
+    def start_generation(self):
+    def commit_generation(self):
+
+Backups will now work reasonably efficiently, yet the code is simple.
+The complexity is all nicely hidden in the Store class.
+
+Restoring should also be easy:
+
+    def restore():
+        restore_directory(generation_id, '/')
+        
+    def restore_directory(genid, dirname):
+        create target directory on output filesystem
+        for each item in the directory in the generation in the store:
+            if it is a directory:
+                restore_directory(genid, sub-directory name)
+            else:
+                restore_file(genid, full pathname to file)
+        restore target directory metadata
+
+    def restore_file(genid, filename):
+        for each chunk in file:
+            read chunk
+            write to output file
+        restore file metadata
+
+The store API needs a couple of new things:
+
+    def listdir(self, genid, dirname):
+    def get_metadata(self, genid, pathname):
+    def get_file_chunks(self, genid, filename):
+    
+There's a little bit more to it to handle hardlinks, symlinks, and
+other special cases, but this is basically what the API will now
+look like.
+
+I have imlemented a proof-of-concept version of the API to allow
+me to play with it, and see what the rest of the code would look like.
+I am still assuming that using something like the funcational B-trees
+in btrfs will be a good way to implement it properly, but the API is
+not assuming that, I hope. (The code is slightly different from the
+above snippets. If you want to have look at the actual code,
+`bzr get http://code.liw.fi/obnam/bzr/rewrite4/` will get you a copy.)
+
+So far, I am happy with this. There's a whole bunch of questions 
+remaining that I will get to. Right now the thing that worries me
+most is finding chunks in the backup store: can I implement it
+efficiently enough that it will be useful. Some version of this
+will need to be done, so that I can de-duplicate data in the
+filesystem. For example, if I move a ISO file to a new place and
+make some small changes to it, it would be disastrous if I had to
+back it up completely, even though almost all data is already in

(Diff truncated)

=== modified file 'posts/lca2010-rest.mdwn'
--- posts/lca2010-rest.mdwn     2010-01-26 07:33:33 +0000
+++ posts/lca2010-rest.mdwn     2010-01-30 01:56:48 +0000
@@ -1,5 +1,5 @@
 [[!meta title="LCA, rest of the week"]]
-[[!tag lca2010]]
+[[!tag conference lca2010]]
 
 Tuesday: Gabriella Coleman's keynote about the origins and impact of
 the free software and hacker communities on the rest of the world

=== added file 'tag/conference.mdwn'
--- tag/conference.mdwn 1970-01-01 00:00:00 +0000
+++ tag/conference.mdwn 2010-01-30 01:52:33 +0000
@@ -0,0 +1,3 @@
+This tag is for blog posts that are about conferences.
+
+[[inline archive=yes pages="link(tag/conference)"]]

=== modified file 'posts/lca2010-rest.mdwn'
--- posts/lca2010-rest.mdwn     2010-01-26 07:31:00 +0000
+++ posts/lca2010-rest.mdwn     2010-01-26 07:33:33 +0000
@@ -37,7 +37,10 @@
 Penguin dinner in the evening was a disappointment from my point
 of view. Too many people, too much noise, I did not hear much and 
 was slightly miserable. I should learn some day that I do not thrive
-in noisy crowds.
+in noisy crowds. I did, however, draw a penguin on my phone
+while there.
+
+[[penguin.png]]
 
 Saturday: LCA Open Day, talked to a bunch of people from companies,
 handed out my business card. A company called Lucid is doing a

=== added file 'posts/lca2010-rest/penguin.png'
Binary files posts/lca2010-rest/penguin.png     1970-01-01 00:00:00 +0000 and posts/lca2010-rest/penguin.png    2010-01-26 07:33:00 +0000 differ

=== modified file 'posts/lca2010-rest.mdwn'
--- posts/lca2010-rest.mdwn     2010-01-26 07:30:10 +0000
+++ posts/lca2010-rest.mdwn     2010-01-26 07:31:00 +0000
@@ -46,5 +46,5 @@
 
 [[reprap.jpg]]
 
-Also, saw a RepRap. Stunningly cool. A glimpse of the
+Also, saw a [RepRap](http://en.wikipedia.org/wiki/RepRap). Stunningly cool. A glimpse of the
 future.

=== modified file 'posts/lca2010-rest.mdwn'
--- posts/lca2010-rest.mdwn     2010-01-26 07:24:40 +0000
+++ posts/lca2010-rest.mdwn     2010-01-26 07:30:10 +0000
@@ -46,4 +46,5 @@
 
 [[reprap.jpg]]
 
-Also, saw a RepRap. Stunningly cool.
+Also, saw a RepRap. Stunningly cool. A glimpse of the
+future.

=== added file 'posts/lca2010-rest/reprap.jpg'
Binary files posts/lca2010-rest/reprap.jpg      1970-01-01 00:00:00 +0000 and posts/lca2010-rest/reprap.jpg     2010-01-26 07:29:31 +0000 differ

=== added directory 'posts/lca2010-rest'
=== added file 'posts/lca2010-rest/fenwick.jpg'
Binary files posts/lca2010-rest/fenwick.jpg     1970-01-01 00:00:00 +0000 and posts/lca2010-rest/fenwick.jpg    2010-01-26 07:28:45 +0000 differ

=== added file 'posts/lca2010-rest.mdwn'
--- posts/lca2010-rest.mdwn     1970-01-01 00:00:00 +0000
+++ posts/lca2010-rest.mdwn     2010-01-26 07:24:40 +0000
@@ -0,0 +1,49 @@
+[[!meta title="LCA, rest of the week"]]
+[[!tag lca2010]]
+
+Tuesday: Gabriella Coleman's keynote about the origins and impact of
+the free software and hacker communities on the rest of the world
+was wonderful. Missed other
+talks, feeling very "shell shocked" and maybe culture
+shocked, and not really wanting to talk to people or hear
+people talk. Did see Blackheath's Haskell talk, which was a basic
+overview of Haskell features.
+
+Wednesday: Mako Hill's keynote was very inspiring. Concepts of
+autonomy and anti-features are good. Matthew Garrett's
+"Making yourself popular" talk was good, though perhpas a bit
+shallow. JobsBOF was a washout for me, nothing interesting there. 
+Roger Fenwick's "World's worst inventions" was funny.
+
+[[fenwick.jpg]]
+
+(The above photo is rather bad. Sorry. I did not feel like carrying
+around with a real camera so I made do with the phone's.)
+
+Thursday: Glyn Moody's keynote quite exceptionally good. He's one
+of my favorite two IT journalists. (The other one, Jon Corbet, was also
+at LCA, though I missed his talk and failed to talk to him.)
+Skipped the rest of the
+conference day, as Soile and I went and opened bank accounts
+and shopped for a car.
+
+Friday: Lighting talks were ok, it's a good concept. Photo management BOF not
+too exciting, but interesting to hear that most people think tagging
+is too much work to be practical. I might want to make Dimbola be
+really good at that. Martin Krafft was late for the
+DebianBOF so I chaired/secretaried it. Lots of discussions, I almost
+felt it was my crowd still.
+
+Penguin dinner in the evening was a disappointment from my point
+of view. Too many people, too much noise, I did not hear much and 
+was slightly miserable. I should learn some day that I do not thrive
+in noisy crowds.
+
+Saturday: LCA Open Day, talked to a bunch of people from companies,
+handed out my business card. A company called Lucid is doing a
+backup program called LBackup, free software, I might want to
+collaborate with them, given my continued interest in Obnam.
+
+[[reprap.jpg]]
+
+Also, saw a RepRap. Stunningly cool.

=== added file 'posts/obnam-cli/comment_2_e9d36089fbea10bdd6f90a32fbc22901._comment'
--- posts/obnam-cli/comment_2_e9d36089fbea10bdd6f90a32fbc22901._comment 1970-01-01 00:00:00 +0000
+++ posts/obnam-cli/comment_2_e9d36089fbea10bdd6f90a32fbc22901._comment 2010-01-19 03:22:31 +0000
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="http://liw.fi/"
+ subject="comment 2"
+ date="2010-01-19T03:22:30Z"
+ content="""
+Verify: yeah, many ways of choosing what data to verify is going to be needed. My code already has plugin and hook systems, and I'll make it possible to extend the verification to pretty much anything, just in case my own ideas aren't universal.
+
+Permission problems: failure to back up or verify something because of permissions need to be treated as a failure.
+
+inotify/dnotify: certainly. I have no idea yet what is going to be the best way of using them, but they're certainly on the roadmap (or would be, if I had time to write the roadmap down).
+
+Deduping/redundancy in the backup store: I could be talked into making it configurable how much de-duping needs doing. For my own needs, I would rather solve it by having backups of backups. I'm also thinking of having a plugin that adds some error correcting codes to the backup store.
+
+
+"""]]

=== added file 'posts/lca2010-monday.mdwn'
--- posts/lca2010-monday.mdwn   1970-01-01 00:00:00 +0000
+++ posts/lca2010-monday.mdwn   2010-01-18 05:22:59 +0000
@@ -0,0 +1,56 @@
+[[!meta title="LCA2010 Monday"]]
+[[!tag conference lca2010]]
+
+I'm at the the [LCA2010](http://www.lca2010.org.nz/) 
+conference in Wellington.
+Today was the first day, with miniconfs.
+A few notes:
+
+* [Stephen Blackheath: Haskell, and all the wonderful things it doesn’t let you do](http://blogs.tucs.org.au/oplm/programme/#haskell). An overview talk of what Haskell is all about.
+  I really need to get back to reading the Real World Haskell book.
+* [Kate Stewart: Sharing Package Copyright and Licensing Data Effectively](https://fossbazaar.org/content/lca-devbiz-january-2010#stewart). An overview of the dilemma a distributor
+  of free software stuff faces: copyright and license info has no
+  markup language, and indeed is often out of date, which causes some
+  legal risk. Fossbazaar.org and others are trying to come up with a
+  format that everyone can use and that hopefully most people from
+  upstreams to Linux distros to others will adopt.
+  [DEP5]() was mentioned.
+* Lana Brindley: Creating Beautiful Documentation. The time slot had been shortened,
+  but good stuff anyway. While I haven't personally done much documentation
+  writing since leaving the Linux Documentation Project in 1997,
+  apart from a manual page every now and then, I agree with Brindley
+  that good documentation is an important factor in a successful
+  project. Tech writers and graphical artists are sorely needed,
+  as is shaping projects so that coders are no longer kings.
+* Scott James Remnant: Cutting down boot times. 
+  Missed this talk, but that's OK, Scott seems
+  to have missed it, too, due to travel.
+* [Carl Worth: Cairo Graphics - Intro and Future thoughts](http://libregraphicsday.org/proposal/79/cairo-graphics-intro-and-future-thoughts). Another overview talk. I know very little about Cairo,
+  but at least I now know where it stands in the stack. I should perhaps
+  look into using it for [Dimbola](http://dimbola.org). If only I knew
+  any graphics programming.
+  
+The conference venue works well, except for occasional wireless
+problems.
+
+Attempted to see how long my X200s battery actually lasts, and I managed
+to get through the day without charging. When I left the hotel, the
+battery was fully charged, and when I came back, there was an estimated
+15 minutes left. However, I didn't use the laptop all the time, and
+I can't figure out from the GNOME Power Manager how much battery time
+I've actually used up today. The history dialog is entirely
+incomprehensible to me.
+
+One thing that happens in conferences, including this LCA, is that
+people realize they've forgotten a cable or a charger or something,
+and someone else lends it to them. There's a bit of a shuffle for
+the lender and borrower to meet. I wonder if it would be too big a 
+hassle for the organizers to set up a "post office": the lender
+would bring the cable, or whatever, put it in a bag, put their own
+name and the borrower's name on the bag, and then give it to the
+reception people to keep. The borrower could then fetch if from the
+reception whenever is suitable. Maybe this would be too much work
+and responsibility for the organizers, who are overworked as it is.
+
+The weather is pretty nice. Some rain occasionally, but lots of
+sunshine, too. Pretty warm. People are very friendly.

=== added directory 'posts/obnam-cli'
=== added file 'posts/obnam-cli/comment_1._comment'
--- posts/obnam-cli/comment_1._comment  1970-01-01 00:00:00 +0000
+++ posts/obnam-cli/comment_1._comment  2010-01-18 04:21:49 +0000
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://rogerbinns.com/"
+ subject="Verify, notify and duping"
+ date="2010-01-18T04:21:48Z"
+ content="""
+For verify, I'd presume some sort of random choice by age grouping (ie covering older files, middle aged files and new ones) as well as by a variety of different directories would help.  Maybe you just tell the tool the maximum amount of time/data transfer to spend on verification and off it goes?  One gotcha I have seen with backups is permissions problems.  You run the backup as an ordinary user (its using your ssh keys etc) and don't notice that it failed to pickup some files maybe because it didn't complain or maybe because it does complain about many permissions problems so you don't see what you care about in the noise.  Then later you discover hat actually /etc/shadow or /var/lib/couchdb would have been nice to have been backed up.
+
+Have you considered a i/dnotify style listener?  Instead of remembering to schedule backups, you leave the tool running pointed at a set of directories you care about, it automatically picks up changed files and backs them up in the near future.  (You could obviously also do this with a separate unrelated monitor program repeated invoking the command line.  I have no idea which approach is better.)
+
+On the deduping side one problem is that some files are more important to me than others.  Not only do I want the contents backed up, but I want the backup to be able to survive some number of failures of the backup data for that file.  For example I'd want to ensure that there is deliberate duplication of the blocks making up some directories (tax returns, password lists, ssh/pgp stuff) so that a single bad sector on the backup server doesn't lose what is most important to me.
+"""]]

=== added file 'posts/collaborative-voted-storytelling.mdwn'
--- posts/collaborative-voted-storytelling.mdwn 1970-01-01 00:00:00 +0000
+++ posts/collaborative-voted-storytelling.mdwn 2010-01-17 22:24:49 +0000
@@ -0,0 +1,10 @@
+[[!meta title="Collaborative storytelling with audience voting"]]
+[[!tag idea]]
+
+As I'm reading [Cory Doctorow's](http://craphound.com/)
+[Makers](http://craphound.com/makers/) novel, I can't help
+wondering whether it might be possible to write a novel 
+collaboratively. Each participant would write a paragraph per
+day, and readers could vote paragraphs up and down. It might
+be interesting to see if a coherent story would eventually
+emerge.

=== added file 'posts/obnam-cli.mdwn'
--- posts/obnam-cli.mdwn        1970-01-01 00:00:00 +0000
+++ posts/obnam-cli.mdwn        2010-01-17 07:43:20 +0000
@@ -0,0 +1,39 @@
+[[!meta title="Obnam command line interface"]]
+[[!tag obnam]]
+
+I have some specific ideas for the command line interface I'm planning 
+for my backup program.
+I'll be writing a man page for obnam, but before I do that, here's
+a sketch.
+
+* `obnam backup --store sftp://example.com/~/backups/ $HOME`
+* `obnam ls --generation latest`
+* `obnam verify`
+* `obnam fsck`
+* `obnam restore --generation latest --to /var/tmp/liw.restore`
+* `òbnam forget --keep 1h:7d:5w:12m:99y`
+
+The **backup** command should be obvious. I'll make a configuration
+file so the location of the backup store can be specified there, rather
+than every time on the command line. Also other arguments, such as
+the directories to back up.
+
+The **ls** command lists the contents of a backup generation.
+
+The **verify** command compares what has been backed up with what is
+on the hard disk now, reporting differences. If you back up and then
+immediately verify, you can check that everything got backed up.
+Verify will also be able to do things like compare randomly selected
+files (rather than all of them). I am not yet sure exactly how the
+verification process should happen to make things trustable.
+
+**fsck** checks that the internal data structures in the backup store
+are OK.
+
+**restore** restores.
+
+**forget** removes old backup generations. It will be able to remove
+specific generations, or apply a policy such as "keep one hour, seven
+daily, five weekly, twelve monthly, and lots of yearly generations".
+It will be cheap to keep lots of generations, since obnam will do
+heavy de-duplication, at the block level.

=== added file 'posts/obnam-once-again/comment_4._comment'
--- posts/obnam-once-again/comment_4._comment   1970-01-01 00:00:00 +0000
+++ posts/obnam-once-again/comment_4._comment   2010-01-12 09:01:22 +0000
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="http://liw.fi/"
+ subject="bzr format docs?"
+ date="2010-01-12T09:01:22Z"
+ content="""
+@lifeless: is there high-level documentation for the 2a format? I've seen one presentation by you on it, and that was inspiring to me for a previous incarnation of obnam, but didn't seem like it would let me easily re-use chunks of data from any version of any file from any host using the same backup store. Also, I'd like to know if the bzr format would work well with encryption.
+"""]]

=== added file 'posts/obnam-once-again/comment_3._comment'
--- posts/obnam-once-again/comment_3._comment   1970-01-01 00:00:00 +0000
+++ posts/obnam-once-again/comment_3._comment   2010-01-12 05:28:21 +0000
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~lifeless"
+ subject="bzr's 2a format"
+ date="2010-01-12T05:28:20Z"
+ content="""
+Has many of the internal properties you'd need. It has some extra data, so I wouldn't use it as-is.
+"""]]

=== added file 'posts/obnam-once-again/comment_2._comment'
--- posts/obnam-once-again/comment_2._comment   1970-01-01 00:00:00 +0000
+++ posts/obnam-once-again/comment_2._comment   2010-01-11 08:52:01 +0000
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://liw.fi/"
+ date="2010-01-11T08:52:01Z"
+ content="""
+I don't actually find it particularly relevant what the dependencies are for restoring data, but anyway, the dependencies will be the same as for backup: python, paramiko, gpg. The reason the dependencies are not that relevant is that if you can boot off a live-cd, dependencies are easy to fulfill, and I would not be stupid enough to require particular hardware (64-bit in your example).
+
+Validation falls under reliability.
+
+De-duplication falls under \"fast\". If a chunk of data has already been backed up, in another file or by another computer, then it obviously should not have to be uploaded again.
+
+Any number of computers will of course work.
+"""]]

=== added directory 'posts/obnam-once-again'
=== added file 'posts/obnam-once-again/comment_1._comment'
--- posts/obnam-once-again/comment_1._comment   1970-01-01 00:00:00 +0000
+++ posts/obnam-once-again/comment_1._comment   2010-01-11 08:16:44 +0000
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://rogerbinns.com/"
+ subject="Some more concerns"
+ date="2010-01-11T08:16:43Z"
+ content="""
+You need to consider restoring and testing.  For example what are the dependencies of the restore program - will it run on any recent Linux LiveCD or do you have to have a bazillion libraries installed and only the latest 64bit Ubuntu?  Is there some sort of simple integration possible with Nautilus?
+
+For testing, at some point you want to validate your backups, probably by pointing to a backup and to a local machine and have the test tell you how they diverge.
+
+You also haven't mentioned what should be done about multiple machines (ie if you want to backup more than one).  Using block hashes (see recent postings about ZFS deduplication settings) it becomes a lot cheaper to backup multiple machines into the same space since they will have many blocks the same. And once you consider laptops, desktops, servers, virtual machines etc you soon find you have a lot of \"computers\" and it would be great to be able to back them all up conveniently.
+"""]]

=== added file 'posts/obnam-once-again.mdwn'
--- posts/obnam-once-again.mdwn 1970-01-01 00:00:00 +0000
+++ posts/obnam-once-again.mdwn 2010-01-11 05:05:23 +0000
@@ -0,0 +1,48 @@
+[[!meta title="Obnam, or once more a backup program"]]
+[[!tag obnam]]
+
+I've decided to resurrect development of my backup program,
+Obnam. This time I thought I'd babble about it in public as I
+develop it, rather than try to present the world with a finished
+product.
+
+I have not been happy with any backup solution I've tried. I have
+some fairly specific requirements:
+
+* Backups must be stored either on a local hard disk, or online.
+  I don't care at all about tapes, optical media, or anything else
+  that requires repetitive manual work.
+* Server end must be under my control as well. No Amazon S3 for me.
+* Both push and pull backups.
+* Backups must be encrypted at client end.
+* Backups must be incremental, but each generation must look like a full
+  snapshot.
+* Backups must use checkpoints: network connections break, and if they do,
+  the next backup must continue from most recent checkpoint.
+* Setup must be easy. Backups are important, but if they're at all any
+  kind of pain, I and most others will just postpone them to a future
+  day and one day it will be too late.
+* Fast. If I do some e-mail and write some code while drinking a smoothie
+  in a net cafe, by the time I finish the drink and put away the laptop
+  the backup must be finished.
+* Deals sensibly both with slow and fast networks. An incremental backup
+  should not download any data from server, and should only upload the
+  delta from the previous backup, plus minimal overhead.
+* Reliable. Backups should not require attention. I should just be allowed
+  to assume they work. This also requires unobtrusive feedback that they're
+  OK, and proper error reporting when something is wrong and does require
+  my attention.
+
+It's been a while since I did a proper survey, so things may have changed
+since, but so far, I've never found a system that I like. If you know of
+one, please don't tell me. I am now deep into thinking about the technical
+problems I will need to solve, and not that interested in finding an
+existing solution anymore.
+
+If "hubris" was spelled with an i, it would be my middle name.
+
+I have some code sketched out, but nothing that does anything useful
+yet. I've been playing with the internal architecture, and the interface
+and abstraction I will want for the "storage subsystem" that stores
+the backed up data. I have not decided yet how to implement the
+storage subsystem, but btrfs B-trees interest me a lot.

=== modified file 'sidebar.mdwn'
--- sidebar.mdwn        2008-05-06 20:37:04 +0000
+++ sidebar.mdwn        2010-01-08 15:29:19 +0000
@@ -16,3 +16,9 @@
 [The Simple Dollar](http://www.thesimpledollar.com/)
 [Taijamai](http://taijamai.blogspot.com/)
 [Unclutterer](http://unclutterer.com/)
+
+<hr />
+
+All content outside of comments is copyrighted by
+Lars Wirzenius, and licensed under a <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative Commons Attribution-Share Alike 3.0 Unported License</a>.
+Comments are copyrighted by their authors.

=== modified file 'index.mdwn'
--- index.mdwn  2010-01-06 17:45:01 +0000
+++ index.mdwn  2010-01-06 17:48:47 +0000
@@ -8,5 +8,5 @@
 [[inline pages="posts/* and !posts/*/*"]]
 
 
-[[!edittemplate template="posttemplate" match="posts/* and !posts/*/*"
+[[edittemplate template="posttemplate" match="posts/* and !posts/*/*"
    silent=yes]]

=== added file 'posttemplate.mdwn'
--- posttemplate.mdwn   1970-01-01 00:00:00 +0000
+++ posttemplate.mdwn   2010-01-06 17:46:40 +0000
@@ -0,0 +1,2 @@
+[[!meta title=""]]
+[[!tag ]]

=== modified file 'index.mdwn'
--- index.mdwn  2009-08-11 08:45:38 +0000
+++ index.mdwn  2010-01-06 17:45:01 +0000
@@ -6,3 +6,7 @@
 also [identi.ca](http://identi.ca/liw).
 
 [[inline pages="posts/* and !posts/*/*"]]
+
+
+[[!edittemplate template="posttemplate" match="posts/* and !posts/*/*"
+   silent=yes]]

=== modified file 'style.css'
--- style.css   2010-01-06 17:39:00 +0000
+++ style.css   2010-01-06 17:42:24 +0000
@@ -148,7 +148,7 @@
     bottom: 0em;
 }
 
-#menu ul, #menu ol {
+#menu ul {
     list-style: none;
 }
 
@@ -193,7 +193,7 @@
     margin-left: 2em;
 }
 
-#main_inner ul {
+#main_inner ul, #main_inner ol {
     margin-bottom: 2.0em;
 }
 

=== modified file 'style.css'
--- style.css   2009-09-09 14:16:47 +0000
+++ style.css   2010-01-06 17:39:00 +0000
@@ -148,7 +148,7 @@
     bottom: 0em;
 }
 
-#menu ul {
+#menu ul, #menu ol {
     list-style: none;
 }
 

=== removed file 'tag/privacy2.mdwn'
--- tag/privacy2.mdwn   2008-09-29 13:50:47 +0000
+++ tag/privacy2.mdwn   1970-01-01 00:00:00 +0000
@@ -1,3 +0,0 @@
-This tag is for blog posts that are about privacy.
-
-[[inline archive=yes pages="link(tag/privacy)"]]

=== removed directory 'posts/tag'
=== removed file 'posts/tag/politics.mdwn'
--- posts/tag/politics.mdwn     2008-07-08 20:18:15 +0000
+++ posts/tag/politics.mdwn     1970-01-01 00:00:00 +0000
@@ -1,3 +0,0 @@
-This tag is for log entries about politics.
-
-[[inline archive=yes pages="link(tag/politics)"]]

=== added file 'tag/free-software.mdwn'
--- tag/free-software.mdwn      1970-01-01 00:00:00 +0000
+++ tag/free-software.mdwn      2009-12-31 08:03:30 +0000
@@ -0,0 +1,3 @@
+This tag is for blog posts about software freedom and open source.
+
+[[inline archive=yes pages="link(tag/free-software)"]]

=== added file 'tag/markdown.mdwn'
--- tag/markdown.mdwn   1970-01-01 00:00:00 +0000
+++ tag/markdown.mdwn   2009-12-31 08:01:25 +0000
@@ -0,0 +1,3 @@
+This tag is for blog posts about [Markdown](http://daringfireball.net/projects/markdown/), the markup language.
+
+[[inline archive=yes pages="link(tag/markdown)"]]

=== added file 'posts/free-software-parenting.mdwn'
--- posts/free-software-parenting.mdwn  1970-01-01 00:00:00 +0000
+++ posts/free-software-parenting.mdwn  2009-12-31 07:58:36 +0000
@@ -0,0 +1,47 @@
+[[!meta title="On free software parenting"]]
+[[!tag rant free-software markdown]]
+
+I believe
+[Jeff Atwood](http://www.codinghorror.com/blog/archives/001317.html)
+is fundmentally wrong in his recent blog
+article [Responsible Open Source Code Parenting](http://www.codinghorror.com/blog/archives/001317.html).
+
+In his article, Atwood bases all criticism of 
+[John Gruber's](http://daringfireball.net/) behavior with regards
+to [Markdown](http://daringfireball.net/projects/markdown/) on this 
+premise:
+
+> As Markdown's "parent", John has a few key responsibilities in 
+> shepherding his baby to maturity. Namely, to lead. To set direction. 
+
+When someone releases some free software, they have no obligation
+whatsoever to do anything with or for it again. No legal obligations,
+and no moral ones. Unless there is some kind of explicit contract
+the author is free to forget anything ever happened.
+
+It's obviously nice if the author assumes responsibility
+for further development and leadership and whatever, but it has to
+happen voluntarily or be compensated.
+
+This is an important difference from the proprietary world Atwood
+is more familiar with. With proprietary software, the user is pretty
+much always a customer, and a customer has rights, one of them being
+that the software works and problems get fixed. With free software,
+the user is a receiver of a surprise gift.
+
+Now, as far as the Markdown situation is concerned, the facts seem
+to be that Gruber does not develop the specification or reference
+implementation, but other people would like things to improve.
+
+In the free software world, the best thing to do in this scenario
+is to gather the people who want to make improvements, have them
+collaborate and take over development, thank Gruber, and make
+the world a better place. Or, vigorously waving a spatula,
+fork, fork, fork.
+
+There's a whole bunch of people using and relying on Markdown
+now. Atwood's [Stack Overflow](http://stackoverflow.com/) site
+is one of the prominent ones. There's implementations for many
+programming languages. There's other sites using Markdown.
+All of these people could (I am reluctant to say should) start
+a "Markdown Foundation", so to speak, and get to work.

=== added file 'posts/bzr-ooo-support/comment_2._comment'
--- posts/bzr-ooo-support/comment_2._comment    1970-01-01 00:00:00 +0000
+++ posts/bzr-ooo-support/comment_2._comment    2009-12-18 21:53:50 +0000
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~lifeless"
+ subject="diff is already hookable, merge hook is in review"
+ date="2009-12-18T21:53:49Z"
+ content="""
+diff is already hookable, merge hook is in review
+"""]]

=== added directory 'posts/bzr-ooo-support'
=== added file 'posts/bzr-ooo-support/comment_1._comment'
--- posts/bzr-ooo-support/comment_1._comment    1970-01-01 00:00:00 +0000
+++ posts/bzr-ooo-support/comment_1._comment    2009-12-10 12:59:04 +0000
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="http://madduck.net/"
+ subject="merge drivers"
+ date="2009-12-10T12:59:03Z"
+ content="""
+Git has a concept of diff & merge drivers: http://git.or.cz/gitwiki/GitTips#HowtousegittotrackOpenDocument.28OpenOffice.2CKoffice.29files.3F
+
+Arguably, there's a lot of work to be done, and it should also be possible to merge, not just diff.
+"""]]

=== added file 'posts/bzr-ooo-support.mdwn'
--- posts/bzr-ooo-support.mdwn  1970-01-01 00:00:00 +0000
+++ posts/bzr-ooo-support.mdwn  2009-12-10 05:58:19 +0000
@@ -0,0 +1,16 @@
+[[!meta title="bzr OO.o support?"]]
+[[!tag idea]]
+
+In re [Brian Kuhn's OO.o and version control troubles](http://identi.ca/notice/16400521).
+
+It'd be cool to extend bzr with some plugins to allow it to handle
+or show differences for specific file types in ways that are useful
+for those. For example, OpenOffice.org Writer files are binary
+blobs, and it's difficult to diff them at the moment. However, it would
+be possible to write something that extracts the text from the
+blob, and shows something like a wdiff.
+
+This could be extended to all sorts of file formats. An image diff
+might generate a new image that colors changed parts with red. A
+source code diff might understand the language and work at the
+level of semantic language elements.

=== added file 'posts/geotagging-news.mdwn'
--- posts/geotagging-news.mdwn  1970-01-01 00:00:00 +0000
+++ posts/geotagging-news.mdwn  2009-12-08 13:56:09 +0000
@@ -0,0 +1,8 @@
+[[!meta tag="Geotagging news"]]
+[[!tag idea]]
+
+I wish news sources would use geotagging or something to make
+it easier to find news related to specific geographic areas,
+regardless of topic.
+
+(Perhaps they do and I have missed this?)

=== added file 'posts/brother-ql-550.mdwn'
--- posts/brother-ql-550.mdwn   1970-01-01 00:00:00 +0000
+++ posts/brother-ql-550.mdwn   2009-11-13 13:40:57 +0000
@@ -0,0 +1,26 @@
+[[!meta title="Brother P-touch QL-550 with Ubuntu 9.10 (karmic)"]]
+[[!tag debian ubuntu linux]]
+
+I recently set up my Brother P-touch QL-550 label printer to work
+with CUPS on my laptop, which runs Ubuntu 9.10 (karmic). This
+required installing [ptouch-driver](http://www.diku.dk/hjemmesider/ansatte/panic/P-touch/),
+with some patches, and then hand-editing the PPD file that gets
+created.
+
+I made a very crude .deb package to install the ptouch-driver.
+I have no idea how to package CUPS stuff properly, so I didn't
+even try. I don't intend to maintain this in Debian or Ubuntu,
+I just needed it for myself, so I didn't go to much effor, I'm
+afraid. Perhaps it's useful anyway. I filed a "Request for Package"
+bug in Debian ([555892](http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=555892)) and talked with Till
+Kamppeter from Ubuntu about this, and he has taken a look
+at this (see comments in the bug).
+
+With my package, the generated PPD has some margins that make it
+almost impossible to fit anything on the label. The margins are
+only a few millimeters, but on labels that matters a lot. I fixed
+this by hand-editing the PPD, Till seems to have fixed in a better
+way.
+
+I hope this is useful to someone. The printer itself is pretty
+nice, too bad Brother doesn't provide free drivers.

=== added file 'posts/sftpsync/comment_4._comment'
--- posts/sftpsync/comment_4._comment   1970-01-01 00:00:00 +0000
+++ posts/sftpsync/comment_4._comment   2009-10-25 08:44:36 +0000
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="http://liw.fi/"
+ date="2009-10-25T08:44:36Z"
+ content="""
+Joey, that is ingenious. I'll have to try that when
+I need this the next time.
+"""]]

=== added file 'posts/dimbola-0.0.3.mdwn'
--- posts/dimbola-0.0.3.mdwn    1970-01-01 00:00:00 +0000
+++ posts/dimbola-0.0.3.mdwn    2009-10-24 11:40:49 +0000
@@ -0,0 +1,48 @@
+[[!meta title="Dimbola 0.0.3"]]
+[[!tag dimbola]]
+
+I've just made release version 0.0.3 of 
+[Dimbola](http://dimbola.org/), my photo management app.
+From the NEWS file:
+
+NEW STUFF
+
+* Ratings are now shown as actual stars rather than asterisk 
+  characters (*).
+* Tag name editing now happens in the tag hierarchy, rather than
+  in a popup dialog.
+* Photos can be rated with the 0-5 keys in the thumbnail grid and photo
+  views.
+* Default thumbnail size in the grid is now 200 pixels, because liw got
+  tired of having to adjust it every time he started Dimbola.
+* The Escape key returns from full screen mode in the photo window.
+* Control-W closes the photo window.
+
+CHANGED STUFF
+
+* The thumbnail grid and photo views are now switched via the menu.
+  It was too difficult to find a solution for switching between the
+  them in the tabbed interface, without the tabs occasionally getting
+  focus and making things non-deterministic for the user.
+* Netpbm command line tools are no longer used to do image format
+  conversions. Instead, the internal GdkPixbuf routines do that.
+
+PROBLEMS FIXED
+
+* When adding new tags, the tag hierarchy is kept sorted.
+* When tags are renamed or removed, the updates are immediately shown in the
+  photo's tag list, and the search tag list.
+* Photo's tag list is now insensitive when no photo or more than one photo
+  is selected. It can only be used with one selected photo.
+* When bringing up the popup menu in the photo or search tag list, if
+  no tag is selected, the tag under the cursor is selected. The menu's
+  "remove" menu entry is properly sensitive.
+* The "stop" button at the bottom left of the main window is now properly
+  sensitive, and actually does stop background jobs.
+* The "remove tag" button ("-") at the top of the tag hierarchy is properly
+  sensitive.
+* Folder list can now be scrolled.
+* Dialog windows are transient for the main window. This helps the window
+  manager position them properly.
+* Thumbnail grid and photo view have a visual focus indicator and grab the
+  focus when clicked upon.

=== added file 'posts/sftpsync/comment_3._comment'
--- posts/sftpsync/comment_3._comment   1970-01-01 00:00:00 +0000
+++ posts/sftpsync/comment_3._comment   2009-10-23 16:57:29 +0000
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ date="2009-10-23T16:57:28Z"
+ content="""
+sshfs uses sftp underneath, and you can run regular rsync on top of it.
+
+(I've come to love sshfs lately for ad-hoc temporary remote mounting from anything to anything.)
+"""]]

=== added file 'posts/sftpsync/comment_2._comment'
--- posts/sftpsync/comment_2._comment   1970-01-01 00:00:00 +0000
+++ posts/sftpsync/comment_2._comment   2009-10-23 11:38:50 +0000
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="http://dagobart.wordpress.com/"
+ subject="google rsync over sftp"
+ date="2009-10-23T11:38:49Z"
+ content="""
+http://www.google.com/search?q=rsync+over+sftp looks good.
+"""]]

=== added directory 'posts/sftpsync'
=== added file 'posts/sftpsync/comment_1._comment'
--- posts/sftpsync/comment_1._comment   1970-01-01 00:00:00 +0000
+++ posts/sftpsync/comment_1._comment   2009-10-23 10:49:14 +0000
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="http://liw.fi/"
+ subject="lftp"
+ date="2009-10-23T10:49:13Z"
+ content="""
+It seems lftp may be able to do at least some of this.
+"""]]

=== added file 'posts/sftpsync.mdwn'
--- posts/sftpsync.mdwn 1970-01-01 00:00:00 +0000
+++ posts/sftpsync.mdwn 2009-10-23 09:14:03 +0000
@@ -0,0 +1,7 @@
+[[!meta title="sftpsync"]]
+[[!tag idea]]
+
+Sometimes I need to synchronize a file or directory tree
+between two machines, but can't use rsync, and only have
+sftp. I wish there was a tool like rsync that would work
+with sftp only.

=== added file 'posts/ninja-school.mdwn'
--- posts/ninja-school.mdwn     1970-01-01 00:00:00 +0000
+++ posts/ninja-school.mdwn     2009-10-15 14:39:35 +0000
@@ -0,0 +1,29 @@
+[[!meta title="Ninja school taunting"]]
+[[!tag note-to-self]]
+
+I had a dream the night before last. I had enrolled into a ninja school,
+and I thought I would learn all about being invisible and climbing walls
+and ceilings. However, when we got to the school, they had taken in a busload
+of tourists whose bus had broken down. The tourists were noisy, nosy, and
+nauseating. They were everywhere, and we couldn't get a moment's respite
+from them.
+
+I was getting angrier, and angrier, and started confronting the
+tourists. This made things worse. Not only would they escalate, they
+would gang up on me. Just at the time when I was about to start throwing
+stuff at them, I realized that his was not how ninjas should do it.
+Ninjas should be smart enough that they don't need to
+do direct fighting.
+
+I calmed myself down, and took a step back, and decided to ignore the
+idiots. After just a little while, when they realized they couldn't
+get any reaction from me, not even a glance, they started ignoring me
+and concentrated their efforts on the other students.
+
+That's when the professors told me I had graduated. It turns out that
+all the invisibility and climbing is just silliness. The real essence of
+being a ninja is ignoring taunts.
+
+"Don't feed the trolls!" is the silent ninja war cry? Who knew.
+
+I wish I could learn that kind of thing awake.

=== added file 'posts/distributed-bug-tracking/comment_2._comment'
--- posts/distributed-bug-tracking/comment_2._comment   1970-01-01 00:00:00 +0000
+++ posts/distributed-bug-tracking/comment_2._comment   2009-10-15 04:47:39 +0000
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="http://liw.fi/"
+ subject="Artifact"
+ date="2009-10-15T04:47:38Z"
+ content="""
+Artifact isn't free software, so I can't examine it to give
+an informed comment. Off the top of my head: since a bug
+report is primarily a discussion among various people
+(bug reporter, other people experiencing the bug, 
+developers, etc), e-mail is the most natural way to
+represent it. It is also the least lossy. Re-inventing
+RFC2822 in XML is not worth it, in my mind.
+
+Other than that, I have no comment on Artifact.
+"""]]

=== added file 'posts/distributed-bug-tracking/comment_1._comment'
--- posts/distributed-bug-tracking/comment_1._comment   1970-01-01 00:00:00 +0000
+++ posts/distributed-bug-tracking/comment_1._comment   2009-10-14 19:56:10 +0000
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://sheremetyev.livejournal.com/"
+ subject="Data format for distributed bug tracking system"
+ date="2009-10-14T19:56:09Z"
+ content="""
+We've create a file-based bug tracker [Artifacts](http://www.versioned.com/artifacts/) that can keep data under any version control system (including distributed one) and uses simple XML as data format. Would be interesting to know your opinion about the approach and implementation. Thanks!
+
+"""]]

=== added file 'posts/effi-juliste-sananvapaus-2009.mdwn'
--- posts/effi-juliste-sananvapaus-2009.mdwn    1970-01-01 00:00:00 +0000
+++ posts/effi-juliste-sananvapaus-2009.mdwn    2009-10-14 15:11:23 +0000
@@ -0,0 +1,17 @@
+[[!meta title="Effi sananvapaus-juliste"]]
+[[!tag in-finnish politics]]
+
+Quick English summary: Made freedom-of-speech poster for Effi.
+Source files now available.
+
+Tein kesällä sananvapausaiheisen julisteentapaisen Effille.
+
+<img alt="juliste"
+     src="http://files.liw.fi/effi-juliste-sananvapaus-2009-pieni.jpg"
+/>
+
+Tiedostot löytyvät nyt tuolta:
+
+<http://files.liw.fi/effi-juliste-sananvapaus-2009.zip>
+
+Lisensoitu CC-BY-SA 3.0.

=== added file 'posts/dimbola-tag-system/comment_2._comment'
--- posts/dimbola-tag-system/comment_2._comment 1970-01-01 00:00:00 +0000
+++ posts/dimbola-tag-system/comment_2._comment 2009-10-13 10:07:33 +0000
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="http://liw.fi/"
+ subject="Teaching machines"
+ date="2009-10-13T10:07:32Z"
+ content="""
+Thanks for your comment. I don't know what you mean
+by \"notion\", and I'm not particularly interested in
+experimental approaches to teaching meaning to machines.
+
+I don't reject them, but as long as they don't aid
+me in quickly making Dimbola a useful tool for myself,
+and hopefully others, I am unfortunately not going
+to work on them. Maybe when Dimbola has become a
+useful tool otherwise, who knows what will happen.
+
+"""]]

=== added directory 'posts/dimbola-tag-system'
=== added file 'posts/dimbola-tag-system/comment_1._comment'
--- posts/dimbola-tag-system/comment_1._comment 1970-01-01 00:00:00 +0000
+++ posts/dimbola-tag-system/comment_1._comment 2009-10-11 23:32:05 +0000
@@ -0,0 +1,6 @@
+[[!comment format=mdwn
+ username="http://dagobart.wordpress.com/"
+ date="2009-10-11T23:32:04Z"
+ content="""
+To address several of the issues you mention in the post, I answered in a blog post of my own. Apparently there's no trackback, hence, here's the poist's URL: http://wrs-mom.blogspot.com/2009/10/applying-tags-implicity-to-photo.html
+"""]]

=== added directory 'posts/listat-eivat-ole-demokratiaa'
=== added file 'posts/listat-eivat-ole-demokratiaa/comment_1._comment'
--- posts/listat-eivat-ole-demokratiaa/comment_1._comment       1970-01-01 00:00:00 +0000
+++ posts/listat-eivat-ole-demokratiaa/comment_1._comment       2009-10-11 23:32:05 +0000
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="TommiVainikainen"
+ subject="Hyviä huomioita, mutta Condorcet on myöskin ongelmallinen"
+ date="2009-09-03T20:50:48Z"
+ content="""
+Esitit hyviä huomioita, mutta pitää muistaa, että Condorcetin menetelmä ei ole suhteellinen vaan enemmistövaali. Käytännössä siis Condorcet johtaisi luultavasti kaksipuoluejärjestelmään, jossa voittaja vie koko potin. Erityisesti listavaaleja on esitetty niihin äänestyksiin, joissa nyt on käytössä suhteellinen d'Hondtin menetelmä. Jos (ja kun) vaalien suhteellisuus halutaan säilyttää, niin tilalle tulisi ottaa esimerkiksi siirtoäänimenetelmä, eikä mitään Condorcetin menetelmistä.
+
+Sen sijaan presidentinvaaleihinhan Condorcet olisi mainio. Sillä säästettäisiin myös rahaa kun ei tarvitsisi järjestää toista kierrosta.
+"""]]

=== added file 'posts/listat-eivat-ole-demokratiaa/comment_2._comment'
--- posts/listat-eivat-ole-demokratiaa/comment_2._comment       1970-01-01 00:00:00 +0000
+++ posts/listat-eivat-ole-demokratiaa/comment_2._comment       2009-10-11 23:32:05 +0000
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://liw.fi/"
+ subject="Arto Satonen pitkistä listoista"
+ date="2009-09-25T18:12:57Z"
+ content="""
+<http://www.satonen.fi/2009/09/25/pitkia-listoja-ei-tarvita/>:
+
+> RAY:n entisen puheenjohtajan Jukka Vihriälän esitys pitkistä listoista on suorastaan surkuhupaisa. Sekö palauttaisi luottamuksen politiikkaan, että katkaistaisiin äänestäjän ja kansanedustajan välinen suhde. Pitkissä listoissa edustaja ei valituksi tullakseen tarvitse kansan tukea, vaan ainoastaan oman poliittisen järjestönsä aktiivien tuen.
+
+"""]]

=== added file 'posts/dimbola-0.0.2.mdwn'
--- posts/dimbola-0.0.2.mdwn    1970-01-01 00:00:00 +0000
+++ posts/dimbola-0.0.2.mdwn    2009-10-11 15:48:58 +0000
@@ -0,0 +1,9 @@
+[[!meta title="Dimbola 0.0.2"]]
+[[!tag dimbola]]
+
+I've just pushed out version 0.0.2 of Dimbola, my fledgling
+photo management application.
+
+See <http://dimbola.org/> for more info, and
+[the NEWS file](http://bazaar.launchpad.net/%7Edimbola-team/dimbola/trunk/annotate/head%3A/NEWS)
+for a summary of what's new in the new version.

=== added file 'tag/lca2010.mdwn'
--- tag/lca2010.mdwn    1970-01-01 00:00:00 +0000
+++ tag/lca2010.mdwn    2009-10-10 15:57:30 +0000
@@ -0,0 +1,5 @@
+This tag is for blog posts that intended for the 
+[Linux Conf Australia 2010](http://www.lca2010.org.nz/)
+Planet.
+
+[[inline archive=yes pages="link(tag/lca2010)"]]

=== added file 'posts/dimbola-tag-system.mdwn'
--- posts/dimbola-tag-system.mdwn       1970-01-01 00:00:00 +0000
+++ posts/dimbola-tag-system.mdwn       2009-10-10 07:45:24 +0000
@@ -0,0 +1,86 @@
+[[!meta title="Tags in Dimbola"]]
+[[!tag dimbola photography]]
+
+I've been thinking about how tags should work in Dimbola,
+or in general. Tags
+are an important tool for managing a large collection of photos,
+and it's important they work well.
+
+So far, I have a simple hierarchical tag system. Tags have a free-form
+name, and can be arranged in a tree. The hierarchy is quite important
+so that one can have things like this:
+
+    * Location
+      * Europe
+        * Finland
+          * Espoo
+          * Helsinki
+          * Vantaa
+        * Sweden
+          * Stockholm
+      * Oceania
+        * New Zealand
+          * Auckland
+          * Wellington
+        * Timor-Leste
+      * Off-planet
+    * Animal
+      * Invertebrae
+      * Mammal
+
+When you add a tag like "Helsinki" to a photo, you implicitly also
+add all of its parents: "Finland", "Europe", and "Location". This
+should will reduce the amount of effort it takes to make all photos
+have extensive tags.
+
+This much already works. I'm wondering what else I could add to the
+tag system. For example, it would be good to be able to share the 
+tag hierarchy one makes with others, and merge theirs into one's own.
+This way, photographers could collaborate to create a shared generic
+tag hierachy, reducing the amount of work they each have to do to
+get a good one. 
+
+There could be several collections of tag
+hierarchies that could be stacked: a general one, plus ones
+specific to particular areas. A bird photographer might need
+to differentiate between very minute variations of a particular
+species, whereas I might only care between the difference
+between "big bird" and "small bird".
+
+What can I do to make such collaboration easier? Obviously I need
+to add export and import of the tag hierarchy to and from files,
+with automatic merging when importing. But I'm thinking there might
+be tags one doesn't want to share with others, such as names of
+people. So, a tag might have a private/public flag.
+
+The private/public flag could be used to control what tags get 
+added to a photo when it is exported, or shown in a web gallery,
+but it might be necessary to have a different control for that.
+For example, although "Location" is probably best kept as a
+public tag, it might be silly to show it on a web gallery.
+
+Sometimes it might be nice to have aliases for a tag. For example,
+when you're trying to find photos of a particular animal, it might
+have several names: at least the common name, and the scientific
+classification in Latin. There might be several common names:
+donkey and ass.
+
+Should it be possible for two tags to have the same name? For example,
+two cities in different countries might have the same name, and it
+would be awkward to have to encode that into the name instead of
+the hierarchy just for those cities, when everything else has it in
+the hierarchy. But will the user get confused by this? How will they
+tell which Paris is being referred to?
+
+Perhaps tags should have descriptions that can be looked up easily? This
+might be useful for other purposes as well. And if you're getting a tag
+hierarchy from someone else, they might have added a tag for something
+you don't know, and would it then be nice to be able to either see the
+description right there, or at least easily look it up in Wikipedia or
+(failing that) some search engine?
+
+Should tags have translations to other languages? Possibly, though
+that's going to get all kinds of tricky.
+
+What else should the perfect tag system for photo management do?
+Any ideas, anyone?

=== added file 'tag/books.mdwn'
--- tag/books.mdwn      1970-01-01 00:00:00 +0000
+++ tag/books.mdwn      2009-10-07 18:25:40 +0000
@@ -0,0 +1,3 @@
+This tag is for blog posts that are about books.
+
+[[inline archive=yes pages="link(tag/books)"]]

=== added file 'posts/elamapeli.mdwn'
--- posts/elamapeli.mdwn        1970-01-01 00:00:00 +0000
+++ posts/elamapeli.mdwn        2009-10-07 18:24:42 +0000
@@ -0,0 +1,43 @@
+[[!meta title="Kirja-arvostelu: Elämäpeli, Ville Vuorela"]]
+[[!tag in-finnish books]]
+
+Kiisto: Olen tuntenut Villen reilun vuosikymmenen ja olemme 
+pelanneet myös yhdessä. Tämä väistämättä värittää
+käsityksiäni hänen kirjastaan. En kuitenkaan harrasta
+pelaamista enkä ole ikinä ollut pelialalla töissä.
+
+Ville Vuorelan **Elämäpeli** on muistelma- ja mielipidekirja, jossa hän
+kertoo urastaan peliteollisuudessa. Ville on ehtinyt koluta läpi
+useamman suomalaisen pelitalon ja kokemuksia riittää kerrottavaksi
+hyvinkin yhden kirjan verran.
+
+Ville vuorottelee anekdoottien ja mielipiteiden purskahdusten
+välillä. Kumpikin on viihdyttävää. Teksti on erinomaisen helppolukuista
+ja kevyttä. Kirja on jaettu luvuittain aiheisiin, joita
+Ville käsittelee joskus huvittuneesti, joskus vihaisena,
+aina kuitenkin mielenkiintoisesti. Vahvat mielipiteet paistavat
+läpi joka asiassa.
+
+Ote onkin kuitenkin kaikkea muuta kuin analyyttinen tai objektiivinen.
+Tämä ei ole oppikirja, vaan pilkahdus pelintekijän sieluun.
+Meille pelialasta mitään tietämättömille tämä antaa kiehtovan
+ikkunan maailmaan, joka muuten olisi täysin läpinäkymätön. Voin
+vain kuvitella, miten pelialalle haluava inostuu tästä kirjasta.
+
+Ville tuo esiin alan ikäviäkin puolia. Työnantajat ja 
+työntekijät ovat usein yhtä epätietoisia työlainsäädännöstä ja
+ala syö itseään, kun projektit ja budjetit paisuvat, mutta hommia
+ei saada tehtyä kunnolla. Isot firmat käyvät valtataistelua
+kampittamalla alihankkijoitaan. Ja niin päin pois.
+
+Tästä huolimatta kirjasta paistaa läpi se, miten tyytyväinen
+Ville on, kun on unelmaurallaan. Välillä turhauttaa, mutta
+sitten mennään taas lujaa.
+
+Lukija jää kuitenkin ehkä kaipaamaan pientä punaista lankaa,
+joka vetäisi teoksen hivenen tiukempaan kasaan. Jotakin synteesiä, 
+joka jättäisi käteen muutakin kuin kasan kohtauksia.
+
+Silti tämä on tuore, todenmakuinen tuulahdus peliteollisuudesta. Suosittelen.
+
+PS. Tämä kirja varmasti kannattaisi kääntää englanniksi.

=== added file 'posts/stop-sending-email.mdwn'
--- posts/stop-sending-email.mdwn       1970-01-01 00:00:00 +0000
+++ posts/stop-sending-email.mdwn       2009-10-06 18:16:01 +0000
@@ -0,0 +1,65 @@
+[[!meta title="Stop sending e-mail?"]]
+[[!tag rant productivity]]
+
+Jeff Atwood writes about e-mail in [Email: The Variable Reinforcement
+Machine](http://www.codinghorror.com/blog/archives/001302.html). He's
+right: people are using the e-mail system badly.
+
+E-mail is not suitable for all sorts of communication: anything that
+requires high bandwidth or is easily misunderstood is probably best
+handle face-to-face or on the phone. Success e-mail use does require
+attention; but then, so does all other form of communication.
+
+Like many others, part of his solution is to convert people to use other
+conduits for communication, and in this he makes a mistake. He suggests
+people switch to proprietary silos such as Twitter, and Facebook. This
+is an utter abomination. It ruins the ability of people to reach each
+other, unless they all agree to kiss their privacy and freedom goodbye.
+
+In the end, the real problem with e-mail is not the technology, and it's
+not other people. It's you. If you waste much time on e-mail, you're
+doing it wrong.
+
+The amount of time you spend on e-mail is only marginally dependent on
+the amount of e-mail you get, and mainly dependent on your own skills
+in processing e-mail.
+
+The top seven skills in efficient processing of e-mails:
+
+1. **Archive e-mail automatically.** There's no point in wasting time
+   doing it manually.
+1. **Delete e-mails from your inbox(es)** as soon as you're done with
+   them. If you've read it, delete it. If you need to respond to it, or
+   need it to do some task, move it to a dedicated folder. An inbox is
+   only for stuff you haven't read yet. (<http://inboxzero.com/> really
+   works, as does the full GTD system.) If your e-mails are archived
+   upon arrival, you can always safely remove them from your inbox.
+1. **Respond at once.** If it takes less than a couple of minutes, do it
+   at once, then delete the e-mail and never bother with it again.
+1. **Stop useless e-mail.** Unsubscribe from mailing lists, unless you
+   really need them. Stop people from sending jokes to the company-wide
+   list (set up a separate joke list?). If you can't stop them from
+   sending useless stuff to you, learn to filter it so you never see it.
+   (If you do the filtering after archiving, you can filter pretty
+   freely, safe in the knowledge that you can dig up a mis-filtered
+   e-mail from the archive if need be.)
+1. **Skim.** Almost always, important e-mails are easy to spot and
+   everything else can be quickly skimmed and then discarded. Often whole
+   novels' worth of e-mails can be discarded based on the subject line.
+1. **Do e-mail in batches.** There is no point in monitoring your inboxes
+   constantly. E-mail by nature is not speed critical (and anyone who
+   treats it as such will lose). So read e-mail every morning, lunchtime,
+   and evening. Or whatever schedule works for you. You don't have to have
+   fixed times: you can do it between other tasks, or while waiting
+   for the computer to run a test suite, or whatever fits you. Just don't
+   keep the e-mail app open and demanding attention all the time.
+1. **Use a competent spam filter.** At best, I've received over 4000
+   e-mails per day, around 80-90% of it spam. Either bogofilter or
+   crm114 are able to get rid of all but a dozen or so spams, with no
+   false positives for weeks, at best (that's when I stopped keeping
+   track).
+
+Use e-mail for what it's meant for: asynchronous, non-time-critical
+correspondence. Moving that stuff to some other system will only
+solve problems temporarily. Eventually the new system will have
+useless time-wasters flooding it, too.

=== added file 'posts/street-photography.mdwn'
--- posts/street-photography.mdwn       1970-01-01 00:00:00 +0000
+++ posts/street-photography.mdwn       2009-10-06 14:12:46 +0000
@@ -0,0 +1,32 @@
+[[!meta title="Street photography"]]
+[[!tag photography]]
+
+[The Online Photographer](http://theonlinephotographer.com) is
+perhaps my favorite photography blog. Today, it has an [article
+by Ken Tanaka](http://theonlinephotographer.typepad.com/the_online_photographer/2009/10/on-city-streets.html), on a 
+new book with street photographs by Gary Stochl. Tanaka
+includes this statement:
+
+> [W]hat makes this work so darn good is that it so perfectly embodies 
+> the four ingredients required to create good candid street imagery; an 
+> imaginative eye, the ping-pong timing reflexes to react to that 
+> imagination, the technical skill to actually use a camera to get the 
+> shot, and, most importantly, the courage to actually do it.
+
+I'm not familiar with Stochl's work, but I think Tanaka has a
+good summary of good street photography.
+
+I've long been intrigued by street photography. At times, I think
+I'd like to try it seriously. However, one of the things that
+worries me is the issue of privacy.
+
+Normally, when you publish a photograph of someone, when they're
+not just a small detail in the picture but the main topic, you
+need to get their approval, even if they were in a public place
+when the photo was taken.
+
+This is entirely impractical with street photography. You can't
+go around taking pictures and then running after people to get them
+to sign model releases.
+
+I've no idea how professionals deal with this.

=== added file 'posts/retired-from-debian.mdwn'
--- posts/retired-from-debian.mdwn      1970-01-01 00:00:00 +0000
+++ posts/retired-from-debian.mdwn      2009-10-06 09:44:34 +0000
@@ -0,0 +1,6 @@
+[[!meta title="Retired from Debian"]]
+[[!tag debian]]
+
+I have retired from Debian today, in order to concentrate on
+other things that are, currently, more fun, such as attempting
+to become an upstream kind of guy.

=== added file 'posts/viimeinkin-sananvapauden-rajoitusta.mdwn'
--- posts/viimeinkin-sananvapauden-rajoitusta.mdwn      1970-01-01 00:00:00 +0000
+++ posts/viimeinkin-sananvapauden-rajoitusta.mdwn      2009-10-05 05:00:33 +0000
@@ -0,0 +1,52 @@
+[[!meta title="Viimeinkin jotain rajaa holtittomalle sananvapauden käytölle mediassa!"]]
+[[!tag in-finnish finnish-politics rant]]
+
+Keskisuomalaisen entinen päätoimittaja Erkki Laatikainen on rohkea
+mies. Hän astui lauantaina riskeistä välittämättä esiin ja ehdotti 
+Suomeen
+sitä, mitä pitkään on kaivattukin: lakia, jolla median holtitonta
+sananvapauden käyttöä suitsitaan.
+
+Laatikainen nostaa pöydälle ison kissan: media, saa kritisoida päättäjiä miten lystää. Tähän
+on saatava loppu. Miten voimme ikinä nousta sellaisten maailman
+suurvaltojen joukkoon kuin 
+[Italia](http://www.hs.fi/ulkomaat/artikkeli/Roomassa+osoitettiin+mielt%C3%A4+Berlusconin+mediavaltaa+vastaan/1135249784095) tai
+[Valko-Venäjä](http://yle.fi/uutiset/ulkomaat/2009/05/lukashenkolta_varovaisia_lupauksia_uudistuksista_720870.html)
+jos poliittiset päättäjämme eivät saa tehdä mitä huvittaa.
+
+Sarkasmi sikseen.
+
+Laatikainen on oikeassa siinä, että medialla on valtaa ja se
+voi käyttää sitä väärin, joten se tarvitsee jotakin tasapainottamaan
+itseään. Hän on jopa oikeassa siinä, että viime kädessä tämä
+tapahtuu lakien ja oikeusistuimien kautta.
+
+Hänen esittämänsä tapa on kuitenkin aivan järkyttävän karmea.
+Hän esittää uutta kiihottamisen vastaista lakia tai pykälää
+ja käyttää mallina olemassaolevaa kansanryhmen vastaisen 
+kiihottamisen pykälää. Tämä pykälä kuitenkin toimii huonosti:
+koko kiihottamisen käsite on epämääräinen ja niinpä
+syytteitä ja nyt tuomioitakin tulee vähintäänkin omituisin 
+perustein.
+
+Vaikka pykälä toimisikin hyvin, tuomioistuimet eivät millään
+ehdi käsittelemään kaikkia tapauksia, eivätkä tarpeeksi
+nopeasti. Koska medialla on kuin onkin demokraatiassa
+vallankäyttäjien vahtikoiran rooli, se kertoo mahdollisista
+väärinkäytöksistä usein, jopa päivittäin. Oikeustapausten
+käsittelyajat ovat kuukausia tai vuosia.
+
+Me emme tarvitse lisää anti-kiihottamista. Me tarvitsemme
+journalistisen muutoksen, jossa media huomaa, että se on itsekin
+vallankäyttäjä ja sen tarvitsee siis toimia myös itsensä
+vahtikoirana. Jos YLE töpeksii ja väittää perättömiä
+pääministerin talonrakennuksesta, muun median pitää paljastaa
+tämä. (En tiedä mikä tilanne YLEn ja Vanhasen kohdalla on. Tiedän
+sen, että pääministeri järjesti poliittisen teatterin
+voittaakseen luottamuslauseäänestyksessä.)
+
+Tätä itseään vahtivaa vahtikoiraa ei saada aikaan lakeja
+muuttelemalla aina, kun vallassa olevaa puoluetta julkisesti
+epäillään väärinkäytöksistä. Se saadaan aikaan oikealla kilpailutilanteella
+suomalaisessa mediassa ja sillä, että kansaa kiinnostaa
+muukin kuin Big Brother.

=== added file 'posts/death-of-parody.mdwn'
--- posts/death-of-parody.mdwn  1970-01-01 00:00:00 +0000
+++ posts/death-of-parody.mdwn  2009-10-01 06:42:57 +0000
@@ -0,0 +1,21 @@
+[[!meta title="The death of parody in Finland"]]
+[[!tag finnish-politics]]
+
+Matti Nikki, a Finnish activist for freedom of speech,
+has yesterday been convicted for using parody. He criticized
+police-like actions by a pro-children group by creating a similar
+website to the group's, and the group promptly sued him.
+
+In the court's decision, Nikki's site is summarily declared
+as not being parody (no reasons given), and this failure to be
+parody is justification for higher damages.
+
+I gave a quote to the [Effi](http://effi.org/) 
+[press release](http://effi.org/julkaisut/tiedotteet/lehdistotiedote-2009-09-30.html) about this.
+
+Some days I wonder if the entire moral integrity of Finland
+is disintegrating. Basic freedoms (freedom of speech, privacy,
+especially) are under constant attack, while politicians
+(including the prime minister) are involved in a year-long
+election campaign financing scandal that keeps getting worse
+almost by the day.

=== added file 'tag/electric-car.mdwn'
--- tag/electric-car.mdwn       1970-01-01 00:00:00 +0000
+++ tag/electric-car.mdwn       2009-09-25 12:54:53 +0000
@@ -0,0 +1,3 @@
+This tag is for blog posts about electric cars.
+
+[[inline archive=yes pages="link(tag/electric-car)"]]

=== added file 'posts/sahkoautojen-vero-pois.mdwn'
--- posts/sahkoautojen-vero-pois.mdwn   1970-01-01 00:00:00 +0000
+++ posts/sahkoautojen-vero-pois.mdwn   2009-09-25 12:53:04 +0000
@@ -0,0 +1,25 @@
+[[!meta title="Sähköautojen vero pois!"]]
+[[!tag in-finnish finnish-politics electric-car]]
+
+Helsingin sanomat uutisoi, että [Helsingin Energia tekee ensimmäisen sähköautojen latauspisteen Kamppiin](http://www.hs.fi/talous/artikkeli/Helsingin+Energia+tekee+ensimm%C3%A4isen+s%C3%A4hk%C3%B6autojen+latauspisteen+Kamppiin/1135249585447?ref=rss).
+Aivan loistava uutinen.
+
+Sähköautoja ei vielä ole suomalaisessa liikenteessä kovin
+monta. Niitä on tulossa markkinoille pian ja olisi toivottavaa,
+että ne pikaisesti yleistyisivät.
+
+HS:n uutisessakin mainitaan, että sähköautoja verotetaan
+nyt yhtä rankasti kuin muitakin autoja. Tämä on törkeä
+epäkohta ja siihen tulisi saada pikaisesti muutos.
+
+Ei ole mitään syytä, miksi eduskunta ei voisi jo tänä syksynä
+säätää lakia, joka poistaisi sähköautoilta verotuksen.
+
+Autovero on tietysti tärkeä tulonlähde valtiolle, mutta se
+ei ole riittävä syy kampittaa sähköautojen markkinoilletuloa.
+Polttomoottoreiden haitat ovat sen verran suuria, että niistä
+aiheutuvat kulut ovat pitkällä tähtäimellä selvästi isompia kuin
+sähköautojen veronalennuksesta koituvat tulonmenetykset olisivat.
+
+Veronalennuksen tulisi tietenkin olla tilapäinen: kun sähköautot
+ovat valloittaneet markkina, ei ole syytä suosia niitä enempää.

=== added file 'posts/queue-not-stack.mdwn'
--- posts/queue-not-stack.mdwn  1970-01-01 00:00:00 +0000
+++ posts/queue-not-stack.mdwn  2009-09-25 11:09:16 +0000
@@ -0,0 +1,28 @@
+[[!meta title="Queue, don't stack"]]
+[[!tag productivity]]
+
+A tiny productivity tip: When working on something, you often
+think of new things to do. While changing some code, you might
+notice a bug that needs fixing or some code that needs 
+refactoring. Write it down
+and do it later, don't do it at once.
+
+If you do it at once, you will have to interrupt whatever you
+were doing, do a context switch, do the new thing, and then
+do another context switch to get back. Context switches are
+expensive in terms of concentration and time.
+
+A stack of contexts becomes a big problem because you'll likely find
+yet new things while doing the new thing, eventually growing
+the stack quite large. This is not the way to get things done
+efficiently, or at all.
+
+Another example: when researching something on the web, it is
+easy to get lost in a huge web of web pages you need to read.
+Don't interrupt reading one when you hit on a new page you'll
+need to read. Open the new page in a new tab, or put it in
+your bookmarks for later reading.
+
+Of course, sometimes you do need to fix the problem you found,
+because it prevents you from continuing the first thing. Do
+what you must, but no more.

=== added file 'posts/ringtone.mdwn'
--- posts/ringtone.mdwn 1970-01-01 00:00:00 +0000
+++ posts/ringtone.mdwn 2009-09-17 13:52:35 +0000
@@ -0,0 +1,12 @@
+[[!meta title="Phone ringtones and stress"]]
+[[!tag note-to-self]]
+
+I don't like it when someone calls me in the middle of work. 
+It is adding insult to injury that the phone keeps
+ringing while I am walking to it, incessantly hurting my ears
+with its stupid noise. If only I could change the sound it makes...
+
+Oh wait. I can. There, changed to a single beep. Problem solved.
+
+(I did that about a week ago. I am now much less annoyed when
+someone calls me. The relief is quite amazing.)

=== added file 'posts/dimbola-bgjobs.mdwn'
--- posts/dimbola-bgjobs.mdwn   1970-01-01 00:00:00 +0000
+++ posts/dimbola-bgjobs.mdwn   2009-09-16 08:50:53 +0000
@@ -0,0 +1,33 @@
+[[!meta title="Dimbola background processing"]]
+[[!tag programming dimbola]]
+
+I've started to slowly clean up the
+[Dimbola](http://blog.liw.fi/tag/dimbola/) code base. I seem to have
+cut more corners than I thought.
+
+One of the problems was that all processing was done in the 
+main UI thread. Whenever the program was doing something heavy,
+the UI would freeze. This is obviously not good.
+
+After hitting my head often enough against the wall, I've concluded
+that using threads with Python and, especially, GTK+, is too tricky
+to be worthwhile. I much prefer the Python 
+[multiprocessing](http://docs.python.org/library/multiprocessing.html)
+module instead: it reduces the problems of concurrency greatly
+by running things in their own processes, rather than threads.
+
+Given the Python global interpreter lock, this process based
+approach also helps by making it easier to use every CPU core
+available, which can really help with heavy stuff.
+
+I made a module in Dimbola to abstract use of multiprocessing a bit.
+This should make it quite straightforward to do things in the 
+background. The [bgjobs](http://bazaar.launchpad.net/%7Edimbola-team/dimbola/trunk/annotate/head%3A/dimbola/bgjobs.py)
+module might be useful for others, as well.
+
+I hope I got all the details working with this. Even with
+multiprocessing and its queues and other helpers, concurrency
+is a tricky beast.
+
+I've also made the [PyGTK binding magic](http://bazaar.launchpad.net/%7Edimbola-team/dimbola/trunk/annotate/head%3A/dimbola/gtkapp.py)
+I [mentioned earlier](http://blog.liw.fi/posts/pygtk-automatic-connects/) available as a module.

=== added file 'posts/gnome-keyboard-shortcuts.mdwn'
--- posts/gnome-keyboard-shortcuts.mdwn 1970-01-01 00:00:00 +0000
+++ posts/gnome-keyboard-shortcuts.mdwn 2009-09-14 12:18:48 +0000
@@ -0,0 +1,25 @@
+[[!meta title="My GNOME keyboard shortcuts"]]
+[[!tag tip gnome]]
+
+One of the semi-hidden features of the GNOME desktop is keyboard shortcuts. They allow you to bind certain actions to specific key
+strokes. I've made the following bindings (or perhaps they came
+as defaults, I no longer remember):
+
+* Alt-Ins opens up my web browser.
+* Alt-Home opens up my home folder.
+* Alt-PageUp maximizes the current window vertically.
+* Alt-End opens a terminal window.
+* Shift-Control-Up arrow increases volume.
+* Shift-Control-Down arrow decreases volume.
+* Shift-Control-Space toggles audio play/pause.
+
+I use these all the time, probably dozens of times per day. 
+
+On many keyboards
+there are special keys you can bind to the actions. However, I use
+a Das Keyboard, with just the basic 105 keys of the European PS/2
+layout, and thus I prefer the Alt/Shift/Control combos.
+
+I used to have panel launchers for some of these, but they required
+aiming and clicking with the mouse. These keyboard shortcuts are
+much more efficient.

=== modified file 'style.css'
--- style.css   2009-09-09 14:12:29 +0000
+++ style.css   2009-09-09 14:16:47 +0000
@@ -397,3 +397,8 @@
 height: 60ex;
 }
 
+
+div.comment {
+margin-top: 5ex;
+}
+

=== modified file 'style.css'
--- style.css   2008-04-09 16:53:23 +0000
+++ style.css   2009-09-09 14:12:29 +0000
@@ -389,3 +389,11 @@
 .normalPC { font-size: 100%; }
 .bigPC { font-size: 115%; }
 .biggestPC { font-size: 130%; }
+
+#subject, #editcontent  {
+width: 100%;
+}
+#editcontent {
+height: 60ex;
+}
+

=== added file 'posts/dimbola-poc.mdwn'
--- posts/dimbola-poc.mdwn      1970-01-01 00:00:00 +0000
+++ posts/dimbola-poc.mdwn      2009-09-08 18:52:28 +0000
@@ -0,0 +1,117 @@
+[[!meta title="Dimbola prototype: a photo organizer"]]
+[[!tag dimbola]]
+
+I have not yet found a tool I like to help me manage my digital 
+photographs.
+I've looked at a number of them, and they are all aimed at other people
+than me.
+
+Here's the workflow I want to have, more or less:
+
+* Shoot some frames.
+* Download images (via card reader) to a suitable location.
+* Make backups of the images, so that there's two copies on two hard disks.
+* Format memory card.
+* Process new images (from one or more shoots):
+  add tags, rate images, set ownership and copyright fields, etc
+* Automatically, in the background: generate preview images from RAW images,
+  and do other heavy tasks, without interfering with interactive use.
+
+After this, things get non-linear. Some of the following things will
+be done to some but not all images.
+
+* Quickly, efficiently find images based on various criteria.
+* Set raw conversion parameters, if defaults are not OK.
+  (Note that raw conversion should be done as needed, not necessarily for
+  all images at once, except for preview generation. If raw conversion
+  parameters are changed, previews and thumbnails should be updated.)
+* Edit images using internal editor for basic stuff, external one for
+  more complicated changed. Basic stuff includes rotation, cropping,
+  some color
+  manipulation, sharpening, perhaps a bit more. Multiple versions of an
+  image should be possible, and the original camera-generated file must
+  never be modified at all. Ideally, modifications are stored as
+  "scripts" rather than new bitmaps. Scripts should be applicable to
+  several images, since I might need to edit a series of photos in the
+  same way. Also needs to support editing the photo in the GIMP, when
+  that is needed.
+* Export images, in various formats, perhaps to online galleries or
+  online printing services, or just to e-mail people.
+* Print images on a local printer. Perhaps also via online printing
+  services.
+  
+The program that seems to most clearly match my desires is Adobe
+Lightroom, but it's non-free and therefore not an option.
+
+I thought I would see how hard it would be to make something that I
+would find acceptable. Turns out, it is pretty hard, or at least it is a
+lot of work.
+
+But a proof-of-concept prototype only took a couple of weekends and some
+mornings and evenings. It already does many of the things I care about,
+but it does them very, very badly, just well enough to give a glimpse of
+what version 1.0 should be like. The user interface is ugly and has many
+rough edges; the database schema is probably quite childish, but I
+wouldn't know (this was my first time using SQL); the Python code is
+horrific. I expect pretty much everything will have to be re-done. I
+cut every corner I could think of to get this done quickly.
+
+<a href="http://files.liw.fi/dimbola-poc-screenshot.jpg">
+<img src="http://files.liw.fi/dimbola-poc-screenshot-thumb.jpg"
+     alt="Dimbola screenshot" />
+</a>
+
+The code can be found via https://launchpad.net/dimbola . There is no
+.deb package yet, but you can run it from the bzr checkout. Do the
+following (works on Ubuntu karmic, at least):
+
+    bzr get lp:dimbola
+    cd dimbola
+    ./dimbola-gtk
+
+You'll need at least the following installed (Ubuntu karmic packages
+names in parentheses): python 2.6 (python), PyGTK (python-gtk2), pyexiv2
+(python-pyexiv2), dcraw (dcraw), netpbm (netpbm). Versions in Ubuntu
+jaunty should also work.
+
+The program currently only accepts Canon RAW files (*.CR2). I have made
+a small selection of samples available at 
+<http://files.liw.fi/dimbola-test-images.tar>.
+
+However, please don't use this version for anything real. It really is
+just a proof-of-concept, and I don't want to have to support it in the
+long term.
+
+A good version would probably take 6-8 weeks of full-time work.
+
+I am now wondering whether to make this into a real project so other
+people might find it useful too. If I do, I
+would welcome some help. Even a small amount of help would make things
+go much faster. Especially the following areas would benefit from help:
+
+* database design, especially for performance when there's hundreds of
+  thousands of images in the database; this would be good to get as
+  right as possible from the beginning, to reduce need to convert
+  databases
+* user interface design; also, implementation of the design in Glade
+* graphic design: icons, gallery themes
+* graphics programming: RAW development, basic image manipulation, color
+  management
+* user support: web site or wiki, documentation, etc
+* project hosting management, perhaps getting a dedicated domain
+* profiling, stress testing, optimization
+* release management; bug management
+* packaging, collaboration with distributions, porting to other Unixes
+  than the one I happen to be using when developing (perhaps even Mac
+  and Windows?)
+* testing by and feedback from real users, particularly serious photographers
+* general development: writing code, reviewing changes
+
+Anyone want to help me with anything? If so, please e-mail me at
+liw@liw.fi.
+
+I don't actually expect to compete with F-spot, digiKam, and other
+existing applications, never mind Adobe Lightroom and Apple Aperture,
+except in small niches. Would you like to
+expand it to include your niche? If so, help me help you and let's make
+it a tool for both of us.

=== added file 'tag/dimbola.mdwn'
--- tag/dimbola.mdwn    1970-01-01 00:00:00 +0000
+++ tag/dimbola.mdwn    2009-09-08 18:44:36 +0000
@@ -0,0 +1,4 @@
+This tag is for blog posts about [Dimbola](https://launchpad.net/dimbola), 
+the photo organizer.
+
+[[inline archive=yes pages="link(tag/dimbola)"]]

=== added file 'posts/listat-eivat-ole-demokratiaa.mdwn'
--- posts/listat-eivat-ole-demokratiaa.mdwn     1970-01-01 00:00:00 +0000
+++ posts/listat-eivat-ole-demokratiaa.mdwn     2009-09-03 05:03:56 +0000
@@ -0,0 +1,38 @@
+[[!meta title="Listat eivät ole demokratiaa"]]
+[[!tag in-finnish finnish-politics]]
+
+Kansanedustaja Pauliina Viitamies [kirjoittaa pitkistä listoista](http://pauliinaviitamies.blogspot.com/2009/08/pitkat-listat.html)
+blogissaan:
+
+> Puolueväki varmuudella tietää sen, kuinka pitkäaikaiset puolueen järjestötyössä 
+> ansioituneet ovat niitä, joiden soisi myös vaaleissa tulla valituiksi.
+
+Tämä on erinomainen esimerkki siitä kuinka kansanedustajat ja muut
+johtavat poliitikot ovat
+sokeutuneet. Eihän sillä ole mitään väliä miten ehdokas on
+ansioitunut puolueen järjestötyössä. Puoluetyö ei ole se mittari,
+jolla ehdokkaan hyvyyttä vaaleissa mitataan. Päinvastoin, väitän
+jopa, että pitkä sitoutuminen puolueeseen on haitaksi ja vaarantaa
+[perustuslain](http://www.finlex.fi/fi/laki/ajantasa/1999/19990731)
+29 pykälän noudattamisen:
+
+> Kansanedustaja on velvollinen toimessaan noudattamaan oikeutta ja totuutta. 
+> Hän on siinä velvollinen noudattamaan perustuslakia, eivätkä häntä sido muut 
+> määräykset.
+
+Pitkät listat eivät ole demokratiaa. Puolueväki ei ole se, jolla pitää
+olla valta päättää missä järjestyksessä ihmisiä valitaan. Se valta on 
+yksinomaan kansan.
+
+Nykyisetkään listat vaaleissa eivät ole demokraattisia, mutta ainakin
+valintajärjestys on äänestäjien päätettävissä.
+
+Tärkeä syy alhaiseen äänestysaktiivisuuteen on kansalaisten tunne siitä,
+ettei sillä ole mitään väliä. Tätä ei korjata sillä, että poistetaan
+vähäinenkin vaikutusvalta.
+
+Oikea tapa korjata äänestysjärjestelmämme on ottaa käyttöön
+[Condorcet-pohjainen 
+järjestelmä](http://en.wikipedia.org/wiki/Condorcet_method), jollaista
+vaikkapa [Debian-projekti](http://www.debian.org/) on vuosia käyttänyt
+menestyksellisesti.

=== added file 'posts/bug-exchange-format/comment_8._comment'
--- posts/bug-exchange-format/comment_8._comment        1970-01-01 00:00:00 +0000
+++ posts/bug-exchange-format/comment_8._comment        2009-08-31 11:24:52 +0000
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://liw.fi/"
+ date="2009-08-31T11:24:51Z"
+ content="""
+I don't think the protocol for transferring things is as important as the format at this stage. Consider the e-mail format (RFC822): it worked for SMTP as well as UUCP.
+
+I also don't think a completely new format is warranted: re-inventing the \"e-mails in Maildir\" format in something based on XML may result in something powerful, but I'm afraid it will first result in taking a really long time.
+
+It's fairly important to encode all the information in e-mail headers: it can be important to know, for example, who was Cc'd on the original e-mail. Adding all the details to a new format is going to take quite a while.
+
+However, I'm a really strong believer that whoever does the work, should make the decision. Since that's not going to be me, thus I'm only suggesting things here.
+"""]]

=== added file 'posts/bug-exchange-format/comment_7._comment'
--- posts/bug-exchange-format/comment_7._comment        1970-01-01 00:00:00 +0000
+++ posts/bug-exchange-format/comment_7._comment        2009-08-27 13:31:43 +0000
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://www-public.it-sudparis.eu/~berger_o/"
+ subject="We're working on that same thing with RDF and ontologies"
+ date="2009-08-27T13:31:42Z"
+ content="""
+We're working on designing a standard bug representation format using RDF and ontologies, in much the same way as you've been describing (for metadata).
+
+More details at https://picoforge.int-evry.fr/cgi-bin/twiki/view/Helios_wp3/Web/HeliosBtOntology
+
+Looking forward to be able to discuss that with you
+"""]]

=== added file 'posts/bug-exchange-format/comment_6._comment'
--- posts/bug-exchange-format/comment_6._comment        1970-01-01 00:00:00 +0000
+++ posts/bug-exchange-format/comment_6._comment        2009-08-27 09:07:40 +0000
@@ -0,0 +1,54 @@
+[[!comment format=mdwn
+ username="https://drak.ucw.cz/~bulb//"
+ subject="Launchpad format or feed format?"
+ date="2009-08-27T09:07:39Z"
+ content="""
+The launchpad format is quite similar to what I proposed in previous comment, except:
+
+1. I would propose to reuse existing definitions. Briefly looking at RSS2.0 and Atom descriptions, it would even seem to be possible to base a bug exchange format completely on either of them with Atom being a bit easier.
+2. The launchpad format is missing unique ids on the comments, which are necessary for synchronization as opposed to one-time import.
+
+The idea of basing on Atom would be roughly like:
+
+1. A bug is a feed. Atom specifies subject (title), url (link), unique id (id) and timestamp of last update (updated).
+2. Author would be the original reporter, other attributes would be simply added by adding whatever elements we need, using a different XML namespace and namespace prefix.
+3. Each comment and attachment would simply be entry. Atom specifies the basic fields (subject - title, author, id, timestamp - published) and content type can be specified. Any other needed fields could be added using namespaced extension elements.
+
+Added benefits would be:
+
+1. Accessible (sans the extended bits) with standard feed readers and especially aggregators. This could simplify implementing things like recent activity of bugs for given application.
+2. The Atom Publishing Protocol could be used for pushing the changes if desired.
+
+The original example could look like:
+
+<pre>
+  &lt;feed xmlns=\"http://www.w3.org/2005/Atom\" xmlns:bug=\"http://liw.fi/bug-exchange\"&gt;
+    &lt;title&gt;hellopy does not speak English&lt;/title&gt;
+    &lt;updated&gt;2009-07-26T15:15Z&lt;/updated&gt;
+    &lt;bug:affects&gt;hellopy&lt;/bug:affects&gt;
+    &lt;bug:severity project=\"http://liw.fi/hellopy\"&gt;minor&lt;/bug:severity&gt;
+    &lt;bug:severity project=\"http://packages.debian.org/hellopy\"&gt;serious&lt;/bug:severity&gt;
+    &lt;bug:status&gt;open&lt;/bug:status&gt;
+    &lt;bug:assigned-to&gt;
+      &lt;email&gt;liw@liw.fi&lt;/email&gt;
+    &lt;/bug:assigned-to&gt;
+    &lt;x:bounty-offered-by xmlns:x=\"http://example.com/bug-bounty\"&gt;
+      &lt;email&gt;verybigboss@example.com&lt;/email&gt;
+    &lt;/x:bounty-offered-by&gt;
+    &lt;entry&gt;
+      &lt;title&gt;hellopy does not speak English&lt;/title&gt;
+      &lt;published&gt;2009-07-26T15:15Z&lt;/published&gt;
+      &lt;author&gt;
+        &lt;name&gt;U. Ser&lt;/name&gt;
+        &lt;email&gt;u.ser@example.com&lt;/email&gt;
+      &lt;/author&gt;
+      &lt;content type=\"text\"&gt;
+        hellopy says 'Huplo' where 'Hello' would be expected. I don't know
+        what language that is supposed to be, but defintiely does not sound
+        like English.
+      &lt;/content&gt;
+    &lt;/entry&gt;
+  &lt;/feed&gt;
+</pre>
+
+"""]]

=== added file 'posts/bug-exchange-format/comment_5._comment'
--- posts/bug-exchange-format/comment_5._comment        1970-01-01 00:00:00 +0000
+++ posts/bug-exchange-format/comment_5._comment        2009-08-27 08:07:42 +0000
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="https://drak.ucw.cz/~bulb//"
+ subject="Ad maildir"
+ date="2009-08-27T08:07:42Z"
+ content="""
+I think the protocol used for synchronization of the bugtrackers should be specified. A problem with maildir is that there is no obvious mapping from it to a network transfer.
+
+I see several options here:
+
+1. Provide the metadata at the specified (http) URL. Add a list of messages to it (<code>&lt;message id=... url=... date=... /&gt;</code>). The pulling bugtracker will read the metadata and than read each message it does not have yet from the URL provided. Advantage is the message is not re-downloaded on further synchronizations, disadvantage is that it's many requests.
+1. Use RSS, Atom or other feed format for the messages instead of RFC822 and merge everything into one big XML. Advantage is that it'd be easy to download whole bug, disadvantage would be that everything is re-downloaded during each synchronization. The server could allow a query for changes in bug since some date to deal with the re-download problem.
+1. The same as above, but embed RFC822 messages into the XML. It requires the implementations to have two parsers while the previous options allows them to go with one (XML).
+1. Use POP or IMAP for downloading the bugs. That seems more complicated though, since all or almost all bugtrackers will already have http interface, while most of them won't have a POP or IMAP one.
+
+I would consider the  second option actually easiest to implement. The exporting tracker will already have the bug data parsed in some structure, so serializing to XML should be easy and many of them already have RSS feed too. And the downloading one would just issue one request and deal with the result. It would also make it easy to download the file manually and upload it to the other tracker later.
+
+Query parameter <code>since=</code>*timestamp* could be specified for the main URL. This would cause the messages received before that timestamp to be omited, but tracker that does not implement it would still be conforming, since it would only send unnecessary data, but nothing would fail.
+"""]]

=== added file 'posts/lapinakyva-yhteiskunta.mdwn'
--- posts/lapinakyva-yhteiskunta.mdwn   1970-01-01 00:00:00 +0000
+++ posts/lapinakyva-yhteiskunta.mdwn   2009-08-25 10:16:30 +0000
@@ -0,0 +1,60 @@
+[[!meta title="Läpinäkyvä yhteiskunta"]] 
+[[!tag in-finnish finnish-politics idea]]
+
+Suomi on perinteisesti ollut jäyhän byrokratian ja sokean
+auktoriteettiuskon maa. Auktoriteetteja ovat olleet niin viranomaiset
+kuin vaikkapa menestyneet liikemiehet. Tieto on kulkenut suusta suuhun
+huhuina tai sitten virallisemmin vähälukuisen lehdistön 
+kautta. Lehdistöön on
+ollut luottaminen ja mikäs siinä luottaessa, onhan lottovoitto syntyä
+Suomeen.
+
+Kaikki ei lottovoittajamaassakaan kuitenkaan ole kestänyt
+päivänvaloa. Poliitikot kähmivät itselleen tai kotiseudulleen rahaa
+tai etuja valtion budjetista. Yritykset pitävät hintoja korkealla
+kartelleilla ja voitelevat poliitikoita vaalirahoilla, Lapin-matkoilla
+ja muilla keinoilla.
+
+Selvän korruption lisäksi asioiden hoito ja päätöksenteko on ollut
+tehotonta. Lainvalmistelussa esimerkiksi ei välttämättä kuunnella
+kaikkia osapuolia. Tai jos kuunnellaan, epämieluisa mielipiteet
+jätetään huomiotta.
+
+Kaikki tämä on ollut mahdollista sen takia, että yhteiskunnassa on
+vain vähän läpinäkyvyyttä. Kun valvojaksi määrätty viranomainen
+ei ehdi kaikkea tutkia, eikä kukaan muu pysty valvomaan ollenkaan,
+kaikki menevät aina siitä, mistä aita on matalin.
+
+Yhteiskunnan voisi nykypäivänä kuitenkin tehdä paljon
+läpinäkyvämmäksi. Esimerkiksi valtion ja kunnan päätöksenteon ja
+sen valmistelun voisi julkaista suoraan, lähes reaaliaikaisesti,
+Internetissä. Sitä varten ei edes tarvitse rakentaa mitään hienoja
+interaktiojärjestelmiä, vaan riittäisi, että dokumentit, jotka joka
+tapauksessa tuotetaan, laitetaan yhteen paikkaan kaikkien katsottaviksi.
+Pieni määrä systemaattisuutta tiedostomuotoihin ja muihin
+käytäntöihin olisi tarpeeksi, jotta näistä dokumenteista voisi
+tehdä hakuja, yhteenvetoja ja muuta automaattista prosessointia.
+
+Esimerkiksi niistä saisi melko helposti aikaan RSS-syötteitä
+lautakuntien, työryhmien, kunnanhallitusten, jne., kokouksista: ennen
+kokousta esityslistat (liitteet linkkien päässä), jälkikäteen
+pöytäkirja.
+
+Eikä syötteiden tarvitsisi olla byrokratian organisaation mukaan
+jäsenneltyjä. Olisi täysin mahdollista rakentaa esimerkiksi
+RSS-syöte kaikista dokumenteista, jotka koskevat Vuotoksen allasta, tai
+ydinvoiman lisärakentamista, tai mitä hakusanoja kukin haluaakin
+käyttää.
+
+Tämän rakentaminen ei vaatisi kovin suurta panosta valtiolta ja
+kunnilta. RSS-syötteiden tekemisen voisi jättää ulkopuolisten
+varaan: koska kaikilla olisi sama pääsy dokumentteihin, eri tahot
+voisivat kilpailla parhaasta ratkaisusta ja rahoittaa toimintansa joko
+käyttömaksuin tai mainoksilla. (Aivan erityisesti ei siis olisi
+tarpeen tilata suurta, kallista ja pitkää projektia Tieto Oyj:ltä.)
+
+Mitä tästä seuraisi? Ainakin se, että hallinnon olisi vähän
+vaikeampi kusettaa kansalaisia. Hallinnon läpinäkyvyys olisi aivan
+ennennäkemätöntä tässä maailmassa. Tämä, jos mikä, edistäisi
+e-Governmentiä. Voisipa se jopa tuoda Suomeen vähän oikeaa
+demokratiaa.

=== added file 'posts/outi-makela-vihaa-minua.mdwn'
--- posts/outi-makela-vihaa-minua.mdwn  1970-01-01 00:00:00 +0000
+++ posts/outi-makela-vihaa-minua.mdwn  2009-08-23 06:40:56 +0000
@@ -0,0 +1,46 @@
+[[!meta title="Outi Mäkelä vihaa minua"]]
+[[!tag rant in-finnish finnish-politics]]
+
+Seuraan monen kansanedustajan blogi 
+[edustajamme.fi-palvelun](http://blogit.edustajamme.fi/) kautta. Sinne on
+erittäin
+kätevästi kerätty monen kansanedustajan blogit yhteen paikkaan.
+Tarkemmin sanoen siellä on blogien RSS-syötteet.
+
+Kansanedustaja Outi Mäkelä on mukana. Hän kuuluu siihen luokkaan
+bloginpitäjiä joiden mielestä on tärkeämpää houkutella lukijat hänen
+omille sivuilleen kuin antaa heidän lukea tekstit kätevästi RSS-lukijan
+kautta.
+
+Tämä tarkoittaa sitä, että RSS-syötteessä hän julkaisee vain pienen alkupätkän
+kustakin blogikirjoituksestaan. Loput pitää käydä lukemassa selaimen
+kautta: RSS-syötteessä on linkki koko kirjoitukseen.
+
+Tämä tekee lukemiseen yhden ylimääräisen askeleen lisää. Mutta itsekkään
+bloginpitäjän kannalta oleelisempaa on saada käyntejä sivustolleen, jotta
+voi leuhkia suosiollaan. Ja antaahan se myös mahdollisuuden kerätä tietoja
+lukijoistaan.
+
+Outi Mäkelä menee askeleen pidemmälle. Hänen www-sivunsa vaativat Adoben
+Flash-ohjelman käyttämistä. Mikäli sitä ei ole selaimeen asennettu,
+sivut käskevät asentamaan sen. Muussa tapauksessa ainoa asia, mitä
+sivuilta näkyy, on [tämä](http://outimakela.com/flash.html):
+
+> Arvoisa vierailija,
+> 
+> Outin uudistetun sivuston käyttö vaatii selaimeltasi Flash-laajennuksen 
+> (vähintään versiota 8), jonka viimeisin versio on asennettavissa Adoben 
+> sivustolta, johon tämä sivu ohjaa selaimesi automaattisesti 15 sekunnin 
+> sisällä.
+> 
+> Kiitos vierailustasi ja tervetuloa (päivitetyn laajennuksen) kanssa uudelleen.
+
+Minä käytän Linuxia ja vieläpä 64-bittisessä muodossa, koska käyttää
+kaikkea muistia koneessa ilman ongelmia. Adoben Flash-kikkare toimii
+tässä ympäristössä huonosti ja aiheuttaa selaimen kaatumista kymmeniä
+kertoja päivässä. En siis voi käyttää sitä.
+
+Outi Mäkelä ei halua, että luen hänen blogikirjoituksiaan. Hän on nähnyt
+paljon vaivaa, jotta en voisi lukea niitä.
+
+Outi, miksi vihaat minua?

=== added file 'posts/pp-onneksi-olkoon.mdwn'
--- posts/pp-onneksi-olkoon.mdwn        1970-01-01 00:00:00 +0000
+++ posts/pp-onneksi-olkoon.mdwn        2009-08-19 12:16:16 +0000
@@ -0,0 +1,8 @@
+[[!meta title="Onneksi olkoon, Piraattipuolue"]]
+[[!tag in-finnish finnish-politics]]
+
+[Piraattipuolue on hyväksytty puoluerekisteriin](http://blog.piraattipuolue.fi/2009/08/piraattipuolue-merkitty-puoluerekisteriin/).
+
+Onneksi olkoon!
+
+Hyvin suoritetun työn palkkiona on uusi, vaativampi työ. Niin nytkin.

=== modified file 'posts/pygtk-automatic-connects.mdwn'
--- posts/pygtk-automatic-connects.mdwn 2009-08-18 09:02:57 +0000
+++ posts/pygtk-automatic-connects.mdwn 2009-08-18 09:14:51 +0000
@@ -4,12 +4,9 @@
 I like the following hack:
 
     def find_and_bind_widgets(self, builder):
-        """Bind widgets and callbacks."""
-        self.widgets = {}
         for o in builder.get_objects():
-            if isinstance(o, self.gtk.Widget):
+            if isinstance(o, gtk.Widget):
                 name = o.get_property('name')
-                self.widgets[name] = o
                 for attr in dir(self):
                     prefix = 'on_%s_' % name
                     if attr.startswith(prefix):

=== added file 'posts/pygtk-automatic-connects.mdwn'
--- posts/pygtk-automatic-connects.mdwn 1970-01-01 00:00:00 +0000
+++ posts/pygtk-automatic-connects.mdwn 2009-08-18 09:02:57 +0000
@@ -0,0 +1,32 @@
+[[!meta title="Automatically connecting signals in PyGTK"]]
+[[!tag programming gnome]]
+
+I like the following hack:
+
+    def find_and_bind_widgets(self, builder):
+        """Bind widgets and callbacks."""
+        self.widgets = {}
+        for o in builder.get_objects():
+            if isinstance(o, self.gtk.Widget):
+                name = o.get_property('name')
+                self.widgets[name] = o
+                for attr in dir(self):
+                    prefix = 'on_%s_' % name
+                    if attr.startswith(prefix):
+                        signal_name = attr[len(prefix):]
+                        method = getattr(self, attr)
+                        o.connect(signal_name, method)
+
+Explanation: In a PyGTK program I am working on, the UI has been laid out
+using Glade and GtkBuilder. The above method goes through all widgets in
+the .glade file, and looks for methods following a specific naming 
+convention: `on_`*widgetname*`_`*signalname*. It then connects the
+method to the signal and widget. 
+
+For example, I have a widget
+called `window`, and a method called `on_window_delete_event`, which
+gets called when the window manager tells the app the close the window.
+
+This lets me just name widgets in Glade and the Python file, without
+having to do any extra work. I do not even need to set the name of the signal
+handler in Glade. If the method is named right, it gets connected.

=== added file 'posts/mies-on-pedofiili.mdwn'
--- posts/mies-on-pedofiili.mdwn        1970-01-01 00:00:00 +0000
+++ posts/mies-on-pedofiili.mdwn        2009-08-17 11:53:57 +0000
@@ -0,0 +1,9 @@
+[[!meta title="Olen mies, olen siis pedofiili"]]
+[[!tag rant in-finnish]]
+
+Minä olen mies. Kaikki miehet ovat pedofiilejä. Kysykää vaikka
+[Air Francelta](http://www.yle.fi/uutiset/ulkomaat/2009/08/air_france_kieltaa_miehilta_lapsien_vieressa_istumisen_933705.html). Tai 
+[British Airwaysiltä](http://www.mailonsunday.co.uk/news/article-414550/Revealed-How-BA-bans-men-sitting-children-dont-know.html).
+
+(Tasa-arvo olisi hieno asia, puolin ja toisin. 
+Pedofilihysteria voisi sen sijaan loppua jo.)

=== modified file 'posts/freedom-in-online-services.mdwn'
--- posts/freedom-in-online-services.mdwn       2009-08-17 06:27:17 +0000
+++ posts/freedom-in-online-services.mdwn       2009-08-17 06:28:57 +0000
@@ -1,3 +1,6 @@
+[[!meta title="Freedom in online services"]]
+[[!tag freedom]]
+
 Freedom in online services is about data: if I have my data in a
 service, who gets access to it, and who gets to decide if and when it
 gets deleted? Does the user have total control, or the service provider?

=== added file 'posts/freedom-in-online-services.mdwn'
--- posts/freedom-in-online-services.mdwn       1970-01-01 00:00:00 +0000
+++ posts/freedom-in-online-services.mdwn       2009-08-17 06:27:17 +0000
@@ -0,0 +1,42 @@
+Freedom in online services is about data: if I have my data in a
+service, who gets access to it, and who gets to decide if and when it
+gets deleted? Does the user have total control, or the service provider?
+
+Freedom in traditional software, what the GNU project started with, is
+also about data, but it was always implicit that the user had total
+control, since they controlled the machine and could decide what
+software to run.
+
+That is why online services are a threat to freedom. Even when they are
+running on a completely free software stack, users still do not
+necessarily have control of their data. If the user has all the [four
+essential freedoms](http://www.gnu.org/philosophy/free-sw.html) defined
+by the [Free Software Foundation](http://www.fsf.org/), it is not
+enough, since they cannot change the code actually running on the
+server.
+
+It is, obviously, impossible to allow each user to change the code
+running on the server. However, it seems to me necessary to add a fifth
+freedom, for services: the user must be able to retrieve all
+their data from the service, and to remove all their data from the
+service.
+
+This may need better phrasing, but the goal is to make it easy to stop
+using a service, and to change to using a different service. That will
+allow users benefit from any changes to the code they make. It is not
+perfect, since in many services much of the value comes from a network
+effect, where the service is better because everyone else is using it as
+well. However, that is more a question of quality than freedom.
+
+It is unclear to me whether the freedom of the service should dictate
+that people other than user who owns the data should be able to freely
+access it. The [Open Software Service
+Definition](http://opendefinition.org/ossd?action=show&redirect=osd) and
+the [Franlin Street
+Statement](http://autonomo.us/2008/07/franklin-street-statement/), both
+excellent and important documents, seem to think that is necessary, but
+I am not sure.
+
+A sixth freedom may also be necessary, one that limits what the service
+provider can do with the user's data, but that is less important to me,
+I think, at least for now.

=== added directory 'posts/balcony-crane'
=== added file 'posts/balcony-crane/comment_1._comment'
--- posts/balcony-crane/comment_1._comment      1970-01-01 00:00:00 +0000
+++ posts/balcony-crane/comment_1._comment      2009-08-13 17:26:24 +0000
@@ -0,0 +1,6 @@
+[[!comment format=mdwn
+ username="http://womble2.livejournal.com/"
+ date="2009-08-13T17:26:24Z"
+ content="""
+Many houses in Amsterdam have such cranes, though I believe they are generally used for large objects such as furniture.
+"""]]

=== added file 'posts/balcony-crane.mdwn'
--- posts/balcony-crane.mdwn    1970-01-01 00:00:00 +0000
+++ posts/balcony-crane.mdwn    2009-08-13 08:19:00 +0000
@@ -0,0 +1,11 @@
+[[!meta title="Cranes for balconies"]]
+[[!tag idea]]
+
+Many old houses have no lifts, making it hard to carry large amounts of
+groceries to your balcony. It might be practical to have a 
+[crane](http://en.wikipedia.org/wiki/Crane_(machine)) you could easily
+put up in your balcony to do the heavy lifting.
+
+I am imagining a tripod with a horizontal arm, a crank for lifting the
+load, and the operator acting as a counterweight. But I leave the design
+to whoever actually makes the thing.

=== modified file 'index.mdwn'
--- index.mdwn  2008-06-23 10:04:20 +0000
+++ index.mdwn  2009-08-11 08:45:38 +0000
@@ -2,6 +2,7 @@
       class="floatTR" link="no"]]
 
 Welcome to my web log. See the [[first_post|posts/welcome]] for an
-introduction. See the [[archive|posts]] page for all posts.
+introduction. See the [[archive|posts]] page for all posts. See
+also [identi.ca](http://identi.ca/liw).
 
 [[inline pages="posts/* and !posts/*/*"]]

=== added file 'posts/kernel-oops-compression.mdwn'
--- posts/kernel-oops-compression.mdwn  1970-01-01 00:00:00 +0000
+++ posts/kernel-oops-compression.mdwn  2009-08-11 07:22:52 +0000
@@ -0,0 +1,69 @@
+[[!meta title="Kernel oops message compression"]]
+[[!tag linux idea]]
+
+I recently attended a talk where a kernel hacker told about debugging
+techniques when the Linux kernel is having problems. One of the things
+he mentioned was that kernel oops messages can sometimes be so long
+they won't fit on a screen. When users submit them, e.g. by photographing
+the screen, they don't show enough information to be useful.
+
+It struck me that it might be possible to encode the message in various
+ways to make them use less space so they don't scroll off the screen.
+My first idea was a 2D bar graph, but those can be difficult in a text-only
+situation. A second idea is to use gzip and base64 encoding, and a
+refinement of that is to use base85 encoding.
+
+This has probably been thought of before, but I thought it'd be fun
+to prototype it anyway. I used a free
+[ascii85 library](http://sourceforge.net/projects/pyascii85/) for
+Python:
+
+    #!/usr/bin/python
+    
+    import zlib, bz2, base64, sys, tempfile, os, ascii85
+    
+    msg = sys.stdin.read()
+    print "msg:", len(msg)
+    compressed = zlib.compress(msg, 9)
+    print "compressed:", len(compressed)
+    fd, compressed_name = tempfile.mkstemp()
+    os.write(fd, compressed)
+    os.close(fd)
+    compressed_f = file(compressed_name)
+    ascii85.encode(compressed_f, sys.stdout)
+
+The output looks like this:
+
+    msg: 1634
+    compressed: 875
+    <~GhS.A>Ar7S'Z],0.1WSK(0_bV2p94FTa66f6^JQWJ.4:CK&Xc39T^5bfu^_\Tq&&u<XaD\6
+    lu::c_'C[5Mge#qt9CE#'^1ebXmM5]cY70)>\-TVY0RhHe#H5XE"-6f[R9^fc!k:qXQdpBILR
+    6-RZ.C_!]`gG]i0_,]6jbo(CuY*or^o"ci=l"*@htS%n/RF(:Jgj<5p6&:F5]&dboUE&elsfd
+    (Q>r9iZ[<<TZLdD7flXWfQDgJ!O=E[hn,#9sJ0_F*M9!*pLQ#:GL4bWjmeR!dh="[NORpL"BF
+    OgCfThPUJ>0e2C=Obgq4J@,HKB#6Wr!Z+@=_@(ucapa-?HiFl=c"6F,Qo2QK(X'kRhemB#?^r
+    pBRcu?kXCBo9UdEqEaUhnW/r!4.oagXhWh)9Y>RZ?M=[Db_+)Nb88)_KecZ61*?GU=10IDTNZ
+    @h3T<[tqqj4<[3j+[I6!?OXO0qBWQ0<YT-K+]1e.[N,Q?6$4F(pQ7kcUCJ69(R48PNhTQ6LQR
+    >;[?u=6M!-4PRrFlO$PJ_>td@h^!-H"HZk_>Z8a9\I:.%7"s6[U+.X)e]4M\-ARjM!0-D:>%0
+    eFfc3Fc1<$sYqHgbA#+hOK6k9X1*BWOX^I.!.@D^OAsXk<XOUm9]JB3hYYDPjok,F&KuVOYo5
+    jUn!'=jNq-Rp8b0dr+]li21>EeIRagC'/t^Y_UQY+,XX9/EmmP;VEaUW0^]7@VM:>=akU:$fB
+    @N%:0J2YqsmA!S\\"W@G`pph9sm23(,kcah7N#Oi3NDUm^]nM8!#ZV<8R#ljg^o/XkT9)5(r\
+    khNf<p3Dg0*6OunTq%DR]IEL_Yc1L7C%^bPTs@>Rr-QcRu_Kqr#bmu/*cGH<O?:W;@fbN1SiY
+    `R&"a>KcXOi6kW\+ee9JqMiUWW>UPW.UjWGIh/ipoFIX()/L'M$-9>>k4*gN[<-8@B2460k.l
+    p,KdJ7>F,O<%]=$A=5.lEMZ-bl[@Hmt&XFYRkrm]9bjOF2f6ZKNWKW[)b)c:,H4.6h+2CCuDa
+    T@DIM&oI6i'nj&5G9Lqf<F@4K@"0@kZh1P/>[:WP!J_E\T:#c;Y)"?g.\t#.Xt&'IYkT##I2]
+    T~>
+
+Gzip seems to compress things to about half the original size, and ascii85
+inflates that by about 25%. However, the result is then all mashed up on
+long lines, so use of vertical space if fairly small. Thus, this might
+be acceptable, perhaps as an optional feature.
+
+Decoding that using OCR from a digital photograph should be possible,
+and is left as an excercise for the reader, as is an implementation of
+the encoder that is actually suitable for the kernel. (Read: not in Python.)
+
+It might be possible to write a custom compressor: oops messages seem
+fairly regular in shape, after all.
+
+There you are. If this is useful for anyone, at any time, please do use
+the idea.

=== modified file 'posts/downloading-updates-faster.mdwn'
--- posts/downloading-updates-faster.mdwn       2009-08-06 10:30:00 +0000
+++ posts/downloading-updates-faster.mdwn       2009-08-11 06:07:28 +0000
@@ -31,6 +31,6 @@
 
 Some discussions on the ubuntu-devel mailing list:
 
-* https://lists.ubuntu.com/archives/ubuntu-devel/2009-July/028529.html
-* https://lists.ubuntu.com/archives/ubuntu-devel/2009-July/028568.html
-* https://lists.ubuntu.com/archives/ubuntu-devel/2009-July/028600.html
+* <https://lists.ubuntu.com/archives/ubuntu-devel/2009-July/028529.html>
+* <https://lists.ubuntu.com/archives/ubuntu-devel/2009-July/028568.html>
+* <https://lists.ubuntu.com/archives/ubuntu-devel/2009-July/028600.html>

=== added file 'posts/bug-exchange-format/comment_4._comment'
--- posts/bug-exchange-format/comment_4._comment        1970-01-01 00:00:00 +0000
+++ posts/bug-exchange-format/comment_4._comment        2009-08-10 07:39:35 +0000
@@ -0,0 +1,6 @@
+[[!comment format=mdwn
+ username="http://liw.fi/"
+ date="2009-08-10T07:39:34Z"
+ content="""
+LarstiQ, that's also an interesting idea. However, unless everyone uses the same system, exchanging bugs between bug trackers is still necessary. That's all I'm currently interested in; I'll look into distributed bug tracking later.
+"""]]

=== added file 'tag/travel.mdwn'
--- tag/travel.mdwn     1970-01-01 00:00:00 +0000
+++ tag/travel.mdwn     2009-08-10 04:49:54 +0000
@@ -0,0 +1,3 @@
+This tag is for blog posts about travel.
+
+[[inline archive=yes pages="link(tag/travel)"]]