diff --git a/blog/entry/unicode_ate_my_homework.mdwn b/blog/entry/unicode_ate_my_homework.mdwn
index 5c6a9b9..9868f05 100644
--- a/blog/entry/unicode_ate_my_homework.mdwn
+++ b/blog/entry/unicode_ate_my_homework.mdwn
@@ -1,5 +1,5 @@
 I've just spent several days trying to adapt git-annex to changes in ghc
-4.7's handling of unicode in filenames. And by spent, I mean, time
+7.4's handling of unicode in filenames. And by spent, I mean, time
 withdrawn from the bank, and frittered away.
 
 In kindergarten, the top of the classrom wall was encircled by the aA bB
@@ -68,7 +68,7 @@ But haskell people are smart, so they thought of this problem, and provided
 a separate type that can deal with it. `RawFilePath` hearks back to
 kindergarten; the filename is simply a series of bytes with no encoding.
 Which means it cannot be converted to a `FilePath` without encountering the
-above problems. But does let you write a safe `rm` in ghc 4.7.
+above problems. But does let you write a safe `rm` in ghc 7.4.
 
 So I set out to make something more complicated than a rm, that still needs
 to deal with arbitrary filename encodings. And I soon saw it would be
@@ -87,7 +87,7 @@ all of `System.FilePath`, and `System.Directory`, and parts of `MissingH`
 and other libraries. (And noticed that I can understand all this Haskell
 code.. yay!) And I got it close enough to working that, I'm sure,
 if I wanted to chase type errors for a week, I could get git-annex, with
-ghc 4.7, to fully work on any encoding of filenames.
+ghc 7.4, to fully work on any encoding of filenames.
 
 But, now I'm left wondering what to do, because all this work is
 regressive; it's swimming against the tide of the transition. GHC's

diff --git a/blog/entry/unicode_ate_my_homework/comment_9_7e15224e822c81f9b46aba6672309028._comment b/blog/entry/unicode_ate_my_homework/comment_9_7e15224e822c81f9b46aba6672309028._comment
new file mode 100644
index 0000000..e5cd1c6
--- /dev/null
+++ b/blog/entry/unicode_ate_my_homework/comment_9_7e15224e822c81f9b46aba6672309028._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://asjo.koldfront.dk/"
+ nickname="asjo"
+ subject="ghc version"
+ date="2012-02-06T20:38:32Z"
+ content="""
+When you write \"ghc 4.7\", you mean \"ghc 7.4\", right?
+"""]]

diff --git a/blog/entry/more_on_ghc_filename_encodings/comment_1_42f61a9ff0c1562a53508c9361fdbe98._comment b/blog/entry/more_on_ghc_filename_encodings/comment_1_42f61a9ff0c1562a53508c9361fdbe98._comment
new file mode 100644
index 0000000..7e7d79b
--- /dev/null
+++ b/blog/entry/more_on_ghc_filename_encodings/comment_1_42f61a9ff0c1562a53508c9361fdbe98._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://cjwatson.livejournal.com/"
+ ip="82.69.40.219"
+ subject="comment 1"
+ date="2012-02-04T10:25:42Z"
+ content="""
+Python 3 does much the same thing, using a 'surrogateescape' codec error handler; I think the scheme was originally described as \"UTF-8b\".  It's not ideal but seems to be the best compromise with traditional Unix it's-all-bytes semantics that anyone's found.
+"""]]

diff --git a/blog/entry/unicode_ate_my_homework/comment_8_ff686829a57f385c203e465dfe002b89._comment b/blog/entry/unicode_ate_my_homework/comment_8_ff686829a57f385c203e465dfe002b89._comment
new file mode 100644
index 0000000..08440f0
--- /dev/null
+++ b/blog/entry/unicode_ate_my_homework/comment_8_ff686829a57f385c203e465dfe002b89._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmBTMMSm9YB3q3REgQyiva-eYchUBD_g00"
+ nickname="David"
+ subject="Linus seems to think filenames are not unicode"
+ date="2012-02-03T23:03:57Z"
+ content="""
+[[http://yarchive.net/comp/linux/utf8.html]] has a nice roundup of why filenames should be treated as a byte stream rather than data in any particular encoding.
+"""]]

diff --git a/blog/entry/more_on_ghc_filename_encodings.mdwn b/blog/entry/more_on_ghc_filename_encodings.mdwn
new file mode 100644
index 0000000..44f9842
--- /dev/null
+++ b/blog/entry/more_on_ghc_filename_encodings.mdwn
@@ -0,0 +1,52 @@
+My [[last_post|unicode_ate_my_homework]] missed an important thing about
+GHC 7.4's handling of encodings for FileName. It can in fact be safe to use
+FilePath to write a command like `rm`. This is because GHC internally uses
+a special encoding for FilePath data, that is documented to allow
+"arbitrary undecodable bytes to be round-tripped through it". (It seems to
+do this by encoding the undecodable bytes as very high unicode code
+points.) So, when presented with a filename that cannot be decoded using
+utf-8 (or whatever the system encoding is), it still handles it, and using
+the resulting FilePath will in fact operate on the right file. Whew!
+
+Moral of the story is that if you're going to be using GHC 7.4 to read or
+write filenames from a pipe, or a file, you need to arrange for the Handle
+you're reading or writing to use this special encoding too.
+I use this to set up my Handles:
+
+	import System.IO
+	import GHC.IO.Encoding
+	import GHC.IO.Handle
+	
+	fileEncoding :: Handle -> IO ()
+	fileEncoding h = hSetEncoding h =<< getFileSystemEncoding
+
+Even if you're only going to write a FilePath to stdout, you
+need to do this. Otherwise, your program will crash on some filenames!
+This doesn't seem quite right to me, but I hesitate to file a bug report.
+(And this is not a new problem in GHC anyway.)
+If I did, it would have this testcase:
+
+	# touch "me¡"
+	# LANG=C ghc
+	Prelude> :m System.Directory
+	Prelude System.Directory> mapM_ putStrLn =<< getDirectoryContents "."
+	me*** Exception: <stdout>: hPutChar: invalid argument (invalid character)
+
+Since git-annex reads lots of filenames from git commands and other places,
+I had to deal with this extensively. Unfortunatly I have not found a way to
+read Text from a Handle using the fileSystemEncoding. So I'm stuck with
+slow Strings. But, it does seem to work now.
+
+----
+
+PS: I found a bug in GHC 7.4 today where one of those famous Haskell
+immutable values seems to get well, mutated. Specifically a [FilePath] 
+that is non-empty at the top of a function ends up empty at the bottom.
+Unless IO is done involving it at the top. Really.
+Hope to develop a test case soon. Happily, the code that triggered it
+did so while working around a bug in GHC that is *fixed* in 7.4.
+Language bugs.. gotta love em.
+
+[[!tag haskell]]
+
+[[!meta title="more on ghc filename encodings"]]

diff --git a/blog/entry/unicode_eye_chart/comment_1_b39a0e42447d9bff8493422ad2d1471e._comment b/blog/entry/unicode_eye_chart/comment_1_b39a0e42447d9bff8493422ad2d1471e._comment
new file mode 100644
index 0000000..a5fc816
--- /dev/null
+++ b/blog/entry/unicode_eye_chart/comment_1_b39a0e42447d9bff8493422ad2d1471e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnp5jn7cg6T50KdCg38ZjvVmXcdwH3mV1Y"
+ nickname="Matthias"
+ subject="eye chart error"
+ date="2012-02-03T19:31:40Z"
+ content="""
+There are two characters to the left of GREEK SMALL LETTER IOTA WITH DIALYTIKA AND TONOS. but you only denote one.
+"""]]

diff --git a/blog/entry/unicode_ate_my_homework/comment_7_ed2ad83b32827952da7e0a9d058e82ca._comment b/blog/entry/unicode_ate_my_homework/comment_7_ed2ad83b32827952da7e0a9d058e82ca._comment
new file mode 100644
index 0000000..6bd1f18
--- /dev/null
+++ b/blog/entry/unicode_ate_my_homework/comment_7_ed2ad83b32827952da7e0a9d058e82ca._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://david.dasz.at/"
+ nickname="David Schmitt"
+ subject="character sets in filenames"
+ date="2012-02-03T13:23:29Z"
+ content="""
+Just take a look at the problems programs like git have, when running on windows. It has to deal with - at least - three different encodings: the user's locale, the console's output encoding and ucs2 for the filesystem. The latter might, or might not be automatically converted when accessing the filesystem, depending on the API used.
+
+Filenames make only sense as raw bytestreams. Even if everything would be talking UTF-8, canonicalisation, combining characters, case(in)sensitivity and other stuff would make that so much harder as the same sequence of \"characters\" (in the broadest sense) can be represented by different bytestreams.
+
+"""]]

diff --git a/blog/entry/unicode_ate_my_homework/comment_6_0d86fffd5922046a08b0b28044d4af05._comment b/blog/entry/unicode_ate_my_homework/comment_6_0d86fffd5922046a08b0b28044d4af05._comment
new file mode 100644
index 0000000..f969249
--- /dev/null
+++ b/blog/entry/unicode_ate_my_homework/comment_6_0d86fffd5922046a08b0b28044d4af05._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://kaizer.se/"
+ nickname="ulrik.sverdrup"
+ subject="RawFileName"
+ date="2012-02-03T12:51:58Z"
+ content="""
+I think \"my program is special, all other programs can use the dumb interface\" is the wrong conclusion.
+
+Raw bytestream filenames is a fundamental property of Linux filesystems, and not something applications can form policy to get away from.  Most applications that deal with files need to get filenames correct, all of the time, not most of the time.
+"""]]

diff --git a/blog/entry/unicode_ate_my_homework/comment_5_07ef01cf163bc5b05974da9af2eb22ab._comment b/blog/entry/unicode_ate_my_homework/comment_5_07ef01cf163bc5b05974da9af2eb22ab._comment
new file mode 100644
index 0000000..9b6be9a
--- /dev/null
+++ b/blog/entry/unicode_ate_my_homework/comment_5_07ef01cf163bc5b05974da9af2eb22ab._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://jmtd.net/"
+ nickname="Jon Dowland"
+ subject="comment 5"
+ date="2012-02-03T08:01:42Z"
+ content="""
+I have a situation where I've got one file on an EXT3 filesystem with UTF-8 encoding which has invalid characters.  I try to ensure I use UTF-8 across all my filesystems but these things can still crop up. I think this file was inside a torrent and the torrent software didn't do conversion. Or perhaps I copied it onto the system via samba and that didn't.
+"""]]

diff --git a/blog/entry/unicode_ate_my_homework/comment_4_47b669b9fa54f3b34b50fbf5f4d52a4d._comment b/blog/entry/unicode_ate_my_homework/comment_4_47b669b9fa54f3b34b50fbf5f4d52a4d._comment
new file mode 100644
index 0000000..6066c22
--- /dev/null
+++ b/blog/entry/unicode_ate_my_homework/comment_4_47b669b9fa54f3b34b50fbf5f4d52a4d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmiI_INaT_TkQSBucPV_XKb20hMAACfAQU"
+ nickname="Alexander"
+ subject="Too early?"
+ date="2012-02-03T05:59:51Z"
+ content="""
+I think that the root of the problem is that non-unicode filenames are possible at all in the underlying OS API. And they exist because this is how POSIX works. Until POSIX is eliminated (e.g. by making Microsoft Windows the only existing platform), you will have to do this regressive work.
+"""]]

diff --git a/blog/entry/unicode_ate_my_homework/comment_3_b489878c55cf3724fefd66ebcf4ee921._comment b/blog/entry/unicode_ate_my_homework/comment_3_b489878c55cf3724fefd66ebcf4ee921._comment
new file mode 100644
index 0000000..80d06d2
--- /dev/null
+++ b/blog/entry/unicode_ate_my_homework/comment_3_b489878c55cf3724fefd66ebcf4ee921._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://joshtriplett.myopenid.com/"
+ nickname="Josh"
+ subject="comment 3"
+ date="2012-02-03T01:59:27Z"
+ content="""
+Huh, sure enough; looks like the wikipedia shortcut got [broken in upstream ikiwiki in October 2011](http://source.ikiwiki.branchable.com/?p=source.git;a=commitdiff;h=2c8ca894d6b773db2c7c278cfc4dd62ff54cdc43), and not fixed until [a week ago, on January 25th](http://source.ikiwiki.branchable.com/?p=source.git;a=commitdiff;h=a8ded6bf1d8ac389100ac3f3c55a075065290cb1).
+"""]]

diff --git a/code/mr.mdwn b/code/mr.mdwn
index ac3d40a..4ba4221 100644
--- a/code/mr.mdwn
+++ b/code/mr.mdwn
@@ -1,8 +1,9 @@
 The mr(1) command can checkout, update, or perform other actions on a set
 of repositories as if they were one combined respository. It supports any
-combination of subversion, git, cvs, mercurial, bzr, darcs, cvs, and fossil
-repositories, and support for other revision control systems can easily be
-added. (There are extensions adding support for unison and git-svn.)
+combination of subversion, git, cvs, mercurial, bzr, darcs, cvs, vcsh,
+fossil and veracity repositories, and support for other revision control
+systems can easily be added. (There are extensions adding support for
+unison and git-svn.)
 
 It is extremely configurable via simple shell scripting. Some examples
 of things it can do include:

diff --git a/blog/entry/unicode_ate_my_homework/comment_2_bf2d3c74893b358d8f072f9ceadf30d8._comment b/blog/entry/unicode_ate_my_homework/comment_2_bf2d3c74893b358d8f072f9ceadf30d8._comment
new file mode 100644
index 0000000..aff4382
--- /dev/null
+++ b/blog/entry/unicode_ate_my_homework/comment_2_bf2d3c74893b358d8f072f9ceadf30d8._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~rbrito"
+ nickname="rbrito"
+ subject="Wrong wikipedia link"
+ date="2012-02-03T00:52:31Z"
+ content="""
+It seems that even with my own instance of ikiwiki (latest version, tracking sid/unstable), using the `[[!wikipedia foo]]` linking also gives me links to en.wikimedia.org, instead of to wikipedia.
+
+I guess that this is what may be happening here, Josh.
+
+
+"""]]

diff --git a/blog/entry/unicode_ate_my_homework/comment_1_63ed10ec466b99b9a796fce674d2fbc1._comment b/blog/entry/unicode_ate_my_homework/comment_1_63ed10ec466b99b9a796fce674d2fbc1._comment
new file mode 100644
index 0000000..9e9e0bc
--- /dev/null
+++ b/blog/entry/unicode_ate_my_homework/comment_1_63ed10ec466b99b9a796fce674d2fbc1._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://joshtriplett.myopenid.com/"
+ nickname="Josh"
+ subject="comment 1"
+ date="2012-02-02T23:22:05Z"
+ content="""
+Your link to Wikipedia seems broken; it links to en.wikimedia.org rather than en.wikipedia.org.  You might consider using ikiwiki's shortcuts like \[[!wikipedia instead, so that can't happen.
+"""]]

diff --git a/blog/entry/unicode_ate_my_homework.mdwn b/blog/entry/unicode_ate_my_homework.mdwn
index bfc14b5..5c6a9b9 100644
--- a/blog/entry/unicode_ate_my_homework.mdwn
+++ b/blog/entry/unicode_ate_my_homework.mdwn
@@ -100,7 +100,7 @@ system encoding). That's *easy*. And maybe have a branch that uses
 `RawFilePath`, in a hackish and type-unsafe way, with no guarantees
 of correctness, for those who really need it.
 
---
+----
 
 Previously: [[unicode_eye_chart]] [[wanted_on_a_bumper_sticker]] [[abc]]
 [[boxes]] [[unpacking_boxes]]

diff --git a/blog/entry/unicode_ate_my_homework.mdwn b/blog/entry/unicode_ate_my_homework.mdwn
new file mode 100644
index 0000000..bfc14b5
--- /dev/null
+++ b/blog/entry/unicode_ate_my_homework.mdwn
@@ -0,0 +1,110 @@
+I've just spent several days trying to adapt git-annex to changes in ghc
+4.7's handling of unicode in filenames. And by spent, I mean, time
+withdrawn from the bank, and frittered away.
+
+In kindergarten, the top of the classrom wall was encircled by the aA bB
+cC of the alphabet. I'll bet they still put that up on the walls.
+And all the kids who grow up to become involved with computers learn
+that was a lie. The alphabet doesn't stop at zZ. It wouldn't all fit
+on a wall anymore.
+
+So we're in a transition period, where we've all learnt deeply the
+alphabet, but the reality is much more complicated. And the collision
+between that intuitive sense of the world and the real world makes things
+more complicated still. And so, until we get much farther along in this
+transition period, you have to be very lucky indeed to not have wasted
+time dealing with that complexity, or at least having encountered
+[[!wikipedia Mojibake]].
+
+Most of the pain centers around programming languages, and libraries,
+which are all at different stages of the transition from ascii
+and other legacy encodings to unicode.
+
+* If you're using C, you likely deal with all characters as raw bytes,
+  and rely on the backwards compatability built into UTF-8, or you
+  go to long lengths to manually deal with wide characters, so you can
+  intelligently manipulate strings. The transition has barely begin,
+  and will, apparently, never end.
+* If you're using perl (at least like I do in ikiwiki), everything
+  is (probably) unicode internally, but every time you call a library
+  or do IO you have to manually deal with conversions, that are generally
+  not even documented. You constantly find new encoding bugs.
+  (If you're lucky, you don't find outright language bugs... I have.)
+  You're at a very uncomfortable midpoint of the transition.
+* If you're using haskell, or probably lots of other languages like python
+  and ruby, everything is unicode all the time.. except for when it's not.
+* If you're using javascript, the transition is basically complete.
+
+My most recent pain is because the haskell GHC compiler is moving along
+in the transition, getting closer to the end. Or at least finishing
+the second 80% and moving into the third 80%. (This is not a quick
+transition..)
+
+The change involves filename encodings, a situation that, at least on unix
+systems, is a vast mess of its own. Any filename, anywhere, can be in any
+encoding, and there's no way to know what's the right one, if you dislike
+guessing.
+
+Haskell folk like strongly typed stuff, so this ambiguity about what type
+of data is contained in a `FilePath` type was surely anathama. So GHC is
+changing to always use UTF-8 for operations on `FilePath`.
+(Or whatever the system encoding is set to, but let's just assume it's
+UTF-8.)
+
+Which is great and all, unless you need to write a Haskell program
+that can deal with arbitrary files. Let's say you want to delete
+a file. Just a simple `rm`. Now there are two problems:
+
+1. The input filename is assumed to be in the system encoding aka unicode.
+   What if it cannot be validly interpreted in that encoding?
+   Probably your `rm` throws an exception.
+2. Once the `FilePath` is loaded, it's been decoded to unicode characters.
+   In order to call `unlink`, these have to be re-encoded to get a
+   filename. Will that be the same bytes as the input filename and the
+   filename on disk? Possibly not, and then the `rm` will delete the wrong
+   thing, or fail.
+
+But haskell people are smart, so they thought of this problem, and provided
+a separate type that can deal with it. `RawFilePath` hearks back to
+kindergarten; the filename is simply a series of bytes with no encoding.
+Which means it cannot be converted to a `FilePath` without encountering the
+above problems. But does let you write a safe `rm` in ghc 4.7.
+
+So I set out to make something more complicated than a rm, that still needs
+to deal with arbitrary filename encodings. And I soon saw it would be
+problimatic. Because the things ghc can do with `RawFilePaths` are limited.
+It can't even split the directory from the filename. We often do need to
+manipulate filenames in such ways, even if we don't know their encoding,
+when we're doing something more complicated than `rm`.
+
+If you use a library that does anything useful with `FilePath`, it's not
+available for `RawFilePath`. If you used standard haskell stuff like
+`readFile` and `writeFile`, it's not available for `RawFilePath` either.
+Enjoy your low-level POSIX interface!
+
+So, I went lowlevel, and wrote my own `RawFilePath` versions of pretty much
+all of `System.FilePath`, and `System.Directory`, and parts of `MissingH`
+and other libraries. (And noticed that I can understand all this Haskell
+code.. yay!) And I got it close enough to working that, I'm sure,
+if I wanted to chase type errors for a week, I could get git-annex, with
+ghc 4.7, to fully work on any encoding of filenames.
+
+But, now I'm left wondering what to do, because all this work is
+regressive; it's swimming against the tide of the transition. GHC's
+change is certainly the right change to make for most programs, that are
+not like `rm`. And so most programs and libraries won't use `RawFilePath`.
+This risks leaving a program that does a fish out of water.
+
+At this point, I'm inclined to make git-annex support only unicode (or the
+system encoding). That's *easy*. And maybe have a branch that uses
+`RawFilePath`, in a hackish and type-unsafe way, with no guarantees
+of correctness, for those who really need it.
+
+--
+
+Previously: [[unicode_eye_chart]] [[wanted_on_a_bumper_sticker]] [[abc]]
+[[boxes]] [[unpacking_boxes]]
+
+[[!tag unicode haskell]]
+
+[[!meta title="unicode ate my homework"]]

diff --git a/blog/entry/howto:_use_google_voice_on_dialup/comment_2_0e57dced713e35f1b9fb79ed69b9f573._comment b/blog/entry/howto:_use_google_voice_on_dialup/comment_2_0e57dced713e35f1b9fb79ed69b9f573._comment
new file mode 100644
index 0000000..3fced2a
--- /dev/null
+++ b/blog/entry/howto:_use_google_voice_on_dialup/comment_2_0e57dced713e35f1b9fb79ed69b9f573._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawloWxqfAlRzA0zMni7vzGLFnYSTdR7Ris0"
+ nickname="Scott"
+ subject="Google Voice on Dialup"
+ date="2012-02-02T17:41:45Z"
+ content="""
+Hey Joey,  thanks for sharing your information on using Google Voice on dial up.  I am not very computer savvy so I was wondering if you could direct me to where I can get more information on setting up a shell account and creating the file that you mentioned.  Thanks again for sharing the information on using Google Voice on dialup.  
+"""]]

diff --git a/blog/entry/version_numbers/comment_6_28205f5ef46f4664864dac49e6d36441._comment b/blog/entry/version_numbers/comment_6_28205f5ef46f4664864dac49e6d36441._comment
new file mode 100644
index 0000000..517f93b
--- /dev/null
+++ b/blog/entry/version_numbers/comment_6_28205f5ef46f4664864dac49e6d36441._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmOThec7H4w8kV6oJxLizuTj2fxA20UNMw"
+ nickname="Wesley J."
+ subject="X.Y.Z"
+ date="2012-02-01T21:20:33Z"
+ content="""
+The best version scheme I've ever found is the old-fashioned X.Y.Z ... BUT with these very strict rules:
+
+  * X is incremented on any backwards-incompatible change compared to previous versions.
+  * Y is incremented any time a new feature is added, but it doesn't break backwards compatibility if you weren't already using the feature.
+  * Z is incremented any change that doesn't add a new feature or break backwards compatibility: like a bug fix.
+  * No \"alpha\", \"beta\", \"rc\", cruft allowed. Just increment the version numbers correctly.
+
+What I love about this is that it tells you things like:
+
+  * 4.4.5 is just like your currently installed 4.4.2, but fixes bugs; you'd better install it.
+  * 6.7.0 might have a nifty new feature compared to 6.6.3 that you have right now; what's more, it won't break anything.
+  * 3.0.2 is the latest version upstream, but you have 2.19.6 ... ooh, better be careful; it might be way better software, but might not work with your data.
+  * For people that don't know how version numbers work, they just pick the \"highest\" number, just like they do now.
+
+Anyway, just wanted to share what I think is a good idea. I've used this scheme for over a decade for internal projects at work and it is a dream. =)
+"""]]

diff --git a/code.mdwn b/code.mdwn
index 5111f52..357bd7d 100644
--- a/code.mdwn
+++ b/code.mdwn
@@ -18,6 +18,7 @@ The stuff that's swapped into my local cache at the moment.
 [[mpdtoys]]
 [[tasksel]]
 [[debmirror]]
+[[github-backup]]
 
 ## Less active projects
 

diff --git a/blog/entry/announcing_github-backup.mdwn b/blog/entry/announcing_github-backup.mdwn
new file mode 100644
index 0000000..6d996bd
--- /dev/null
+++ b/blog/entry/announcing_github-backup.mdwn
@@ -0,0 +1,18 @@
+Partly as a followup to [[a Github survey]], and partly because
+I had a free evening and the need to write more haskell code, any haskell
+code, I present to you,
+**[github-backup](https://github.com/joeyh/github-backup)**.
+
+github-backup is a simple tool you run in a git repository you cloned from
+Github. It backs up everything Github knows about the repository, including
+other forks, issues, comments, milestones, pull requests, and watchers.
+
+This is all stored *in* the repository, as regular files, on a "github"
+branch.
+
+Available in Cabal now, in Debian maybe if someone packages
+[haskell-github](http://hackage.haskell.org/package/github).
+
+[[!tag code/github-backup]]
+
+[[!meta title="announcing github-backup"]]

diff --git a/code/github-backup.mdwn b/code/github-backup.mdwn
new file mode 100644
index 0000000..b9ce9ed
--- /dev/null
+++ b/code/github-backup.mdwn
@@ -0,0 +1,3 @@
+backs up everything github knows about a repository, to the repository
+
+<https://github.com/joeyh/github-backup>

diff --git a/blog/entry/olduse.net_1982.mdwn b/blog/entry/olduse.net_1982.mdwn
index ef12b04..77ca176 100644
--- a/blog/entry/olduse.net_1982.mdwn
+++ b/blog/entry/olduse.net_1982.mdwn
@@ -47,7 +47,8 @@ The announcements of the Motorola M68k, the IBM PC, and the CD-ROM.
 <img src="http://www.worldipv6launch.org/wp-content/themes/ipv6/downloads/World_IPv6_launch_banner_256.png" alt="world ipv6 launch" align=right>
 Reading the TCP-IP digest, and Postel's plans for launching IPv4 soon,
 while the [world IPv6 launch](http://www.worldipv6launch.org/) is being
-planned now.
+planned now. (The nay-sayers are especially fun to read. Including the
+guy who was concerned about the address space size, in 1981!)
 
 Learning that nethack ascention tales have a history streching back 30 years,
 to rogue, and that the stories back then

diff --git a/blog/entry/olduse.net_1982.mdwn b/blog/entry/olduse.net_1982.mdwn
index 7ceb6bc..ef12b04 100644
--- a/blog/entry/olduse.net_1982.mdwn
+++ b/blog/entry/olduse.net_1982.mdwn
@@ -2,7 +2,7 @@ Hard to believe I've consumed all of 1981's Usenet posts now on
 [olduse.net](http://olduse.net/), and it's been running for 7 months
 already.
 
---
+----
 
 Last night, there was a "very long"
 [post](http://article.olduse.net/1983@Acbosgd.UUCP), describing nearly
@@ -61,7 +61,7 @@ proliferating, many first inklings of what will be major problems
 and developments in 5 or 10 years. A shift in tone is already apparent,
 by now usenet is not only about announcements, there are already some flames.
 
-<img src="http://olduse.net/img/appleshot.png" alt="oldusenet in a period terminal">
+<img src="http://olduse.net/img/appleshot.png" alt="oldusenet in a period terminal" width="640" height="375">
 
 Still 9 years to go!
 

diff --git a/blog/entry/olduse.net_1982.mdwn b/blog/entry/olduse.net_1982.mdwn
new file mode 100644
index 0000000..7ceb6bc
--- /dev/null
+++ b/blog/entry/olduse.net_1982.mdwn
@@ -0,0 +1,70 @@
+Hard to believe I've consumed all of 1981's Usenet posts now on
+[olduse.net](http://olduse.net/), and it's been running for 7 months
+already.
+
+--
+
+Last night, there was a "very long"
+[post](http://article.olduse.net/1983@Acbosgd.UUCP), describing nearly
+every node on usenet in 1982. There had been a warning about this post the
+day before, since it would take many sites half an hour to download
+at 300 baud. It was handily formatted as a shell script, which created
+per-node files.
+
+So, I ran this code nobody has run since 1982. It worked. I got files. I
+tossed them on the olduse.net wiki, and used some ikiwiki 
+code TOVA contracted me to write just a few months ago, to make
+clickable links on my usenet map.
+
+[[!img blog/pics/oldusenetmap.png alt="usenet map"
+link="http://olduse.net/blog/usenet_map_mashup/"]]
+
+The map data was contributed in another post a while back. By 1982, usenet is
+getting nearly impossible to map with 1982 technology of ascii art. I enjoyed
+throwing graphviz, git, wikis, and the web at it.
+
+So, we have a collaboration across time, me and "Mark" and a lot of
+people who described their usenet nodes and piles of technology
+that make creating a mashup easy. Awesome!
+
+---
+
+I blog about stuff I find on the [olduse.net
+blog](http://olduse.net/blog/). It's an open blog;
+[Koldfront](https://koldfront.dk/) also blogs there, and we welcome other
+bloggers.
+
+Some of the highlights for me have included:
+
+As the space shuttle program is winding down, reading the excitement about
+the first shuttle flights, and the play-by-play coverage of a launch,
+posted to `net.columbia` by a high school student borrowing his dad's
+account. (A usegroup name that's hard to read without remembering
+[its fate](http://en.wikipedia.org/wiki/Space_shuttle_columbia#Final_mission_and_destruction)).
+
+The announcements of the Motorola M68k, the IBM PC, and the CD-ROM.
+
+<img src="http://www.worldipv6launch.org/wp-content/themes/ipv6/downloads/World_IPv6_launch_banner_256.png" alt="world ipv6 launch" align=right>
+Reading the TCP-IP digest, and Postel's plans for launching IPv4 soon,
+while the [world IPv6 launch](http://www.worldipv6launch.org/) is being
+planned now.
+
+Learning that nethack ascention tales have a history streching back 30 years,
+to rogue, and that the stories back then
+[had much the same flavor as they do today](http://olduse.net/blog/rogue_and_nethack/).
+
+Various celebrity sightings. [Dennis Ritchie](http://olduse.net/blog/Dennis_Ritchie/)
+teaching C and Unix. Bill Joy talking vi. RMS talking .. nuclear politics?
+
+The general development of usenet. B-news being rolled out, groups
+proliferating, many first inklings of what will be major problems
+and developments in 5 or 10 years. A shift in tone is already apparent,
+by now usenet is not only about announcements, there are already some flames.
+
+<img src="http://olduse.net/img/appleshot.png" alt="oldusenet in a period terminal">
+
+Still 9 years to go!
+
+[[!tag oldusenet]]
+
+[[!meta title="olduse.net 1982"]]
diff --git a/blog/pics/oldusenetmap.png b/blog/pics/oldusenetmap.png
new file mode 100644
index 0000000..83e4f90
Binary files /dev/null and b/blog/pics/oldusenetmap.png differ

diff --git a/blog/entry/version_numbers/comment_5_8e03ceee4bfda1f45cfc63846f75623e._comment b/blog/entry/version_numbers/comment_5_8e03ceee4bfda1f45cfc63846f75623e._comment
new file mode 100644
index 0000000..9a13e85
--- /dev/null
+++ b/blog/entry/version_numbers/comment_5_8e03ceee4bfda1f45cfc63846f75623e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 5"
+ date="2012-01-17T20:23:49Z"
+ content="""
+I might add the dots at some point. (It can only be done sanely when there's a new major version though.)
+
+If you're manually memorizing, or comparing debhelper version numbers, you're probably doing something wrong.
+"""]]

diff --git a/blog/entry/version_numbers/comment_4_bdee4bf79c15fe74ac12740252f8cf71._comment b/blog/entry/version_numbers/comment_4_bdee4bf79c15fe74ac12740252f8cf71._comment
new file mode 100644
index 0000000..1fb490d
--- /dev/null
+++ b/blog/entry/version_numbers/comment_4_bdee4bf79c15fe74ac12740252f8cf71._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnIQLuUmSOYeCKNY__SREnKq0h1E--4cvA"
+ nickname="Christopher"
+ subject="Version numbers are somewhat arbitrary"
+ date="2012-01-17T03:19:57Z"
+ content="""
+\"Normal\" non-date version numbers suck, because they don't mean anything except to the developer that came up with them.  To everyone else they're an arbitrary number to compare to the other arbitrary version numbers of the same program (or package).
+
+A date is at least something everyone can understand.  It tells you the release date, but doesn't tell you anything about the maturity of the code.
+The irony is that this is fine, because version numbers without a date also tell you nothing about the maturity of the code.
+The only downside to version numbers with a date is that the version numbers are long, making them slightly harder to read.
+These kinds of date numbers seem like they should be easier for a computer to parse, though.
+
+I found a pretty good web link discussing the issue here:
+
+   http://www.codinghorror.com/blog/2007/02/whats-in-a-version-number-anyway.html
+
+-- ChrisK
+"""]]

diff --git a/blog/entry/version_numbers/comment_3_bceee43be220364230126c17c3a09d68._comment b/blog/entry/version_numbers/comment_3_bceee43be220364230126c17c3a09d68._comment
new file mode 100644
index 0000000..e08819f
--- /dev/null
+++ b/blog/entry/version_numbers/comment_3_bceee43be220364230126c17c3a09d68._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="http://noone.org/abe/"
+ nickname="XTaran"
+ subject="Can anyone remember these long numbers?"
+ date="2012-01-16T23:28:22Z"
+ content="""
+I must admit, I was quite disappointed and frustrated when I saw that debhelper also got infected by this very annoying and only hard to memorize version numbers.
+
+With these version number scheme you can't see on a first glance if a version is the same, a higher or lower version than the one you use. Try to compare 3.20110111 with 3.20101111 or 3.20111011 without starting to count 1s, just by looking at it. This is how ikiwiki and git-annex version numbers look to me since months now: They all look the same. I can't remember anymore which version I use on which box. It's just plain annoying.
+
+I'm sure this argument isn't \"badly enough\" for Joey to stop this adversity, so I have suggestion for damage mitigation: Using delimiters between YYYY, MM and DD would already help a lot to guide the eye where it has to look for each relevant token, i.e. it be easier to distinguish between 3+2011.01.11, 3+2010.11.11 and 3+2011.10.11. (I though would prefer dashes inside the date as delimiter but that doesn't work for native Debian packages as Joey uses for the mentioned software, so I used pluses for the main delimiter instead.)
+
+Nevertheless I still prefer non-date based versioning schemes over date based version numbers.
+
+I just used date based stuff just for packaging snapshots which have not been knowingly tagged as some release. But since I just recently have been pointed to git's describe feature, I'll likely use that for snapshots in the future, especially automatically generated snapshots. While hex git ids are not useful when continuously ascending numbers are needed, version tags in git repositories often are continuously ascending, so git describe counts the number of commits since the last tag and generates a version number out of the last tag, the number of commits and the beginning of the commit id, e.g. 0.9.4-92-gedb329a if the last tag was 0.9.4, there were 92 commits since then and the last commit is ebd329a (the g stands for git).
+"""]]

diff --git a/blog/entry/version_numbers/comment_2_e94f16a216336bbe27c2fdb1d95e7bb0._comment b/blog/entry/version_numbers/comment_2_e94f16a216336bbe27c2fdb1d95e7bb0._comment
new file mode 100644
index 0000000..5ac2065
--- /dev/null
+++ b/blog/entry/version_numbers/comment_2_e94f16a216336bbe27c2fdb1d95e7bb0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 2"
+ date="2012-01-16T14:52:57Z"
+ content="""
+For stable I just tack on a number, so something like 3.20100815.7.
+"""]]

diff --git a/blog/entry/version_numbers/comment_1_4d5f6b2577ebf8e0f37233364522d1cb._comment b/blog/entry/version_numbers/comment_1_4d5f6b2577ebf8e0f37233364522d1cb._comment
new file mode 100644
index 0000000..2dbe997
--- /dev/null
+++ b/blog/entry/version_numbers/comment_1_4d5f6b2577ebf8e0f37233364522d1cb._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://gyrosgeier.myopenid.com/"
+ nickname="Simon.Richter"
+ subject="Stable branches?"
+ date="2012-01-16T09:09:21Z"
+ content="""
+The first number would identify the branch?
+"""]]

diff --git a/blog/entry/version_numbers.mdwn b/blog/entry/version_numbers.mdwn
index 4518866..77a1c9f 100644
--- a/blog/entry/version_numbers.mdwn
+++ b/blog/entry/version_numbers.mdwn
@@ -7,7 +7,9 @@ time, unless I find something badly wrong with it. It reflects how I think
 about versions for my software; there's a kind of continual "now" that
 development progresses through, in which individual releases have little
 discrete meaning and at the same time, there can also be significant
-discontinuities of one kind or another.
+discontinuities, that require the user to do something to deal with
+(such as a new debhelper compat version, or a new git-annex repository
+format).
 
 Those two things are really all that I need a version number for my
 software to communicate. I can do without the rest of the things that

diff --git a/blog/entry/version_numbers.mdwn b/blog/entry/version_numbers.mdwn
new file mode 100644
index 0000000..4518866
--- /dev/null
+++ b/blog/entry/version_numbers.mdwn
@@ -0,0 +1,38 @@
+Today I released two entirely different pieces of software with the
+identical version number 3.20120115. Debian developers also will be soon
+noticing a piece of software I released with the version number 9.20120115.
+
+I expect to move more of my software to this version number scheme over
+time, unless I find something badly wrong with it. It reflects how I think
+about versions for my software; there's a kind of continual "now" that
+development progresses through, in which individual releases have little
+discrete meaning and at the same time, there can also be significant
+discontinuities of one kind or another.
+
+Those two things are really all that I need a version number for my
+software to communicate. I can do without the rest of the things that
+version numbers are used for:
+
+* The marketing of version 1.0 and 2.0.
+* The comparative nuances such as whether 1.0 to 1.1 is a relatively
+  big change, and 1.0 to 1.0.1 is a relatively small change
+* The implication that 0.99 is *almost* 1.0 ready, and 1.1a is some kind
+  of alpha release.
+
+There is so much software, with so many version numbers that any signal
+encoded in such version numbers is swamped in the noise. Even on projects
+that I develop a version number like 2.88 is meaningless to *me*. All
+I care about is, how long ago was that version? Has there been a major
+change breaking compatibility since that version? "2.88" doesn't answer
+these questions well; "3.20111111" does.
+
+It is a little wordy to have the full year in there, and it can be annoying
+to remember to set the version to the right date on release day (TODO:
+automate). This is balanced with the version not being so wordy as to
+include the time of day, which means I might have to do a 3.20120115.1 if I
+goof up. These minor problems are worth it to instantly know how old a
+version is when a user pastes it into a bug report.
+
+And that is probably all I will ever have to say about version numbers. :)
+
+[[!meta title="version numbers"]]

diff --git a/code/debhelper/news/version_8.9.10.mdwn b/code/debhelper/news/version_8.9.10.mdwn
deleted file mode 100644
index b1e85ca..0000000
--- a/code/debhelper/news/version_8.9.10.mdwn
+++ /dev/null
@@ -1,9 +0,0 @@
-debhelper 8.9.10 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * dh\_strip: In v9, pass --compress-debug-sections to objcopy.
-     Needs a new enough binutils and gdb; debhelper backport
-     may need to disable this.
-     Thanks, Aurelien Jarno and Bastien ROUCARIES. Closes: #[631985](http://bugs.debian.org/631985)
-   * dh: Ensure -a and -i are passed when running override\_dh\_command-arch
-     and override\_dh\_command-indep targets. This is needed when the binary
-     target is run, rather than binary-arch/binary-indep. Closes: #[648901](http://bugs.debian.org/648901)"""]]
\ No newline at end of file
diff --git a/code/debhelper/news/version_9.20120115.mdwn b/code/debhelper/news/version_9.20120115.mdwn
new file mode 100644
index 0000000..9ca0a5d
--- /dev/null
+++ b/code/debhelper/news/version_9.20120115.mdwn
@@ -0,0 +1,9 @@
+debhelper 9.20120115 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * Finalized v9 mode, which is the new recommended default.
+     (But continuing to use v8 is also fine.)
+   * It is now deprecated for a package to not specify a compatibility
+     level in debian/compat. Debhelper now warns if this is not done,
+     and packages without a debian/compat will eventually FTBFS.
+   * dh: --without foo,bar now supported.
+   * Updated German man page translation. Closes: #[653360](http://bugs.debian.org/653360)"""]]
\ No newline at end of file

diff --git a/code/etckeeper/news/version_0.56.mdwn b/code/etckeeper/news/version_0.56.mdwn
deleted file mode 100644
index 22690d9..0000000
--- a/code/etckeeper/news/version_0.56.mdwn
+++ /dev/null
@@ -1,4 +0,0 @@
-etckeeper 0.56 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * Converted to use dh\_python2. Closes: #[616800](http://bugs.debian.org/616800)
-   * Handle files with % in their names."""]]
\ No newline at end of file
diff --git a/code/etckeeper/news/version_0.61.mdwn b/code/etckeeper/news/version_0.61.mdwn
new file mode 100644
index 0000000..b93d02a
--- /dev/null
+++ b/code/etckeeper/news/version_0.61.mdwn
@@ -0,0 +1,5 @@
+etckeeper 0.61 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * Fix up botched git-rm conffile removal from 0.58.
+     The file could be in any of three states; absent, present, or .dpkg-dist.
+     Finish fully removing it. Closes: #[655836](http://bugs.debian.org/655836)"""]]
\ No newline at end of file

diff --git a/code/etckeeper/news/version_0.55.mdwn b/code/etckeeper/news/version_0.55.mdwn
deleted file mode 100644
index 8f13a1e..0000000
--- a/code/etckeeper/news/version_0.55.mdwn
+++ /dev/null
@@ -1,11 +0,0 @@
-etckeeper 0.55 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * Fix error propigation to yum, which makes AVOID\_COMMIT\_BEFORE\_INSTALL work.
-     Closes: https://bugzilla.redhat.com/show\_bug.cgi?id=709487
-     Thanks, Thomas Moschny
-   * Avoid being noisy in post-install after automatic yum updates.
-     (Tuomo Soini)
-   * Ignore FHS violating prelink.cache and openvpn-status.log.
-   * Ignore *.LOCK files, as used by selinux policies.
-   * Add AVOID\_SPECIAL\_FILE\_WARNING to config file, and set it in cron
-     job to avoid daily noise. (gulikoza)"""]]
\ No newline at end of file
diff --git a/code/etckeeper/news/version_0.60.mdwn b/code/etckeeper/news/version_0.60.mdwn
new file mode 100644
index 0000000..36dacd7
--- /dev/null
+++ b/code/etckeeper/news/version_0.60.mdwn
@@ -0,0 +1,7 @@
+etckeeper 0.60 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * Updated Dutch translation of debconf templates. Closes: #[654244](http://bugs.debian.org/654244)
+   * Support -h and --help. Closes: #[654188](http://bugs.debian.org/654188)
+   * Fix typo in bugfix for #651168.
+   * Improve yum hook to avoid running if etckeeper was just removed.
+     Thanks, Mykola Marzhan"""]]
\ No newline at end of file

diff --git a/blog/entry/solar_year/comment_4_ba1b875633d5a86971801e562d84272f._comment b/blog/entry/solar_year/comment_4_ba1b875633d5a86971801e562d84272f._comment
new file mode 100644
index 0000000..4b7b5c8
--- /dev/null
+++ b/blog/entry/solar_year/comment_4_ba1b875633d5a86971801e562d84272f._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawniazbeWTaCCZ0nwMlcDM-S-tyBgFqLKRk"
+ nickname="Dustin"
+ subject="Tracking software?"
+ date="2012-01-04T03:54:52Z"
+ content="""
+Hi Joey,
+
+Thanks for this, quite interesting really.  What software are you using to talk to your inverter?  I maintain a GPL package in Ubuntu called Aurora (authored by Curt Blank), and publish my data to pvoutput.org (where there seems to be quite a number of open source developers who publish their PV data).
+
+Thanks!
+:-Dustin
+"""]]

diff --git a/code/alien/discussion.mdwn b/code/alien/discussion.mdwn
index 4f425ae..b4ab800 100644
--- a/code/alien/discussion.mdwn
+++ b/code/alien/discussion.mdwn
@@ -1,6 +1,6 @@
 I find alien to be a very useful tool for converting and creating packages, however I have run into one problem: architecture-dependent files in TGZ archives. Because all TGZ files are treated as "noarch" the rpmbuild command will fail. I can two-step around this problem (assuming the objects in the package were compiled for the same architecture as I am running on) with:
-alien -r -g package.tgz
-cd package
+alien -r -g package.tgz;
+cd package;
 rpmbuild -bb package.spec --build-root=`pwd`
 
 but ideally I would be able to do this all with alien. It would be nice to have a command-line parameter to change the target architecture used for rpmbuild.

diff --git a/code/alien/discussion.mdwn b/code/alien/discussion.mdwn
index d9b09eb..4f425ae 100644
--- a/code/alien/discussion.mdwn
+++ b/code/alien/discussion.mdwn
@@ -1,3 +1,13 @@
+I find alien to be a very useful tool for converting and creating packages, however I have run into one problem: architecture-dependent files in TGZ archives. Because all TGZ files are treated as "noarch" the rpmbuild command will fail. I can two-step around this problem (assuming the objects in the package were compiled for the same architecture as I am running on) with:
+alien -r -g package.tgz
+cd package
+rpmbuild -bb package.spec --build-root=`pwd`
+
+but ideally I would be able to do this all with alien. It would be nice to have a command-line parameter to change the target architecture used for rpmbuild.
+--Dan
+
+----
+
 If you are the original designer of alien, do you think, because of its
 experimental situation at the moment, alien will once - though perhaps very
 difficult - have a possibility - and possible with other programs - to

diff --git a/code/moreutils.mdwn b/code/moreutils.mdwn
index 19b9d8e..9412705 100644
--- a/code/moreutils.mdwn
+++ b/code/moreutils.mdwn
@@ -30,6 +30,7 @@ There are lots more listed below, and I'm always interested to add
 more to the collection, as long as they're suitably general-purpose,
 and don't duplicate other well-known tools.
 
+- chronic: runs a command quietly unless it fails
 - combine: combine the lines in two files using boolean operations
 - ifdata: get network interface info without parsing ifconfig output
 - ifne: run a program if the standard input is not empty

diff --git a/blog/entry/a_resolution_that_stuck/comment_1_b1283b459eb38b57ab91a5c49ac71156._comment b/blog/entry/a_resolution_that_stuck/comment_1_b1283b459eb38b57ab91a5c49ac71156._comment
new file mode 100644
index 0000000..9d1c516
--- /dev/null
+++ b/blog/entry/a_resolution_that_stuck/comment_1_b1283b459eb38b57ab91a5c49ac71156._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmEsNX-3h_78xvpTJuhqrDXE7RfH-o-Ue8"
+ nickname="Maggie"
+ subject="Wow!"
+ date="2012-01-02T14:18:57Z"
+ content="""
+I am really impressed by your journalling.  Mundane and banal subject matter in large quantities is what writing is all about, I think.  Perhaps it might feel like you are not writing profound enough stuff, but the fact that you write is making you better at writing.  And from there you can go on and write a sci fi novel or a nonfiction book about your neurotic little sister, or a combination of the two!  Or just a simple poem about dripping rain on your roof, because I think much of your writing is poetic.  Then it is quality over quantity.  :)  Good example.
+"""]]

diff --git a/blog/archives/2012.mdwn b/blog/archives/2012.mdwn
new file mode 100644
index 0000000..3546d01
--- /dev/null
+++ b/blog/archives/2012.mdwn
@@ -0,0 +1 @@
+[[!calendar type=year year=2012 pages="blog/entry/* and !*/Discussion"]]
diff --git a/blog/archives/2012/01.mdwn b/blog/archives/2012/01.mdwn
new file mode 100644
index 0000000..0590449
--- /dev/null
+++ b/blog/archives/2012/01.mdwn
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=01 year=2012 pages="blog/entry/* and !*/Discussion"]]
+"""]]
+
+[[!inline pages="creation_month(01) and creation_year(2012) and blog/entry/* and !*/Discussion" show=0 feeds=no reverse=yes]]
diff --git a/blog/archives/2012/02.mdwn b/blog/archives/2012/02.mdwn
new file mode 100644
index 0000000..541ef05
--- /dev/null
+++ b/blog/archives/2012/02.mdwn
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=02 year=2012 pages="blog/entry/* and !*/Discussion"]]
+"""]]
+
+[[!inline pages="creation_month(02) and creation_year(2012) and blog/entry/* and !*/Discussion" show=0 feeds=no reverse=yes]]
diff --git a/blog/archives/2012/03.mdwn b/blog/archives/2012/03.mdwn
new file mode 100644
index 0000000..193d3d0
--- /dev/null
+++ b/blog/archives/2012/03.mdwn
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=03 year=2012 pages="blog/entry/* and !*/Discussion"]]
+"""]]
+
+[[!inline pages="creation_month(03) and creation_year(2012) and blog/entry/* and !*/Discussion" show=0 feeds=no reverse=yes]]
diff --git a/blog/archives/2012/04.mdwn b/blog/archives/2012/04.mdwn
new file mode 100644
index 0000000..864fe1c
--- /dev/null
+++ b/blog/archives/2012/04.mdwn
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=04 year=2012 pages="blog/entry/* and !*/Discussion"]]
+"""]]
+
+[[!inline pages="creation_month(04) and creation_year(2012) and blog/entry/* and !*/Discussion" show=0 feeds=no reverse=yes]]
diff --git a/blog/archives/2012/05.mdwn b/blog/archives/2012/05.mdwn
new file mode 100644
index 0000000..3ab796f
--- /dev/null
+++ b/blog/archives/2012/05.mdwn
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=05 year=2012 pages="blog/entry/* and !*/Discussion"]]
+"""]]
+
+[[!inline pages="creation_month(05) and creation_year(2012) and blog/entry/* and !*/Discussion" show=0 feeds=no reverse=yes]]
diff --git a/blog/archives/2012/06.mdwn b/blog/archives/2012/06.mdwn
new file mode 100644
index 0000000..21b6f1e
--- /dev/null
+++ b/blog/archives/2012/06.mdwn
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=06 year=2012 pages="blog/entry/* and !*/Discussion"]]
+"""]]
+
+[[!inline pages="creation_month(06) and creation_year(2012) and blog/entry/* and !*/Discussion" show=0 feeds=no reverse=yes]]
diff --git a/blog/archives/2012/07.mdwn b/blog/archives/2012/07.mdwn
new file mode 100644
index 0000000..50968ed
--- /dev/null
+++ b/blog/archives/2012/07.mdwn
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=07 year=2012 pages="blog/entry/* and !*/Discussion"]]
+"""]]
+
+[[!inline pages="creation_month(07) and creation_year(2012) and blog/entry/* and !*/Discussion" show=0 feeds=no reverse=yes]]
diff --git a/blog/archives/2012/08.mdwn b/blog/archives/2012/08.mdwn
new file mode 100644
index 0000000..9eafa8a
--- /dev/null
+++ b/blog/archives/2012/08.mdwn
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=08 year=2012 pages="blog/entry/* and !*/Discussion"]]
+"""]]
+
+[[!inline pages="creation_month(08) and creation_year(2012) and blog/entry/* and !*/Discussion" show=0 feeds=no reverse=yes]]
diff --git a/blog/archives/2012/09.mdwn b/blog/archives/2012/09.mdwn
new file mode 100644
index 0000000..0fcd7bc
--- /dev/null
+++ b/blog/archives/2012/09.mdwn
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=09 year=2012 pages="blog/entry/* and !*/Discussion"]]
+"""]]
+
+[[!inline pages="creation_month(09) and creation_year(2012) and blog/entry/* and !*/Discussion" show=0 feeds=no reverse=yes]]
diff --git a/blog/archives/2012/10.mdwn b/blog/archives/2012/10.mdwn
new file mode 100644
index 0000000..9d38155
--- /dev/null
+++ b/blog/archives/2012/10.mdwn
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=10 year=2012 pages="blog/entry/* and !*/Discussion"]]
+"""]]
+
+[[!inline pages="creation_month(10) and creation_year(2012) and blog/entry/* and !*/Discussion" show=0 feeds=no reverse=yes]]
diff --git a/blog/archives/2012/11.mdwn b/blog/archives/2012/11.mdwn
new file mode 100644
index 0000000..47202a9
--- /dev/null
+++ b/blog/archives/2012/11.mdwn
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=11 year=2012 pages="blog/entry/* and !*/Discussion"]]
+"""]]
+
+[[!inline pages="creation_month(11) and creation_year(2012) and blog/entry/* and !*/Discussion" show=0 feeds=no reverse=yes]]
diff --git a/blog/archives/2012/12.mdwn b/blog/archives/2012/12.mdwn
new file mode 100644
index 0000000..73a4b18
--- /dev/null
+++ b/blog/archives/2012/12.mdwn
@@ -0,0 +1,5 @@
+[[!sidebar content="""
+[[!calendar type=month month=12 year=2012 pages="blog/entry/* and !*/Discussion"]]
+"""]]
+
+[[!inline pages="creation_month(12) and creation_year(2012) and blog/entry/* and !*/Discussion" show=0 feeds=no reverse=yes]]

diff --git a/blog/entry/a_resolution_that_stuck.mdwn b/blog/entry/a_resolution_that_stuck.mdwn
new file mode 100644
index 0000000..045d65c
--- /dev/null
+++ b/blog/entry/a_resolution_that_stuck.mdwn
@@ -0,0 +1,60 @@
+Last year, my new year's resolution was to write in my journal every day.
+That actually stuck, I wrote 262 journal entries in 2011. While I've been
+keeping a journal intermittently since 1998, last year I doubled the number
+of entries in it. And wrote a novel's worth of entries -- 53 thousand words!
+
+Most of it is of course banal and mundane stuff. Not good compared with
+Lars, who does something with his journal where he goes into some detail
+about code he's working on, and other work. The excerpts I've seen are
+quite nice. But after I've written code, written a commit message,
+documentation, perhaps bug reports etc, I often can't find much to say
+about it in my journal, beyond the bare bones that I worked on $foo today or
+faced a particularly hard bug. I also worry that the journal, and my
+reluctance to repeat myself, often tips the balance away from me blogging,
+if I write down something in the journal first.
+
+----
+
+Here's my journal for today:
+
+> Compare what jokes are funny now with those in 1982.
+> The 1982 ones from net.jokes on olduse.net seem juvenile.
+> Now compare what Unix joke man pages are funny now with
+> those I'm reading from 1982. They seem basically the same.
+> What would Biella make of this?
+> 
+> Liw noticed ikiwiki OOM on pell. Tracked down to a perl markdown
+> bug with long lines. Had quite enough of perl markdown; ikiwiki will be
+> moving to a different engine. Added discount support to it today,
+> still needs Debian package tho.
+> 
+> [censored]
+> 
+> Really gorgeous sunset, with a high wind, moon, puffy low, fast moving
+> clouds. Enjoyed it ecstaticly. It's going to get cold soon. Very rainy
+> early, but then got intermittently sunny; power is holding out ok.
+> 
+> Was going to roast a chicken today, but got distracted and had a large 
+> lunch besides. Need to find some quick food for supper.
+> 
+> I need to start a new book, should it be the River Cottage book about 
+> meat that I stole from Anna, or some SF?
+> 
+> Blogged about journaling, and put this journal entry in it, so also 
+> journaled about blogging. Wrote it somewhat self-conciously.
+
+----
+
+The benefits for me have ranged from being able to go back and work out
+dates of events, to forwarding the odd excerpts to others. The best thing
+though is certianly having a regular time of introspection, to look back
+over my the day.
+
+If you've not got a new year's resolution yet, I recommend this one.
+(Learning Haskell would be another good one, if you haven't yet.)
+
+Just write something, anything, down in your journal every day.
+
+[[!tag lay]]
+
+[[!meta title="a resolution that stuck"]]

diff --git a/blog/entry/solar_year/comment_3_755a8791b829ea99ad6281de86633053._comment b/blog/entry/solar_year/comment_3_755a8791b829ea99ad6281de86633053._comment
new file mode 100644
index 0000000..8ff63b6
--- /dev/null
+++ b/blog/entry/solar_year/comment_3_755a8791b829ea99ad6281de86633053._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 3"
+ date="2012-01-01T22:23:49Z"
+ content="""
+To put it in perspective, about the highest I've seen my panels produce is 125 watts. Not that many lightbulbs worth.
+
+I'm sometimes asked why I don't add more solar panels, and that's a good question; I have mostly enjoyed finding ways to make do with so little power, however.
+"""]]

diff --git a/blog/entry/solar_year/comment_2_584984ca0e99be7386c8f4908dfeae43._comment b/blog/entry/solar_year/comment_2_584984ca0e99be7386c8f4908dfeae43._comment
new file mode 100644
index 0000000..90299ae
--- /dev/null
+++ b/blog/entry/solar_year/comment_2_584984ca0e99be7386c8f4908dfeae43._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 2"
+ date="2012-01-01T22:16:43Z"
+ content="""
+My PV system is only 256 watts, and it's nearly 2 decades old (and the recycled batteries are older still). I wrote some more about it in [[getting_to_know_my_batteries]].
+
+It is neat to get a little power on cloudy days. Works as long as the clouds are not so thick that the day is entirely dim. My PV only produces enough on such days to \"break even\" with my running the laptop all day though.
+
+I also like the effect where, on an overcast day with snowfall, the snow on the surrounding hills acts as a reflector and I get much more production that I normally would.
+"""]]

diff --git a/blog/entry/solar_year/comment_1_bc457b5df9d71c1491e23279bea1357b._comment b/blog/entry/solar_year/comment_1_bc457b5df9d71c1491e23279bea1357b._comment
new file mode 100644
index 0000000..cb0d357
--- /dev/null
+++ b/blog/entry/solar_year/comment_1_bc457b5df9d71c1491e23279bea1357b._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnJ6kdPrjIPHSo5V_ZxZEj2W8pmCx_FNYU"
+ nickname="Keith"
+ subject="Off Grid"
+ date="2012-01-01T19:55:30Z"
+ content="""
+Joey,
+
+I find this very fascinating! Less than a month ago I put a PV array on my house and have been much more attuned to the weather and its effect on my production. Our system is 3.8kW and I was amazed to see that even on a very overcast day the system would put out nearly a kW. I am really looking forward to the summer when we start generating more each day than we consume. We also have a family friend who grew up off grid and her parents continue to live in their cabin. They get their power from a micro-hydro setup and have an array of golf cart batteries to store their power.
+
+Can you tell me more about your setup?
+"""]]

diff --git a/blog/entry/solar_year.mdwn b/blog/entry/solar_year.mdwn
index a691140..3ea712d 100644
--- a/blog/entry/solar_year.mdwn
+++ b/blog/entry/solar_year.mdwn
@@ -8,14 +8,14 @@ spell where power felt slightly tight. Then over the summer, plenty of
 power, no need to conserve. The last month though had what seemed like
 weeks of continual grey clouds, where I never saw the sun.
 
-[[!img blog/pics/high_noon.png align=right caption="high noon today"]]
+[[!img blog/pics/high_noon.jpg align=right caption="high noon today"]]
 
 Of course, even on a sunny day in winter, it does not get far
 above the hills, and the peak production window is only a few hours.
 This bad combination had my battery power dipping below the 10 volts
 that I consider low, down to 9, and even to 8 volts.
 
-Of course I use kerosine lamps in the winter. (I prefer the light anway.)
+I use kerosine lamps in the winter. (I prefer the light anway.)
 I've also started unplugging my Thecus server at night to conserve power,
 meaning no internet late or early. For four or so nights, I had no power to
 run even my laptop after sunset. On one notable day, there was no power

diff --git a/blog/entry/solar_year.mdwn b/blog/entry/solar_year.mdwn
new file mode 100644
index 0000000..a691140
--- /dev/null
+++ b/blog/entry/solar_year.mdwn
@@ -0,0 +1,39 @@
+I've been at the cabin, on solar power, for a year now. I have a year of
+data!
+
+[[!img blog/pics/volt_log_2011.png]]
+
+Everything went pretty well until last month. There was an April rainy
+spell where power felt slightly tight. Then over the summer, plenty of
+power, no need to conserve. The last month though had what seemed like
+weeks of continual grey clouds, where I never saw the sun.
+
+[[!img blog/pics/high_noon.png align=right caption="high noon today"]]
+
+Of course, even on a sunny day in winter, it does not get far
+above the hills, and the peak production window is only a few hours.
+This bad combination had my battery power dipping below the 10 volts
+that I consider low, down to 9, and even to 8 volts.
+
+Of course I use kerosine lamps in the winter. (I prefer the light anway.)
+I've also started unplugging my Thecus server at night to conserve power,
+meaning no internet late or early. For four or so nights, I had no power to
+run even my laptop after sunset. On one notable day, there was no power
+even in the daytime.
+
+Even when it turned sunny again, I found that the batteries would seem to
+charge to 12 volts during the day, but then precipitously drop to 10 and 9
+volts at night. I think the problem was not damaged batteries, but that
+these Nicads charge most efficiently above 12 volts (14 volts is best), and
+there was never enough power saved up to get them full enough that they
+could charge really efficiently.
+
+So, I reluctantly spent three days away this week, to let the batteries
+soak up sun and recover. It seems to have worked; they've been holding
+a 12 volt charge overnight again.
+
+
+
+[[!tag lay solar]]
+
+[[!meta title="solar year"]]
diff --git a/blog/pics/high_noon.jpg b/blog/pics/high_noon.jpg
new file mode 100644
index 0000000..c71616b
Binary files /dev/null and b/blog/pics/high_noon.jpg differ
diff --git a/blog/pics/volt_log_2011.png b/blog/pics/volt_log_2011.png
new file mode 100644
index 0000000..2d0a543
Binary files /dev/null and b/blog/pics/volt_log_2011.png differ

diff --git a/blog/entry/a_Github_survey/comment_1_e2037af64861ebd4f660b7f5a882b9ad._comment b/blog/entry/a_Github_survey/comment_1_e2037af64861ebd4f660b7f5a882b9ad._comment
new file mode 100644
index 0000000..c38dcc2
--- /dev/null
+++ b/blog/entry/a_Github_survey/comment_1_e2037af64861ebd4f660b7f5a882b9ad._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl6qDWThz-0xNJ-1u6_7vYpe2UTwdHdS2g"
+ nickname="Jason"
+ subject="Right here."
+ date="2011-12-28T18:36:01Z"
+ content="""
+Jason Scott, Internet Archive, nominally in charge of software preservation. Up and ready to talk about this now or when I'm in town on the 16th of January. Want to connect us?
+"""]]

diff --git a/blog/entry/a_Github_survey.mdwn b/blog/entry/a_Github_survey.mdwn
new file mode 100644
index 0000000..81b1018
--- /dev/null
+++ b/blog/entry/a_Github_survey.mdwn
@@ -0,0 +1,60 @@
+The great thing about git and other distributed version control systems is
+that once you clone (or fork) a repository, you have all the data. You
+don't have to trust that Github will preserve it; everyone who develops
+the project is a backup.
+
+Github carries this principle quite far amoung the features they provide.
+But not all the way. Today I have surveyed their features, and where the
+data for each is stored.
+
+* source code -- in git, of course!
+* user and project [pages](http://pages.github.com) and wiki -- in git
+* [gists](https://gist.github.com/) -- in git
+* issues -- in a database accessible by an [API](http://developer.github.com)
+* notes on commits -- in a database accessible by an API
+* relationships between repos (who forked what, pull requests)
+  -- in a database accessible by an API
+* your account details and activity -- in a database, accessible
+  by you via an API
+* list of all projects and users -- in a closed database (AFAIK)
+
+The two that really stand out are the issues and notes not being stored in
+git. This means that, if a project uses github, it gets locked into github
+to a degree. The records of bugs and features, all the planning, and
+communication, is locked away in a database where it cannot be cloned,
+where every developer is *not* a backup.
+
+Github's intent here is *not* to control this data to lock you in (to the
+extent they want to lock you in, they do that by providing a proprietary UI
+that people rave about); it was probably only expedient to use some sort of
+database, rather than git, when implementing these features.
+
+They should automatically produce git repository branches containing a
+project's issues, and notes, based on the contents of their database.
+(For notes, `git notes` is the obviously right storage location.)
+Along with ensuring every developer checkout is a backup, this would
+allow accessing that data while offline, which is one of the reasons
+we use distributed version control.
+
+The lack of a global list of projects is problimatic in a more global sense.
+It means that we can't make a backup of all the (public) repositories in
+Github (assuming that we had the bandwidth and storage to do it). I
+recently backed up all the repositories on Berlios.de, when it looked to be
+shutting down; this was only possible because they allowed enumerating them
+all.
+
+People at The Internet Archive say that their archival coverage of free
+software is actually quite *bad*. We trust our version control systems
+to save our free software data, but while this works individually, it
+will result in data loss globally over time. I'd encourage Github to help
+the Internet Archive improve their collections by donating periodic snapshots
+of their public git repositories to the Archive. You're located in the same
+city, 5 miles apart; they have lots of hard drives (though less right
+now during the shortage than usual); this should be pretty easy to do.
+
+----
+
+Full disclosure: Github has bought me dinner and seemed like
+stand-up guys to me.
+
+[[!meta title="a Github survey"]]

diff --git a/code/mr/news/version_1.09.mdwn b/code/mr/news/version_1.09.mdwn
deleted file mode 100644
index 8247249..0000000
--- a/code/mr/news/version_1.09.mdwn
+++ /dev/null
@@ -1,5 +0,0 @@
-mr 1.09 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * Remove dir\_test hack and add a way for vcs tests to run perl code,
-     using this for the same optimisation. Fixes support for git-svn
-     etc. Closes: #[652317](http://bugs.debian.org/652317)"""]]
\ No newline at end of file
diff --git a/code/mr/news/version_1.10.mdwn b/code/mr/news/version_1.10.mdwn
new file mode 100644
index 0000000..d7f02dd
--- /dev/null
+++ b/code/mr/news/version_1.10.mdwn
@@ -0,0 +1,3 @@
+mr 1.10 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * Fix display of trust errors."""]]
\ No newline at end of file

diff --git a/code/debhelper/news/version_8.9.14.mdwn b/code/debhelper/news/version_8.9.14.mdwn
new file mode 100644
index 0000000..9f7aefe
--- /dev/null
+++ b/code/debhelper/news/version_8.9.14.mdwn
@@ -0,0 +1,4 @@
+debhelper 8.9.14 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * Typo. Closes: #[653006](http://bugs.debian.org/653006)
+   * Typo. Closes: #[653339](http://bugs.debian.org/653339)"""]]
\ No newline at end of file
diff --git a/code/debhelper/news/version_8.9.9.mdwn b/code/debhelper/news/version_8.9.9.mdwn
deleted file mode 100644
index 8f7e10b..0000000
--- a/code/debhelper/news/version_8.9.9.mdwn
+++ /dev/null
@@ -1,5 +0,0 @@
-debhelper 8.9.9 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * dh\_auto\_build: Use target architecture (not host architecture)
-     for build directory name. Closes: #[644553](http://bugs.debian.org/644553) Thanks, Tom Hughes
-   * dh: Add dh\_auto\_configure parameter example. Closes: #[645335](http://bugs.debian.org/645335)"""]]
\ No newline at end of file

diff --git a/code/etckeeper/news/version_0.54.mdwn b/code/etckeeper/news/version_0.54.mdwn
deleted file mode 100644
index 69ef50f..0000000
--- a/code/etckeeper/news/version_0.54.mdwn
+++ /dev/null
@@ -1,8 +0,0 @@
-etckeeper 0.54 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * Ignore inssev's FHS violating /etc/init.d/.depend.* files.
-     Closes: #[619407](http://bugs.debian.org/619407) See #619409
-   * Use hg pre-commit hook, rather than its precommit hook,
-     as the latter is run after the files staged for commit are
-     determined and so .etckeeper cannot be staged as part of the current
-     commit. Closes: #[621827](http://bugs.debian.org/621827)"""]]
\ No newline at end of file
diff --git a/code/etckeeper/news/version_0.59.mdwn b/code/etckeeper/news/version_0.59.mdwn
new file mode 100644
index 0000000..991ee20
--- /dev/null
+++ b/code/etckeeper/news/version_0.59.mdwn
@@ -0,0 +1,6 @@
+etckeeper 0.59 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * Add /etc/cups/subscriptions.conf to default ignores, as the content of
+     this file does not normally contain configuration and it changes
+     frequently. Closes: #[651168](http://bugs.debian.org/651168)
+   * Shell quoting fix. Thanks, Daniel Hahler"""]]
\ No newline at end of file

diff --git a/code/etckeeper/discussion.mdwn b/code/etckeeper/discussion.mdwn
index 4cab2b5..24dc28a 100644
--- a/code/etckeeper/discussion.mdwn
+++ b/code/etckeeper/discussion.mdwn
@@ -1,4 +1,20 @@
 ---
+How about calling "sync; sync" at the end of "etckeeper commit"?
+/etc/.git (or whichever DVCS' repo) is worth ensuring to be immediately
+committed to the disk.
+
+    --- a/commit.d/50vcs-commit
+    +++ b/commit.d/50vcs-commit
+    @@ -87,3 +87,5 @@ elif [ "$VCS" = darcs ] && [ -d _darcs ]; then
+                    darcs record --author="$USER" $DARCS_COMMIT_OPTIONS
+            fi
+     fi
+    +
+    +sync; sync
+
+--Kai
+
+---
 
 I would love to see some notify support.
 

diff --git a/code/etckeeper/discussion.mdwn b/code/etckeeper/discussion.mdwn
index a9c06a5..4cab2b5 100644
--- a/code/etckeeper/discussion.mdwn
+++ b/code/etckeeper/discussion.mdwn
@@ -1,4 +1,4 @@
-==
+---
 
 I would love to see some notify support.
 
@@ -12,27 +12,27 @@ with any package management software, including plain old "cp".
 
 --arekm
 
-==
+---
 Hey,
 
 what is the best way to kind of "temporary commit" changes in the working directory to be able to fast install some packages with APT? Git stash is not what I want, since I cannot change the working directory. (e.g. for server programs like postfix, which really poll for changes in /etc). Git rebase afterwards is also nothing I want to do in /etc. What is the best way? Is there a clever way? --sandoz (2011-06-08)
 
-==
+---
 
 Hi Joey, 0.44 mentions OS X portability fixes, but metastore doesn't compile on OS X. Therefore, how is etckeeper run on OS X?
 
 > etckeeper has not used metastore for a long time. --[[Joey]] 
 
-==
+---
 
 Thanks for etckeeper; I just used it in anger for the first time.  I don't know for a fact that it really made my life better, but it makes me _feel_ better.  The story: I applied the usual security upgrade to my desktop box, and after rebooting, noted with dismay that my monitor, which had previously been happily running at 1280x1024, was now running at 640x480.  (Typical Linux story.)  So I poked around, and dimly remembered that I could run 'dpkg-reconfigure xserver-xorg', which I did.  (I realize that's probably not the best tool for what I was doing, but it's all I remembered).  That worked -- the monitor is now back to its old 1280x1024 self.  Naturally the xorg.conf file is totally different; both the current version and the old version are utterly incomprehensible to me ... but the point is _I've got a record of all of them_, plus a comment explaining what I did and why.  _That's_ why etckeeper makes me feel better.
 Thanks again.
 
-==
+---
 
 Oops, it just saved my butt again.  I swear I'll try not to append to this comment every time it proves useful ...
 
-==
+---
 
 Hey, I was wondering if there's any intention to support subversion?
 
@@ -40,7 +40,7 @@ Hey, I was wondering if there's any intention to support subversion?
 > all the .svn directories. I do not plan to work on supporting it myself,
 > if someone works up a reasonable patch I'd probably apply it. --[[Joey]] 
 
-==
+---
 
 What would you say is the best hosting site to use with etckeeper (git)? It should probably be private right?
 
@@ -60,13 +60,13 @@ Also can you use etckeeper for backing up home directory dotfiles?
 >> the problem if we used it for that? Most likely I'm missing something but
 >> It seems possible with the current code. --George
 
-==
+---
 
 The idea of managing config files from remote computers sounds interesting to me. Is it possible to pull and push updates through git without loss of original metadata? Thanks in advance, Chris.
 
 > etckeeper restores the metadata when `etckeeper init` is run. --[[Joey]]
 
-==
+---
 
 Hi.
 
@@ -83,7 +83,7 @@ TIA, Richard.
 
 >> +1 --George
 
-==
+---
 
 I'm running etckeeper; have happily not had need to use its results "in anger," (e.g. - haven't needed to use it to recover from a problem), but feel a fairly considerable weight alleviated from shoulders.
 
@@ -106,13 +106,13 @@ The fact that these are completely independent sets of configuration for each do
 
 cbbrowne@acm.org
 
-==
+---
 
 ummm, where are the docs please? thanks!
 
 > In the package. --[[Joey]] 
 
-==
+---
 
 Interaction bug with Ubuntu Software Centre (Ubuntu 10.10): all packages installed from the centre get failure message:
 
@@ -130,11 +130,11 @@ while `bzr whoami` from a terminal correctly reports "john doe <johndoe@example.
 > (Also, bug reports without version numbers are not very useful.
 > --[[Joey]] 
 
-==
+---
 
 I just saw that etckeeper is now integrated to TurnKey-Linux, version 11.1. Great work Joey! -- PRouleau
 
-==
+---
 
 On RH flavored Linux systems network configuration files are typically (if not controlled by NetworkManager) hardlinked in 2-3 places and thus cause warnings like this:
 
@@ -149,7 +149,7 @@ On RH flavored Linux systems network configuration files are typically (if not c
 
 every time etckeeper is run, which is kind of annoying. What would you propose to do about this? --Thomas
 
-==
+---
 
 +1 for RH problems (perhaps a AVOID_SPECIAL_FILE_WARNING option?). How serious the problem with hardlinks is anyway? Maybe at least these (NetworkManager) files should be somehow ignored?
 

diff --git a/code/etckeeper/discussion.mdwn b/code/etckeeper/discussion.mdwn
index 35b70cc..a9c06a5 100644
--- a/code/etckeeper/discussion.mdwn
+++ b/code/etckeeper/discussion.mdwn
@@ -5,7 +5,7 @@ I would love to see some notify support.
 Would be cool to be able to run etckeeper as daemon that will automaticly commit on each file change,
 best with information on who actually made the change. Information about who made the change probably
 will require audit support or fanotify under Linux (not sure which provides all required info and
-is best suited for this task).[funny quotes](http://itshumour.blogspot.com/2010/06/twenty-hilarious-funny-quotes.html) [hilarious quotes](http://bit.ly/1AHm7r) [funny jokes](http://itshumour.blogspot.com/2011/07/funny-marriage-jokes.html) [dental implants](http://dentaldentistsolutions.blogspot.com/2009/10/process-and-pictures-dental-implants.html)[funny facebook statuses](http://itshumour.blogspot.com/2011/08/funny-statuses-quotes-for-facebook.html)
+is best suited for this task).
 
 That would make etckeeper kind of backup PLUS logging solution. In this mode it would also work
 with any package management software, including plain old "cp".

diff --git a/boxen.mdwn b/boxen.mdwn
index e04b639..7ae1fca 100644
--- a/boxen.mdwn
+++ b/boxen.mdwn
@@ -12,9 +12,10 @@ Mostly mythical creatures.
 
 * [[gnu]] {*}
 * wildebeest (spare for gnu)
-* grebe (Anna's)
-* cucurbit {*} (Anna's old)
+* grebe {*} (Anna's)
+* cucurbit (Anna's old)
 * aquamiser {*} (Mark's)
+* aquamiser2 {*} (Mark's new)
 * [[kodama]]
 * [[phoenix]]
 * [[dragon]]
diff --git a/code/mr/news/version_1.08.mdwn b/code/mr/news/version_1.08.mdwn
deleted file mode 100644
index 73c1180..0000000
--- a/code/mr/news/version_1.08.mdwn
+++ /dev/null
@@ -1,3 +0,0 @@
-mr 1.08 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * Fix vcs test code. Closes: #[651976](http://bugs.debian.org/651976)"""]]
\ No newline at end of file
diff --git a/code/mr/news/version_1.09.mdwn b/code/mr/news/version_1.09.mdwn
new file mode 100644
index 0000000..8247249
--- /dev/null
+++ b/code/mr/news/version_1.09.mdwn
@@ -0,0 +1,5 @@
+mr 1.09 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * Remove dir\_test hack and add a way for vcs tests to run perl code,
+     using this for the same optimisation. Fixes support for git-svn
+     etc. Closes: #[652317](http://bugs.debian.org/652317)"""]]
\ No newline at end of file

diff --git a/code/mr/news/version_1.07.mdwn b/code/mr/news/version_1.07.mdwn
deleted file mode 100644
index 7144c98..0000000
--- a/code/mr/news/version_1.07.mdwn
+++ /dev/null
@@ -1,15 +0,0 @@
-mr 1.07 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * Added support for vcsh, enable with: include = cat /usr/share/mr/vcsh
-     Thanks, Richard Hartmann
-   * Block tty control codes in untrusted mr config files.
-   * Correct printing of line numbers when includes are used. Closes: #[650952](http://bugs.debian.org/650952)
-   * The previous fix for chaining to absolute paths broke chaining to relative
-     paths with more than one path segment. Thanks, Adam Spiers
-   * Support \_append to add on to the existing value of a parameter.
-     Thanks, Adam Spiers
-   * Optimizations. Commands like "mr list" run up to 5 times faster.
-   * Fix shell escaping of parameters passed to mr commands. Closes: #[644672](http://bugs.debian.org/644672)
-   * Added --force option that disables repository skipping.
-   * Repositories using skip = lazy will not be checked out by "mr update"
-     or "mr checkout" unless --force is used."""]]
\ No newline at end of file
diff --git a/code/mr/news/version_1.08.mdwn b/code/mr/news/version_1.08.mdwn
new file mode 100644
index 0000000..73c1180
--- /dev/null
+++ b/code/mr/news/version_1.08.mdwn
@@ -0,0 +1,3 @@
+mr 1.08 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * Fix vcs test code. Closes: #[651976](http://bugs.debian.org/651976)"""]]
\ No newline at end of file

diff --git a/code/mr/news/version_1.06.mdwn b/code/mr/news/version_1.06.mdwn
deleted file mode 100644
index 6c9b9fc..0000000
--- a/code/mr/news/version_1.06.mdwn
+++ /dev/null
@@ -1,6 +0,0 @@
-mr 1.06 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * Fix propigation of failure from pre and post hooks and from fixups.
-   * Support chaining to absolute paths.
-   * Add support for skip = lazy, a mode where mr only operates on repositories
-     that are checked out."""]]
\ No newline at end of file
diff --git a/code/mr/news/version_1.07.mdwn b/code/mr/news/version_1.07.mdwn
new file mode 100644
index 0000000..7144c98
--- /dev/null
+++ b/code/mr/news/version_1.07.mdwn
@@ -0,0 +1,15 @@
+mr 1.07 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * Added support for vcsh, enable with: include = cat /usr/share/mr/vcsh
+     Thanks, Richard Hartmann
+   * Block tty control codes in untrusted mr config files.
+   * Correct printing of line numbers when includes are used. Closes: #[650952](http://bugs.debian.org/650952)
+   * The previous fix for chaining to absolute paths broke chaining to relative
+     paths with more than one path segment. Thanks, Adam Spiers
+   * Support \_append to add on to the existing value of a parameter.
+     Thanks, Adam Spiers
+   * Optimizations. Commands like "mr list" run up to 5 times faster.
+   * Fix shell escaping of parameters passed to mr commands. Closes: #[644672](http://bugs.debian.org/644672)
+   * Added --force option that disables repository skipping.
+   * Repositories using skip = lazy will not be checked out by "mr update"
+     or "mr checkout" unless --force is used."""]]
\ No newline at end of file

diff --git a/code/debhelper/news/version_8.9.13.mdwn b/code/debhelper/news/version_8.9.13.mdwn
new file mode 100644
index 0000000..2324032
--- /dev/null
+++ b/code/debhelper/news/version_8.9.13.mdwn
@@ -0,0 +1,8 @@
+debhelper 8.9.13 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * Pass CPPFLAGS to qmake. Closes: #[646129](http://bugs.debian.org/646129) Thanks, Felix Geyert
+   * dh\_strip: Use build-id in /usr/lib/debug in v9.
+     Closes: #[642158](http://bugs.debian.org/642158) Thanks, Jakub Wilk
+   * Spanish translation update. Closes: #[636245](http://bugs.debian.org/636245) Thanks, Omar Campagne
+   * Only enable executable config files in v9. The quality of file permissions
+     in debian/ directories turns out to be atrocious; who knew?"""]]
\ No newline at end of file
diff --git a/code/debhelper/news/version_8.9.8.mdwn b/code/debhelper/news/version_8.9.8.mdwn
deleted file mode 100644
index d5bf3a0..0000000
--- a/code/debhelper/news/version_8.9.8.mdwn
+++ /dev/null
@@ -1,11 +0,0 @@
-debhelper 8.9.8 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * dh\_fixperms: Operate on .ali files throughout /usr/lib, including
-     multiarch dirs. Closes: #[641279](http://bugs.debian.org/641279)
-   * dh: Avoid compat deprecation warning before option parsing.
-     Closes: #[641361](http://bugs.debian.org/641361)
-   * Clarify description of dh\_auto\_* -- params. Closes: #[642786](http://bugs.debian.org/642786)
-   * Mention in debhelper(7) that buildsystem options are typically passed
-     to dh. Closes: #[643069](http://bugs.debian.org/643069)
-   * perl\_makemaker: In v9, pass CFLAGS to Makefile.PL using OPTIMIZE.
-     Closes: #[643702](http://bugs.debian.org/643702) Thanks, Steve Langasek."""]]
\ No newline at end of file

diff --git a/code/debhelper/news/version_8.9.12.mdwn b/code/debhelper/news/version_8.9.12.mdwn
new file mode 100644
index 0000000..85c5c7d
--- /dev/null
+++ b/code/debhelper/news/version_8.9.12.mdwn
@@ -0,0 +1,10 @@
+debhelper 8.9.12 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * Debhelper config files may be made executable programs that output the
+     desired configuration. No further changes are planned to the config file
+     format; those needing powerful syntaxes may now use a programming language
+     of their choice. (Be careful aiming that at your feet.)
+     Closes: #[235302](http://bugs.debian.org/235302), #[372310](http://bugs.debian.org/372310), #[235302](http://bugs.debian.org/235302), #[614731](http://bugs.debian.org/614731),
+     Closes: #[438601](http://bugs.debian.org/438601), #[477625](http://bugs.debian.org/477625), #[632860](http://bugs.debian.org/632860), #[642129](http://bugs.debian.org/642129)
+   * Added German translation of man pages, done by Chris Leick. Closes: #[651221](http://bugs.debian.org/651221)
+   * Typo fixes. Closes: #[651224](http://bugs.debian.org/651224) Thanks, Chris Leick"""]]
\ No newline at end of file
diff --git a/code/debhelper/news/version_8.9.7.mdwn b/code/debhelper/news/version_8.9.7.mdwn
deleted file mode 100644
index a404f79..0000000
--- a/code/debhelper/news/version_8.9.7.mdwn
+++ /dev/null
@@ -1,27 +0,0 @@
-debhelper 8.9.7 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * dh: Now you can use override\_dh\_command-arch and override\_dh\_command-indep
-     to run different overrides when building arch and indep packages. This
-     allows for a much simplified form of rules file in this situation, where
-     build-arch/indep and binary-arch/indep targets do not need to be manually
-     specified. See man page for examples. Closes: #[640965](http://bugs.debian.org/640965)
-     .
-     Note that if a rules file has say, override\_dh\_fixperms-arch,
-     but no corresponding override\_dh\_fixperms-indep, then the unoverridden
-     dh\_fixperms will be run on the indep packages.
-     .
-     Note that the old override\_dh\_command takes precidence over the new
-     overrides, because mixing the two types of overrides would have been
-     too complicated. In particular, it's difficult to ensure an
-     old override target will work if it's sometimes constrained to only
-     acting on half the packages it would normally run on. This would be
-     a source of subtle bugs, so is avoided.
-   * dh: Don't bother running dh\_shlibdebs, dh\_makeshlibs, or dh\_strip
-     in the binary target when all packages being acted on are indep.
-   * dh: Avoid running install sequence a third time in v9 when the
-     rules file has explicit binary-indep and binary-arch targets.
-     Closes: #[639341](http://bugs.debian.org/639341) Thanks, Yann Dirson for test case.
-   * debhelper no longer build-depends on man-db or file, to ease bootstrapping.
-   * Remove obsolete versioned dependency on perl-base.
-   * Avoid writing debhelper log files in no-act mode. Closes: #[640586](http://bugs.debian.org/640586)
-   * Tighten parsing of DEB\_BUILD\_OPTIONS."""]]
\ No newline at end of file

diff --git a/code/debian.mdwn b/code/debian.mdwn
index 09e8174..6367695 100644
--- a/code/debian.mdwn
+++ b/code/debian.mdwn
@@ -1,6 +1,6 @@
 [[!sidebar content="""
 My personal apt repository, with current releases of all my [[code]]
-is at <http://kitenet.net/~joey/debian/>
+is at [here](http://kitenet.net/~joey/debian/)
 """]]
 
 Debian is too large for this page, and my decade-plus of involvement in the

diff --git a/code/pdmenu.mdwn b/code/pdmenu.mdwn
index a82e3bd..dbcc38c 100644
--- a/code/pdmenu.mdwn
+++ b/code/pdmenu.mdwn
@@ -23,6 +23,9 @@ from git (`git://git.kitenet.net/pdmenu`).
 Currently the best place to download the tarball is from
 <http://packages.debian.org/unstable/source/pdmenu>
 
+For CentOS and SUSE, there are packages here:
+<http://software.opensuse.org/search?baseproject=ALL&exclude_debug=true&lang=en&p=1&q=pdmenu>
+
 ----
 
 Amazingly, pdmenu was my first C program!

diff --git a/blog/entry/watch_me_code_for_half_an_hour.mdwn b/blog/entry/watch_me_code_for_half_an_hour.mdwn
index d174c43..6d89a59 100644
--- a/blog/entry/watch_me_code_for_half_an_hour.mdwn
+++ b/blog/entry/watch_me_code_for_half_an_hour.mdwn
@@ -14,6 +14,6 @@ Not shown is the hour I spent the next day changing the "optimize"
 subcommand implemented here into "--auto" options that can be passed to
 [[code/git-annex]]'s get and drop commands.
 
-[[!poll 33 "watched it all, liked it" 8 "watched some, boring" 3 "too long for me" 14 "too haskell for me" 12 "not interested"]]
+[[!poll 34 "watched it all, liked it" 8 "watched some, boring" 3 "too long for me" 14 "too haskell for me" 12 "not interested"]]
 
 [[!meta title="watch me program for half an hour"]]

diff --git a/boxen/discussion.mdwn b/boxen/discussion.mdwn
deleted file mode 100644
index 257cc56..0000000
--- a/boxen/discussion.mdwn
+++ /dev/null
@@ -1 +0,0 @@
-foo

diff --git a/boxen/discussion.mdwn b/boxen/discussion.mdwn
new file mode 100644
index 0000000..257cc56
--- /dev/null
+++ b/boxen/discussion.mdwn
@@ -0,0 +1 @@
+foo

diff --git a/boxen/discussion.mdwn b/boxen/discussion.mdwn
deleted file mode 100644
index 257cc56..0000000
--- a/boxen/discussion.mdwn
+++ /dev/null
@@ -1 +0,0 @@
-foo

diff --git a/boxen/discussion.mdwn b/boxen/discussion.mdwn
new file mode 100644
index 0000000..257cc56
--- /dev/null
+++ b/boxen/discussion.mdwn
@@ -0,0 +1 @@
+foo

diff --git a/code/etckeeper/news/version_0.53.mdwn b/code/etckeeper/news/version_0.53.mdwn
deleted file mode 100644
index 4bbd6e4..0000000
--- a/code/etckeeper/news/version_0.53.mdwn
+++ /dev/null
@@ -1,14 +0,0 @@
-etckeeper 0.53 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
- * [ Joey Hess ]
-   * Install bzr hook lazily, clean up some compatibility code. (Jelmer Vernooij)
- * [ Josh Triplett ]
-   * Only set environment variables for commit authorship (EMAIL,
-     GIT\_AUTHOR\_NAME, GIT\_AUTHOR\_EMAIL, GIT\_COMMITTER\_EMAIL) if they don't
-     already exist.
- * [ Joey Hess ]
-   * Add .pyc and .pyo files to ignore.
-   * Add lvm/backup and lvm/cache to ignore. Closes: #[462355](http://bugs.debian.org/462355)
-   * Avoid warning about special or hard linked files that are ignored
-     by hg. Thanks Sjoerd Mullender for patch.
-     Closes: https://bugzilla.redhat.com/show\_bug.cgi?id=688991"""]]
\ No newline at end of file
diff --git a/code/etckeeper/news/version_0.58.mdwn b/code/etckeeper/news/version_0.58.mdwn
new file mode 100644
index 0000000..f26d056
--- /dev/null
+++ b/code/etckeeper/news/version_0.58.mdwn
@@ -0,0 +1,19 @@
+etckeeper 0.58 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * Changed to store all permissions of files and directories, even those
+     with standard permissions of 644 and 755. This is unfortunately necessary
+     in order to support etckeeper init on a checkout that was made with a
+     nonstandard umask, in which case the files that were expected to be
+     644 and 755, won't be. Closes: #[649701](http://bugs.debian.org/649701)
+     Thanks to Дмитрий Матросов for reporting the bug and developing
+     a fixup script (attached to the bug) which could be used if you've
+     already encountered this problem.
+   * Bugfix for filenames containing single quotes.
+   * Use git add -A, which automatically removes deleted files,
+     and avoids a separate call to git add -u.
+     Thanks to Miklos Vajna, whose patch in 2008 was deferred
+     because -A was then too new, and languished in a branch until found today.
+   * Optimised metadata storage.
+   * cron.daily: Don't stop committing when a stale packagelist.pre-install
+     file exists.
+     Thanks to gulikoza for noticing this bug."""]]
\ No newline at end of file

diff --git a/blog/entry/roundtrip_latency_from_a_cabin_with_dialup_in_2011.mdwn b/blog/entry/roundtrip_latency_from_a_cabin_with_dialup_in_2011.mdwn
index bd38691..1279117 100644
--- a/blog/entry/roundtrip_latency_from_a_cabin_with_dialup_in_2011.mdwn
+++ b/blog/entry/roundtrip_latency_from_a_cabin_with_dialup_in_2011.mdwn
@@ -35,6 +35,7 @@ alt="imagine an xkcd-style infographic here"
 ## 2 minutes
 
 - downloading new email
+- commute to work
 - an increasing number of websites that force https
   (average of 3 reloads needed due to timeouts)
 
diff --git a/hacker_tombstone.otl b/hacker_tombstone.otl
index bb4d65e..7c9c575 100644
--- a/hacker_tombstone.otl
+++ b/hacker_tombstone.otl
@@ -182,6 +182,8 @@ case studies
 			died on april 17th of a heart attack."
 		obitiary
 			master.debian.org:/home/debian/git/obituary.git
+		tombstone
+			https://lists.debian.ch/pipermail/community/2011/000675.html
 server issues
 	keep server up or take it down?
 		how long should it stay up?

diff --git a/blog/entry/roundtrip_latency_from_a_cabin_with_dialup_in_2011.mdwn b/blog/entry/roundtrip_latency_from_a_cabin_with_dialup_in_2011.mdwn
index b73719c..bd38691 100644
--- a/blog/entry/roundtrip_latency_from_a_cabin_with_dialup_in_2011.mdwn
+++ b/blog/entry/roundtrip_latency_from_a_cabin_with_dialup_in_2011.mdwn
@@ -68,7 +68,7 @@ alt="imagine an xkcd-style infographic here"
 - an hour of video pulled from my server with git-annex
   (includes travel time to broadband access point)
 
-## 110 minutes
+## 70 minutes
 
 - a halfway decent but slightly overpriced grocery store
 - a produce stand

diff --git a/blog/entry/roundtrip_latency_from_a_cabin_with_dialup_in_2011.mdwn b/blog/entry/roundtrip_latency_from_a_cabin_with_dialup_in_2011.mdwn
new file mode 100644
index 0000000..b73719c
--- /dev/null
+++ b/blog/entry/roundtrip_latency_from_a_cabin_with_dialup_in_2011.mdwn
@@ -0,0 +1,86 @@
+alt="imagine an xkcd-style infographic here"
+
+## 0 seconds
+
+- peace and quiet
+- full history of all my projects (git repos)
+- my blog
+- email
+
+## 0.5 seconds
+
+- chatting on IRC
+- searching through all email received since 1994
+- music
+- cached web pages
+
+## 5 seconds
+
+- ssh to a server
+- search the web
+- lwn, hacker news, reddit, metafilter, and other web aggregators
+
+## 10 seconds
+
+- resuming laptop from sleep and waiting for network-manager
+- view an unnecessarily pastebinned scrap of text
+- access local Debian mirror
+- looking up a typical bug report
+
+## 20 seconds
+
+- click on a typical link from a web aggregator
+- an hour of video pulled from a USB drive with git-annex
+
+## 2 minutes
+
+- downloading new email
+- an increasing number of websites that force https
+  (average of 3 reloads needed due to timeouts)
+
+## 5 minutes
+
+- viewing a single file, bug report, or merge request on github
+- cloning the full content of a typical not too large git repo
+- retriving data from archival drives via git-annex
+- going offline and making a phone call
+- `apt-get update` (thanks aj, for the pdiffs)
+- viewing a single a twitter page (megabytes of crud and `#!` redirections)
+
+## 10 minutes
+
+- entering a state of flow while programming
+- boingboing.net (with all the pretty pictures)
+- my mailbox (after a nice walk down a long driveway)
+
+## 22 minutes
+
+- milk and eggs
+- a swim in the river
+
+## 30 minutes
+
+- broadband internet access
+- someone else who knows what linux is
+
+## 32 minutes
+
+- an hour of video pulled from my server with git-annex
+  (includes travel time to broadband access point)
+
+## 110 minutes
+
+- a halfway decent but slightly overpriced grocery store
+- a produce stand
+- a coffee shop
+
+## 180 minutes
+
+- family
+- a bakery with real bread
+
+## 300 minutes
+
+- downloading a typical podcast
+
+[[!meta title="roundtrip latency from a cabin with dialup in 2011"]]

diff --git a/code/etckeeper/discussion.mdwn b/code/etckeeper/discussion.mdwn
index a9c06a5..35b70cc 100644
--- a/code/etckeeper/discussion.mdwn
+++ b/code/etckeeper/discussion.mdwn
@@ -5,7 +5,7 @@ I would love to see some notify support.
 Would be cool to be able to run etckeeper as daemon that will automaticly commit on each file change,
 best with information on who actually made the change. Information about who made the change probably
 will require audit support or fanotify under Linux (not sure which provides all required info and
-is best suited for this task).
+is best suited for this task).[funny quotes](http://itshumour.blogspot.com/2010/06/twenty-hilarious-funny-quotes.html) [hilarious quotes](http://bit.ly/1AHm7r) [funny jokes](http://itshumour.blogspot.com/2011/07/funny-marriage-jokes.html) [dental implants](http://dentaldentistsolutions.blogspot.com/2009/10/process-and-pictures-dental-implants.html)[funny facebook statuses](http://itshumour.blogspot.com/2011/08/funny-statuses-quotes-for-facebook.html)
 
 That would make etckeeper kind of backup PLUS logging solution. In this mode it would also work
 with any package management software, including plain old "cp".

diff --git a/code/etckeeper/discussion.mdwn b/code/etckeeper/discussion.mdwn
index e34ad85..a9c06a5 100644
--- a/code/etckeeper/discussion.mdwn
+++ b/code/etckeeper/discussion.mdwn
@@ -1,3 +1,18 @@
+==
+
+I would love to see some notify support.
+
+Would be cool to be able to run etckeeper as daemon that will automaticly commit on each file change,
+best with information on who actually made the change. Information about who made the change probably
+will require audit support or fanotify under Linux (not sure which provides all required info and
+is best suited for this task).
+
+That would make etckeeper kind of backup PLUS logging solution. In this mode it would also work
+with any package management software, including plain old "cp".
+
+--arekm
+
+==
 Hey,
 
 what is the best way to kind of "temporary commit" changes in the working directory to be able to fast install some packages with APT? Git stash is not what I want, since I cannot change the working directory. (e.g. for server programs like postfix, which really poll for changes in /etc). Git rebase afterwards is also nothing I want to do in /etc. What is the best way? Is there a clever way? --sandoz (2011-06-08)

diff --git a/code/debhelper/news/version_8.9.11.mdwn b/code/debhelper/news/version_8.9.11.mdwn
new file mode 100644
index 0000000..a9cd607
--- /dev/null
+++ b/code/debhelper/news/version_8.9.11.mdwn
@@ -0,0 +1,3 @@
+debhelper 8.9.11 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * Fix broken option passing to objcopy. Closes: #[649044](http://bugs.debian.org/649044)"""]]
\ No newline at end of file
diff --git a/code/debhelper/news/version_8.9.6.mdwn b/code/debhelper/news/version_8.9.6.mdwn
deleted file mode 100644
index 10364d9..0000000
--- a/code/debhelper/news/version_8.9.6.mdwn
+++ /dev/null
@@ -1,4 +0,0 @@
-debhelper 8.9.6 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * dh\_installlogcheck: Add support for --name. Closes: #[639020](http://bugs.debian.org/639020)
-     Thanks, Gergely Nagy"""]]
\ No newline at end of file

diff --git a/code/debhelper/news/version_8.9.10.mdwn b/code/debhelper/news/version_8.9.10.mdwn
new file mode 100644
index 0000000..b1e85ca
--- /dev/null
+++ b/code/debhelper/news/version_8.9.10.mdwn
@@ -0,0 +1,9 @@
+debhelper 8.9.10 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * dh\_strip: In v9, pass --compress-debug-sections to objcopy.
+     Needs a new enough binutils and gdb; debhelper backport
+     may need to disable this.
+     Thanks, Aurelien Jarno and Bastien ROUCARIES. Closes: #[631985](http://bugs.debian.org/631985)
+   * dh: Ensure -a and -i are passed when running override\_dh\_command-arch
+     and override\_dh\_command-indep targets. This is needed when the binary
+     target is run, rather than binary-arch/binary-indep. Closes: #[648901](http://bugs.debian.org/648901)"""]]
\ No newline at end of file
diff --git a/code/debhelper/news/version_8.9.5.mdwn b/code/debhelper/news/version_8.9.5.mdwn
deleted file mode 100644
index bff0001..0000000
--- a/code/debhelper/news/version_8.9.5.mdwn
+++ /dev/null
@@ -1,8 +0,0 @@
-debhelper 8.9.5 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * dh\_compress: Don't compress \_sources documentation subdirectory
-     as used by python-sphinx. Closes: #[637492](http://bugs.debian.org/637492)
-     Thanks, Jakub Wilk
-   * dh\_ucf: fix test for ucf/ucfr availability and quote filenames.
-     Closes: #[638944](http://bugs.debian.org/638944)
-     Thanks, Jeroen Schot"""]]
\ No newline at end of file

diff --git a/blog/entry/watch_me_code_for_half_an_hour.mdwn b/blog/entry/watch_me_code_for_half_an_hour.mdwn
index b0f8207..d174c43 100644
--- a/blog/entry/watch_me_code_for_half_an_hour.mdwn
+++ b/blog/entry/watch_me_code_for_half_an_hour.mdwn
@@ -14,6 +14,6 @@ Not shown is the hour I spent the next day changing the "optimize"
 subcommand implemented here into "--auto" options that can be passed to
 [[code/git-annex]]'s get and drop commands.
 
-[[!poll 32 "watched it all, liked it" 8 "watched some, boring" 3 "too long for me" 14 "too haskell for me" 12 "not interested"]]
+[[!poll 33 "watched it all, liked it" 8 "watched some, boring" 3 "too long for me" 14 "too haskell for me" 12 "not interested"]]
 
 [[!meta title="watch me program for half an hour"]]

diff --git a/code/alien/news/version_8.81.mdwn b/code/alien/news/version_8.81.mdwn
deleted file mode 100644
index 92104a8..0000000
--- a/code/alien/news/version_8.81.mdwn
+++ /dev/null
@@ -1,17 +0,0 @@
-alien 8.81 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * Avoid uninitialized value warning when debian/rules fails to run
-     due to alien being run in a noexec directory. Closes: #[579216](http://bugs.debian.org/579216)
-   * Prevent DESTROY stomping on alien's exit code sometimes.
-   * Support extracting lzma compressed RPMs.
-     (Patch by unnamed person on some bug tracking system I don't frequent.)
-   * Suggest lzma. If not installed, alien will still fail to decompress
-     RPMs using it, but will support most rpms, which are not.
-   * Fix precedence problem that prevented alien from preserving permissions
-     of suid/sgid binaries that are not owned by root.
-     (Patch by Duane Waddle, on a bug tracking system I don't frequent, that
-     was about the "expire" it 4 days from now. We got lucky Duane, but please
-     use the Debian BTS next time!)
-   * Support RPMs containing ghost files.
-     (Patch by Ben Webb, who would get his patches applied quicker if he
-     actually communicated them to the program's author.)"""]]
\ No newline at end of file
diff --git a/code/alien/news/version_8.86.mdwn b/code/alien/news/version_8.86.mdwn
new file mode 100644
index 0000000..b366085
--- /dev/null
+++ b/code/alien/news/version_8.86.mdwn
@@ -0,0 +1,4 @@
+alien 8.86 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * Filter out illegal characters in version number when building a deb.
+     Closes: #[648531](http://bugs.debian.org/648531)"""]]
\ No newline at end of file

diff --git a/blog/entry/the_Engelbart_demo/comment_1_033b7a534c3d3621de2242752370ef00._comment b/blog/entry/the_Engelbart_demo/comment_1_033b7a534c3d3621de2242752370ef00._comment
new file mode 100644
index 0000000..2c14e42
--- /dev/null
+++ b/blog/entry/the_Engelbart_demo/comment_1_033b7a534c3d3621de2242752370ef00._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm71zIuCSK5niEBxskozZ3eblcdHD7TmhY"
+ nickname="Wouter"
+ subject="Webcam!"
+ date="2011-11-08T07:54:16Z"
+ content="""
+You forgot the webcam -- and your final image actually shows it. This is not the film director deciding to do an overlay or so, they mention that they have the computer do the routing. Sure, they probably don't digitize the video stream, instead transmitting it through analogue channels instead, but it's still a camera builtin to the monitor, the feed of which is being displayed on another monitor.
+"""]]

diff --git a/blog/entry/watch_me_code_for_half_an_hour.mdwn b/blog/entry/watch_me_code_for_half_an_hour.mdwn
index 2dde540..b0f8207 100644
--- a/blog/entry/watch_me_code_for_half_an_hour.mdwn
+++ b/blog/entry/watch_me_code_for_half_an_hour.mdwn
@@ -14,6 +14,6 @@ Not shown is the hour I spent the next day changing the "optimize"
 subcommand implemented here into "--auto" options that can be passed to
 [[code/git-annex]]'s get and drop commands.
 
-[[!poll 31 "watched it all, liked it" 8 "watched some, boring" 3 "too long for me" 14 "too haskell for me" 12 "not interested"]]
+[[!poll 32 "watched it all, liked it" 8 "watched some, boring" 3 "too long for me" 14 "too haskell for me" 12 "not interested"]]
 
 [[!meta title="watch me program for half an hour"]]

diff --git a/code/debhelper/news/version_8.9.4.mdwn b/code/debhelper/news/version_8.9.4.mdwn
deleted file mode 100644
index ce85b8a..0000000
--- a/code/debhelper/news/version_8.9.4.mdwn
+++ /dev/null
@@ -1,15 +0,0 @@
-debhelper 8.9.4 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * dh: The --before --after --until and --remaining options are deprecated.
-     Use override targets instead.
-   * Assume that the package can be cleaned (i.e. the build directory can be
-     removed) as long as it is built out-of-source tree and can be configured.
-     This is useful for derivative buildsystems which generate Makefiles.
-     (Modestas Vainius) Closes: #[601590](http://bugs.debian.org/601590)
-   * dh\_auto\_test: Run cmake tests in parallel when allowed by
-     DEB\_BUILD\_OPTIONS. (Modestas Vainius) Closes: #[587885](http://bugs.debian.org/587885)
-   * dpkg-buildflags is only used to set environment in v9, to avoid
-     re-breaking packages that were already broken a first time by
-     dpkg-buildpackage unconditionally setting the environment, and
-     worked around that by unsetting variables in the rules file.
-     (Example: numpy)"""]]
\ No newline at end of file
diff --git a/code/debhelper/news/version_8.9.9.mdwn b/code/debhelper/news/version_8.9.9.mdwn
new file mode 100644
index 0000000..8f7e10b
--- /dev/null
+++ b/code/debhelper/news/version_8.9.9.mdwn
@@ -0,0 +1,5 @@
+debhelper 8.9.9 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * dh\_auto\_build: Use target architecture (not host architecture)
+     for build directory name. Closes: #[644553](http://bugs.debian.org/644553) Thanks, Tom Hughes
+   * dh: Add dh\_auto\_configure parameter example. Closes: #[645335](http://bugs.debian.org/645335)"""]]
\ No newline at end of file

diff --git a/code/mr/news/version_1.05.mdwn b/code/mr/news/version_1.05.mdwn
deleted file mode 100644
index 7f95c5a..0000000
--- a/code/mr/news/version_1.05.mdwn
+++ /dev/null
@@ -1,16 +0,0 @@
-mr 1.05 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * README now gives a quick into to using mr.
-   * Brought back the "deleted" parameter, which provides an easy way to
-     mark repositories that should be removed.
-   * Allow untrusted mrconfig files to set parameters to true/false.
-     So skip=true or deleted=true can be used in an untrusted mrconfig file.
-   * Also allow order=N in an untrusted mrconfig file.
-   * Support bzr checkouts, which are updated with "bzr update",
-     and to which bzr automatically pushes commits. Closes: #[643589](http://bugs.debian.org/643589)
-   * Use bzr branch, not deprecated bzr clone when registering bzr
-     repositories. Closes: #[643591](http://bugs.debian.org/643591)
-   * Allow bzr branch|clone|get|checkout in untrusted mrconfig files.
-   * Avoid using sed -r in git-fake-bare, for OSX portability.
-   * git-fake-bare: handle fake bare repositories with core.bare not set
-     (Thanks, Julien Rebetez)"""]]
\ No newline at end of file
diff --git a/code/mr/news/version_1.06.mdwn b/code/mr/news/version_1.06.mdwn
new file mode 100644
index 0000000..6c9b9fc
--- /dev/null
+++ b/code/mr/news/version_1.06.mdwn
@@ -0,0 +1,6 @@
+mr 1.06 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * Fix propigation of failure from pre and post hooks and from fixups.
+   * Support chaining to absolute paths.
+   * Add support for skip = lazy, a mode where mr only operates on repositories
+     that are checked out."""]]
\ No newline at end of file

diff --git a/code/etckeeper/news/version_0.52.mdwn b/code/etckeeper/news/version_0.52.mdwn
deleted file mode 100644
index ec78f3d..0000000
--- a/code/etckeeper/news/version_0.52.mdwn
+++ /dev/null
@@ -1,4 +0,0 @@
-etckeeper 0.52 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * Rewrote 50git-rm to avoid using git ls-files, and thus avoid encoding
-     problems with filenames."""]]
\ No newline at end of file
diff --git a/code/etckeeper/news/version_0.57.mdwn b/code/etckeeper/news/version_0.57.mdwn
new file mode 100644
index 0000000..a38ea18
--- /dev/null
+++ b/code/etckeeper/news/version_0.57.mdwn
@@ -0,0 +1,3 @@
+etckeeper 0.57 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * Use find -path instead of less portable find -wholename."""]]
\ No newline at end of file

diff --git a/blog/entry/watch_me_code_for_half_an_hour.mdwn b/blog/entry/watch_me_code_for_half_an_hour.mdwn
index 7cbd968..2dde540 100644
--- a/blog/entry/watch_me_code_for_half_an_hour.mdwn
+++ b/blog/entry/watch_me_code_for_half_an_hour.mdwn
@@ -14,6 +14,6 @@ Not shown is the hour I spent the next day changing the "optimize"
 subcommand implemented here into "--auto" options that can be passed to
 [[code/git-annex]]'s get and drop commands.
 
-[[!poll 30 "watched it all, liked it" 8 "watched some, boring" 3 "too long for me" 14 "too haskell for me" 12 "not interested"]]
+[[!poll 31 "watched it all, liked it" 8 "watched some, boring" 3 "too long for me" 14 "too haskell for me" 12 "not interested"]]
 
 [[!meta title="watch me program for half an hour"]]

diff --git a/blog/entry/two_random_thoughts_about_bugs/comment_5_88deec04b145e354777dec0674239632._comment b/blog/entry/two_random_thoughts_about_bugs/comment_5_88deec04b145e354777dec0674239632._comment
new file mode 100644
index 0000000..4c0625e
--- /dev/null
+++ b/blog/entry/two_random_thoughts_about_bugs/comment_5_88deec04b145e354777dec0674239632._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://joshtriplett.myopenid.com/"
+ nickname="Josh"
+ subject="comment 5"
+ date="2011-11-03T06:56:53Z"
+ content="""
+mirabilos: \"not a bug\" can just get closed, and potentially flagged as I described if it represents a common form of \"not a bug\" that people should check before filing a new bug.  \"difference of opinion\" falls under \"working as designed\", which gets treated the same way.
+"""]]

diff --git a/blog/entry/the_Engelbart_demo.mdwn b/blog/entry/the_Engelbart_demo.mdwn
new file mode 100644
index 0000000..ac4b170
--- /dev/null
+++ b/blog/entry/the_Engelbart_demo.mdwn
@@ -0,0 +1,47 @@
+Just watched the whole [Douglas Engelbart demo from
+1968](http://en.wikipedia.org/wiki/The_Mother_of_All_Demos).
+Somehow I'd only heard of this as the first demo of the computer mouse,
+and only seen a brief clip on youtube. All three 30-minute reels of
+the film are [available online](http://www.archive.org/details/XD300-23_68HighlightsAResearchCntAugHumanIntellect),
+and well worth a watch in full.
+
+[[!img pics/demo/face.png size=200x]]
+[[!img pics/demo/mouse.png size=200x]]
+
+The mouse is the least of it, the demo includes an outlining text editor,
+model-view-controller, hypertext, wiki, domain specific programming
+languages, a precurser to email, bug tracking, version control(?), a
+chorded keyboard. (Ok, that last one didn't really take off.) Probably a
+dozen other things I've forgotten. All in a single interface, and all
+before I was born.
+
+Just like any tech demo, there are fumbles and mistakes, which is
+reassuring to anyone who has tried to give a tech demo.
+
+[[!img pics/demo/camera.png size=200x align=left]]
+There's also the awesome crazy hack shown here. 
+They could only afford these
+tiny, round CRTs, so they pointed a television camera at it, and the
+camera image was piped to their television console. (So add KVM switch to
+the list of firsts!) The demo 
+was done in San Fransisco, with the computer system remote in Palo Alto, so
+in this image you see the text on the CRT overlaid with the video from the
+camera. 
+
+[[!img pics/demo/google.png align=right size=200x]]
+
+Engelbart points out that the delay this added to the system acts as a
+short-term memory that filtered out flicker in the original display (and
+made the mouse have a mouse trail). To me it gives the whole demo a unique
+quality, as if it were underwater.
+
+Despite the piping around of audio and video signals, and the multiuser
+system, the glaring thing missing from the demo that we have these days is
+networking. Although there is this amusing bit at the end where they compile
+a regular expression and then apply it, in order to search for documents
+containing certain terms, and end up with a hyperlinked list of 10 results,
+ordered by relevance. Yes, think Google.
+
+[[!tag computer history]]
+
+[[!meta title="the Engelbart demo"]]

diff --git a/blog/pics/demo/camera.png b/blog/pics/demo/camera.png
new file mode 100644
index 0000000..ca78be1
Binary files /dev/null and b/blog/pics/demo/camera.png differ
diff --git a/blog/pics/demo/face.png b/blog/pics/demo/face.png
new file mode 100644
index 0000000..de413a6
Binary files /dev/null and b/blog/pics/demo/face.png differ
diff --git a/blog/pics/demo/google.png b/blog/pics/demo/google.png
new file mode 100644
index 0000000..689b9a0
Binary files /dev/null and b/blog/pics/demo/google.png differ
diff --git a/blog/pics/demo/mouse.png b/blog/pics/demo/mouse.png
new file mode 100644
index 0000000..d6f4042
Binary files /dev/null and b/blog/pics/demo/mouse.png differ

diff --git a/blog/entry/two_random_thoughts_about_bugs/comment_4_783cb5df0932fab72284960c73d8343a._comment b/blog/entry/two_random_thoughts_about_bugs/comment_4_783cb5df0932fab72284960c73d8343a._comment
new file mode 100644
index 0000000..89aa7a0
--- /dev/null
+++ b/blog/entry/two_random_thoughts_about_bugs/comment_4_783cb5df0932fab72284960c73d8343a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://mirsolutions.de/"
+ nickname="mirabilos"
+ subject="filtering categories"
+ date="2011-10-31T09:05:20Z"
+ content="""
+Josh, I like your idea of having a submitter and a maintainer view of bugs which only interest one party, such as your third class of wontfix bugs. (And the second class, with the option to show them in a maintainer view too, when the maintainer is in a state to actively look at the upstream bugs in his package.)
+
+There’s also, still, “not a bug” (invalid, closed?) and “difference in opinion”…
+"""]]

diff --git a/blog/entry/two_random_thoughts_about_bugs/comment_3_f87b041b4a583d7cf9945f7c54e7f3b0._comment b/blog/entry/two_random_thoughts_about_bugs/comment_3_f87b041b4a583d7cf9945f7c54e7f3b0._comment
new file mode 100644
index 0000000..7d11f86
--- /dev/null
+++ b/blog/entry/two_random_thoughts_about_bugs/comment_3_f87b041b4a583d7cf9945f7c54e7f3b0._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://joshtriplett.myopenid.com/"
+ nickname="Josh"
+ subject="Types of wontfix bugs"
+ date="2011-10-31T03:29:34Z"
+ content="""
+Many of the wontfix bugs I know of would indeed fit into different categories:
+
+- Bugs where the maintainer says some variant of \"I don't plan to do this myself\" should get tagged \"help\", not \"wontfix\".
+- Bugs for upstream rather than Debian should get tagged \"upstream\", and effectively reassigned upstream.  Unfortunately we don't have a cross-BTS reassign command.
+- Bugs which request changes to behavior that works as upstream intended and won't change should get closed as non-bugs.  (For instance, bugs requesting the inclusion of non-free software.)
+
+However, for some of these cases I do think a more general tag should exist, which says \"despite the possible closure of this bug, treat it as an open bug for the purposes of showing it when searching the bug lists, so that people don't file duplicates\".  Something similar to the \"affects\" mechanism, but for open or closed bugs in the same package rather than open bugs in a different package.  This tag should also generate a separate category, which the maintainer can more easily ignore.
+"""]]

diff --git a/blog/entry/two_random_thoughts_about_bugs/comment_2_9a1e3ffc4c1d130cb4e0207888295202._comment b/blog/entry/two_random_thoughts_about_bugs/comment_2_9a1e3ffc4c1d130cb4e0207888295202._comment
new file mode 100644
index 0000000..73098f9
--- /dev/null
+++ b/blog/entry/two_random_thoughts_about_bugs/comment_2_9a1e3ffc4c1d130cb4e0207888295202._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="http://mirsolutions.de/"
+ nickname="mirabilos"
+ subject="on WONTFIX"
+ date="2011-10-29T22:08:51Z"
+ content="""
+There are bug tracking systems for software and for packages.
+Debian BTS is the latter, in most cases.
+
+I have a lot of WONTFIX bugs in cvs which I’d like to close,
+but anal-ist reporters tell me to only close them if “the
+bug has been resolved” (meaning if they are pleased). These
+things are misunderstandings of the reporters, difference in
+opinion about the topic at hand, and (most) development of new
+features or changes of existing behaviour that the packager,
+as opposed to upstream, just cannot do (or cannot reason).
+
+So I’d like to keep my WONTFIX, please. (Otherwise, I’d be
+closing them all and ignoring the reporters’ cries which,
+I guess, some code of conduct would forbid me eventually.)
+
+PS: I don't use markdown, and what’s otl? The “plain old
+text” option is missing here…
+"""]]

diff --git a/blog/entry/two_random_thoughts_about_bugs/comment_1_b51bd460d1b0a12af03a32da97210f10._comment b/blog/entry/two_random_thoughts_about_bugs/comment_1_b51bd460d1b0a12af03a32da97210f10._comment
new file mode 100644
index 0000000..12eafa1
--- /dev/null
+++ b/blog/entry/two_random_thoughts_about_bugs/comment_1_b51bd460d1b0a12af03a32da97210f10._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlgyDHHlSfaeXKS1V4Jsoe-6U8Ty46XZl4"
+ nickname="Philipp"
+ subject="Meta bugs"
+ date="2011-10-29T18:32:03Z"
+ content="""
+Are you referring to facilities that will prevent the user to file another bug about that specific problem?  Because I always felt that \"wontfix\" is exactly about that.
+"""]]

diff --git a/blog/entry/two_random_thoughts_about_bugs.mdwn b/blog/entry/two_random_thoughts_about_bugs.mdwn
new file mode 100644
index 0000000..575e6e8
--- /dev/null
+++ b/blog/entry/two_random_thoughts_about_bugs.mdwn
@@ -0,0 +1,23 @@
+First thought is this: A bug's likelyhood of ever being fixed decays with
+time, starting when I first read it. If I have to read it a second time,
+the bug has already become more complex, since something prevented me from
+just fixing it the first time. If more information has to be added to the
+bug, that makes it yet more complex. If there is an argument in the bug
+about whether it is a bug, or how to fix it, just revisiting the bug at a
+later date can become more expensive than it's worth. Much of what is
+involved in filing good and effective bug reports are obvious corollaries
+of this. It also follows that it's best to either fix, or at least plan how
+to fix a bug immediatly upon reading it.
+
+Second thought is about "wontfix". A bug submitter and the developer
+responsible for the bug see this state in very different ways, but the name
+hides what it really means, which is that there is a meta-bug affecting
+either the bug submitter, the developer, or both. Once you realize this,
+wontfix bugs, from either side, become a bit personally insulting. They
+also quickly decay to uselessness (see first thought), and then just lurk
+there wasting the developer's time in various ways. Bug tracking systems
+should not provide a "wontfix" state; if they want to track meta-bugs
+they should provide a way to reassign such a bug to some other party who
+can actually resolve such a meta-bug.
+
+[[!meta title="two random thoughts about bugs"]]

diff --git a/blog/entry/GitTogether2011.mdwn b/blog/entry/GitTogether2011.mdwn
index 3c98f62..89a55a2 100644
--- a/blog/entry/GitTogether2011.mdwn
+++ b/blog/entry/GitTogether2011.mdwn
@@ -26,7 +26,7 @@ discussed during the unconference:
   before I wrote [[code/etckeeper]], that no, git should not be used for that..)
 * submodules: I was astounded that they're now considering supporting
   "floating" submodules, which would track the head of a branch, rather
-  that the specific rev committed in the superproject. Many other problems
+  than the specific rev committed in the superproject. Many other problems
   that have kept me from ever trying submodules are also being worked on.
   This seems unlikely to replace [[code/mr]], but who knows -- at least getting
   rid of [repo](http://source.android.com/source/version-control.html)

diff --git a/blog/entry/GitTogether2011.mdwn b/blog/entry/GitTogether2011.mdwn
index 2b5f6d6..3c98f62 100644
--- a/blog/entry/GitTogether2011.mdwn
+++ b/blog/entry/GitTogether2011.mdwn
@@ -16,9 +16,9 @@ I was very happy that everything I think needs improvement in git was
 discussed during the unconference:
 
 * big files: My postit suggesting this got more checks than most 
-  anything else, and I briefly presented git-annex at the start of a
-  session on general scalability. Some ideas for improved hooks that
-  git-annex and other tools could use are developing.
+  anything else, and I briefly presented [[code/git-annex]] at the start of a
+  session on general scalability -- on its 1-year anniversary. Some ideas
+  for improved hooks that git-annex and other tools could use are developing.
   Better scalability to lots of files and more efficient index files were
   also discussed.
 * git as a filesystem: There was a consensus that gone are the days